Dev Tracker - Discussion

Clearly a troll or a fool.

I can tell you that Thorny doesn't troll basically ever.

Well we now know who’s mule you are.

If anyone ever believed that, I have a bridge to sell them.

I've trolled in the past, and I was a world-class *** as a teenager. I'm not going to deny that. I don't know who you are since you're anonymous, and I'm sure I gave you a perfectly good reason to hate me back in the day given your bs character is on Leviathan. If you talked to me about it like an adult, I'd probably offer you a much-deserved apology. But, damn near half of your posts on that account are just attacking me out of nowhere, and none of them are substantiated.

You've claimed I don't know what I'm talking about, but I don't see you correcting anything I have to say. You're claiming I troll, but you can't provide an example of where. The bottom line is that you seem to have the world's biggest chip on your shoulder, and it's contributing nothing to this or any other thread. Get over it. And no, I am not Geriond(as if that really needs to be said, we disagree all the time..)

Don’t flatter yourself. I don’t know you from Adam. I’ve browsed here and other XI forums and there are just people on both who I read their comments, roll my eyes and think “oh lord”. You take unnecessary pokes at people often and get raged when anyone does it to you.

To be fair, you’re not the only person on here I find annoying.

*** Thorny has helped more people on this site than I guarantee you have. You’re really going over the top to make your voice heard about how much hate you have for him, and really, it’s you that sounds like a problem. There’s a block button for a reason, *** use it if you hate him so much.

Also, I’m not his other mule either, since you probably were going that route.

Calm down, I don’t hate anyone. I find some people annoying and think it’s amusing when they accuse someone of something they’re guilty of.

I didn't know this was the throny tracker thread.

Should change the title to horny for throny...

Pm me the price of the bridge when you have a chance.

It's disgusting how much misinformation is being peddled in this thread. *​All* manipulation of data comes from the client:

How do speed hacks work? -- The client dictates how quickly the character can switch between two positions and relays that information to the server accordingly. The server performs ZERO verifications against the values provided.

How do position hacks work? -- The client lets the server know the coordinates that the character is positioned at and the server treats it as such, once again, without any validation.

How did the HQ crafting exploit work? -- The client let the server know that the craft result was an HQ item, so of course, the server respected it and populated an HQ item into the character's inventory.

If you're starting to see a pattern here then you're not alone, the client is king in all things related to cheating.

Now there's another factor that Thorny has alluded to in previous posts that we can dive into a little deeper. Packet size.

First, this person would have you believe that the server itself uses a "3999 byte buffer for outgoing packets". Sorry, but that is not how computers work. When you see a storage capacity that dictates 1MB, it actually means 1024 kilobytes. How many people here have 3999 MB of RAM? Raise your hands. Zero, of course. You have 4.294 GB of RAM or some other exponential factor of 2.

Let's assume that this person was somehow correct and the maximum packet size was "3999 bytes". Well guess what, these are UDP packets and as such they don't need to be confirmed by the recipient before the next one is sent. Transmission rate is just as important as packet size and completely eliminates the need for a throttled stream of inventory packets.

The reason that the *4096* kb packets are throttled is because the network routers and firewall that Square Enix uses check for duplicate packets before transmitting anything. This prevents item duplication and a number of other exploits from being allowed through.

--

Edit: FYI, what Thorny is doing is using buzzwords and partially correct information to troll people who don't have the knowledge to fully comprehend their posts. It's juvenile and easily seen through by anyone who is actually in the industry.

The server is not verifying their positions for anything related to game code, instead they are now monitoring position changes over time and flagging characters that exceed a maximum allowed rate. The client is still dictating the characters movement speed and position at runtime but the server is *finally* starting to check after several hours whether or not the data that the client sent should be flagged or not.

Yes, but that's always going to be the case whenever any hack is addressed. The client itself isn't going to verify it, they're the source of the faulty data. Any exploit that is eventually patched is done so via the server monitoring the data sent from the client and eventually flagging it. It changes nothing about the immediate interaction with the game though. The big thing now is that Square Enix actually has routers and firewalls monitoring the issue which should put some of these hackers at pause.

MTU for standard ethernet equipment is 1500 bytes, not 3999, 4096 or other random values, 1500. Encapsulation / tunneling can modify that value downward and is why we use Maximum Segment Size (MSS) as a way to fragment as little as possible. UDP ignores MSS entirely and doesn't have any way to auto-negotiate sizes from sender to receiver. Because of this behavior and the desire to be nice to serial connections, FFXI which primarily uses UDP, sends packets measured in hundreds of bytes, not thousands.

https://www.imperva.com/blog/mtu-mss-explained/

For TCP, IP Header is 20 bytes, TCP Header is 20 bytes, payload is 1460 bytes. For UDP we have a 20 byte IP header and 8 byte UDP header with the payload being whatever we want but minimum is 576.

Now there does exist a method of sending packets larger then 1500, it's known as Jumbo Frame which extends the MTU up to 9000 bytes, this is common when building 10Gb+ infrastructure, especially storage networks. FFXI doesn't use this and practically everyone's ISP and home network doesn't use this thus the practical MTU limit is 1500, not that FFXI really used that anyway.

true

true

the client is allowed to tell the server it's position because it would be far too laggy otherwise on a game designed for dialup, they *do* have server side enforcement and have since 2008-2009(look up the 'read me' gm and the autojailer), but don't use it aggressively because they don't want to sacrifice that many players

this isn't true, the server told the client the craft result when you kneeled down so it would know which animation to play, the exploit was that there were ways to interrupt the craft without losing materials

the client didn't tell the server what happened, you just interrupted the craft and retried until the server told you you got a HQ

the buffer the client stores incoming packets(post-decryption) and outgoing packets(pre-encryption) in is 3999 bytes, if you know half as much as you claim to know you could hop on ashita discord, grab an unpacked version of the client dll, throw it into IDA, and verify this for yourself

this means that when they decrypt the data and fill that buffer, the resulting data is 3999 bytes or less, it doesn't mean anything about what was actually sent(which is encrypted and compressed, so will be smaller)



this isn't wrong, but the ffxi client-server model won't send the next s>c udp packet until it receives the next c>s udp packet, if you read the recent threads about sheol-gaol prior to the fix, this was a major reason for the lost information (people with higher latency get less round trips, and a backlog of unsent data was accumulating resulting in the server logic discarding some of it)

they could change their server model to alleviate this, but they've shown no interest in doing so and we don't know how much work would go into it

duplicate packets are not a risk for item duplication, and most 'packets' as windower and everything refer to them are just a single instruction as part of a larger udp packet so you can actually send duplicates of them anyway

you are talking about broad knowledge applied across multiple games that you haven't verified is accurate for ffxi, i'm speaking of ffxi specifically, and you've not only tried to correct me using entirely invalid information but provided absolutely nothing new or useful

I have to agree with CPU here. This is just more technical jargon that you can hide behind instead of admitting that you’re wrong and have no idea what you’re talking about. It’s cute that you used your sockpuppet account “Saevel” to back up your unwarranted nonsense though.

Could yall, just, not

Now see what you did, you got dads attention

spiderman pointing meme.jpg

More or less every single one of their posts is an ad hominem shitpost. The account clearly only exists to stir ***without having to muddy the name of their main character.

I have my suspicions on who it might be since they didn't even bother trying to hide their usual grammatical errors and use of punctuation, but that's beside the fact.

Don't use socks to talk ***. If you're going to be an ***, at least have the courage to do it from your main.

Thank you. Exactly my point in my previous post.

Everything Thorny said has made sense here, the threading thing was the only part I was confused about.

CPU bringing up RAM in the context of buffer sizes makes no sense whatsoever, it has to do with the buffer allocated prior to sending/receiving (or before/after decryption). Most clients parsing and handling binary data will have a set buffer size or a range of possible sizes based on the operation/command being executed. I can't speak to FFXI specifically, but this is common practice wherever binary data is parsed. They aren't (or shouldn't) allow allocation of the entire virtual memory space for sending/receiving messages, there is no reason to when the size of the data structures being sent is known.

I would also assume that whatever header is prepended to each UDP message contains some measure of session tracking and that acknowledgement is built in, nothing would work otherwise. The server presumably assembles these messages based on the values in this header. Again, whenever handling binary data, this is common even when stateful protocols are used.

Comparing speed hacks to item hacks is completely off, also. There is always going to be some level of trust in the client, movement is part of that, since the client has to report movement back to the server. They could presumably verify movement speed and prevent movement hacks with some heuristics that determine if x user moves beyond a certain threshold, but this would (IMO) be buggy, in cases where users lag and messages are delivered at once. There is a dramatic difference between this and crafting, though.

There is no way the client informs the server of crafting results. That would indicate that all the logic and code for crafting existed client side, which would allow the client to dictate whatever results they want. Not only would that be entirely unnecessary, it has obvious implications for the game by allowing people to specify results from the client and they are smarter than that. This is also provable by loading the binaries into IDA or ghidra, I guarantee you'll find handlers for crafting responses in the client code, but nothing generating crafting results. There is no reason to allow the client to specify item results.

The network routers and the firewall protect the server from the bad data and the dupes.

How do they do that, exactly?

That would assume that the firewall and router could parse the FFXI network data and interpret it, along with maintaining state already maintained on the server. Good luck finding any firewall on the market that does that. They would have written it themselves, but that begs the question: why? Why go to the effort to implement a complicated network appliance that examines traffic, then informs servers if a dupe is detected, and act accordingly, when you could just offload all item handling and generation to the server. The effort of doing so is considerable when you could just do it right in the first place.

It is possible they have network appliances that detect invalid data in the sense of invalid CRCs or hashes, but it's extremely unlikely they have something actually parsing the FFXI protocol data and making decisions solely so they can continue to generate crafting/item results on the client. Since CRCs and hashes aren't used for security purposes in this context, these checks would purely be to detect malformed data or possibly dumb denial of service attacks, nothing more.

Man, I thought classical musicians argued about esoteric stuff like nobody else, then I met tech people. Y'all funny.

Hey, don’t try to get technical with me kid. This is all ones and zeroes. I happen to know that for a fact. Now where do you think it makes sense to stop the bad ones and the bad zeroes? After they’ve infiltrated your server and had their way with your data, *or* would it make more sense to stop them before they ever even reach your intranet?