Sooo...kings camps since yesterdays little patch

[divisortheory]

Well, first, assembly does have a concept of functions, except they're called procedures. If some sort of indication exists where these procedures were defined (i.e. the "proc" and "endp", or at least the transitions from .data to .code and back, in assembly were encoded when it was compiled, and not simply substituted directly in where they were called), you could at least identify partitions in memory between one procedure and another.

You're confusing assembler directives (e.g. MASM/TASM/etc keywords) with actual assembly language. When the assembly code is translated into binary numbers, there is no such thing as "proc" and "endp". Those are merely directives to the assembler about what calling convention to use, which then dictates the real sequence of instructions that will end up in your code. The assembler transparently converts things like proc and endp into a sequence of "actual" assembly instructions. for example it might convert the C function

void f(int x, int y, int z) {}

into the assembly language

push ebp
mov ebp, esp
sub esp, 12

(for example). That's what your "proc" is translated into. Sinec I assume FFXI was not written in assembly language, but rather in C or C++, it gets even more compliacted because it can optimize things, or you might use a different calling convention. The important thing is that there is nothing in that sequence of code about the name of the function, there is nothing there about the arguments, there is nothing there about anything. It's just a sequence of instructions that starts at some address, an address which the compiler/assembler hardcodes into the other areas of the programs that call this function. It is theoretically impossible to tell in general where "functions" start and end, because again there simply isn't such a thing as a function in assembly language.



The other things you mentioned are definitely areas of investigation, my point is simply that all of them would be very very difficult, and as one previous poster mentioned about "it takes 5 minutes to update memlocs", this would definitely no longer be the case, and people would be out of comission for quite a while after every udpate until the developer fixed his app, and eventually he would get so sick of having to go through this difficult heuristic process of finding the new values each time that he would probably abandon the project.

I was just thinking you could look at inputs/outputs/algorithm type identifiers to make it easier to locate.

Yea, there's definitely ways for someone to proceed if SE were to do this, the thing is just that it's so little work for SE to do this, and it makes things orders of magnitude more difficult for the people who are trying to use bots. The only conclusion I can really come to is that SE doesn't care. If they did care, they would allocate these structures dynamically. If/when someone figured out how to get around that, they would figure out how that program works and attempt to implement further measures to prevent this kind of behavior. It isn't a lot of work for them, and it could potentially be a ton of work for the hacker.

[Nagamaki]

I watched AV a bit last week-end and "killable mob" isn't what came to mind.

Locking 2hours seemed to work, but its pretty difficult to keep them all locked, and even without 2hours it still has instacast Tornado II, Aero V and Aeroga IV not to mention a very sick Regen. -ga is obviously the biggest single danger, but things like AoE stun/def down or AoE silence combod into instacast nukes = instantly dead tanks. Would stacking enough wind resistance gear work for turning death spells into insignificant damage? Maybe, I didn't really check the tanks, but they're well aware of what resistance gear can do so I would guess they at least tried.

[Omalika]

I watched AV a bit last week-end and "killable mob" isn't what came to mind.

Locking 2hours seemed to work, but its pretty difficult to keep them all locked, and even without 2hours it still has instacast Tornado II, Aero V and Aeroga IV not to mention a very sick Regen. -ga is obviously the biggest single danger, but things like AoE stun/def down or AoE silence combod into instacast nukes = instantly dead tanks. Would stacking enough wind resistance gear work for turning death spells into insignificant damage? Maybe, I didn't really check the tanks, but they're well aware of what resistance gear can do so I would guess they at least tried.

If there is some way to "lock" SP perhaps there is some way to lock Magic aswell?

[BRP]

Most theories that make sense don't get tested.

[nivlakian]

Most theories that make sense don't get tested.

Like which ones?

[BRP]

Popping (tier 2) Jailers while he is out and holding them.

[Krandor]

How the hell does that theory make sense?

[Kaylia]

Popping (tier 2) Jailers while he is out and holding them.

Cant tell if its serious or sarcastic, but i lol'd

[Seebo]

Popping (tier 2) Jailers while he is out and holding them.

I hope you're being sarcastic -.-

[aurik]

How do you "find the code signature" of a function (if that function is not exported from a DLL)? Everything looks the same in assembly language. I'm not saying it's impossible to write a bot that works with dynamic memlocs, but with even half a brain the developers can make it so hard that it's probably not worth it for anyone to waste their time on. With static memlocs its trivial.

The same way virus scanners find viruses.

Unless SE rewrites those functions with every update, there will be a string of code somewhere that remains the same. Look for that exact string each time, and establish your reference point.

They would only have to change the function ONCE after switching to the dynamic memory allocation scheme. At that point I don't know how you would ever find it the first time in order to be able to record the first few bytes of the function so as to be able to scan for that sequence of bytes in the future. And it wouldn't matter anyway, with each update they could scatter a few "nop" instructions throughout the function and the naive byte search approach would fail.

Sorry for being late in responding, I was stepping through powerpc assembly code all afternoon

Very simple to look for a function that doesn't change. When you compile a function it will turn into a series of bits. Identify which bits in that function are generally the same from compile to compile (hint: stuff like opcodes, constants, etc) and just do a memory compare. For example, a certain function might have the characteristic of having the first 32 bits, then skip 5 bits, then the next 27 bits, then skip 50 bits, then the next 16 bits always match the exact same thing. This characteristic is the "signature" of the function. If you know that the pointer to the correct memloc is the value at (for example) 16(SP), all you need to do is intercept the memory at 16(SP) during the function and you're golden.

If you're really feeling fancy you could even cleverly detect nops and skip over them. Like regexes, except you're doing it on binary data.

It's a ton more sophisticated than current mrargus which basically just scans predetermined regions and pokes data in random locations which happen to (or after an update happen not to) work. But it's definitely doable.

And yea they could foil you pretty good by just re-ordering the parameters for compromisable functions every time they patch the game, but that would require real effort on SE's part and would probably cause a lot of bugs in general.

[nivlakian]

Popping (tier 2) Jailers while he is out and holding them.

I expected that reply from you because it seems to be the only thing you ever say regarding this.

I'm not sure how you believe that this theory is more valid than the others. Most likely, it's not tried due to the number of people it would take to hold a tier 2 jailer and deal with AV simultaneously as well as getting the extra pop items. The theory is just rediculous even if it were to be true.

You said "most theories", surely there were others?

[Turtlesoup]

Popping (tier 2) Jailers while he is out and holding them.

I expected that reply from you because it seems to be the only thing you ever say regarding this.

I'm not sure how you believe that this theory is more valid than the others. Most likely, it's not tried due to the number of people it would take to hold a tier 2 jailer and deal with AV simultaneously as well as getting the extra pop items. The theory is just rediculous even if it were to be true.

You said "most theories", surely there were others?

Teh ebon panelz !111

[Suiram]

We sent someone to the ebon panels while fighting AV once. I don't know what he saw there, but now he won't come for AV anymore.

[Tymon]

We sent someone to the ebon panels while fighting AV once. I don't know what he saw there, but now he won't come for AV anymore.

made me almost fall out of my chair

[divisortheory]

Very simple to look for a function that doesn't change. When you compile a function it will turn into a series of bits. Identify which bits in that function are generally the same from compile to compile (hint: stuff like opcodes, constants, etc) and just do a memory compare. For example, a certain function might have the characteristic of having the first 32 bits, then skip 5 bits, then the next 27 bits, then skip 50 bits, then the next 16 bits always match the exact same thing. This characteristic is the "signature" of the function. If you know that the pointer to the correct memloc is the value at (for example) 16(SP), all you need to do is intercept the memory at 16(SP) during the function and you're golden.

By "function signature" I assumed you meant the unique identification of a function based on its name, return type, and argument list. But yea, you could look for "patterns" in the sequence of code bytes that either exactly match or are vaguely similar to some known "snapshot" that you've taken. Just that you you will quickly start getting into the realm of what is and isn't deterministic, and the x86 instruction set is ridiculously complicated, you would basically have to write your own entire disassembler for it to be feasible. The complexity of this algorithm to find the dynamic memlocs would explode with each very minor attempt by SE to thwart the hackers.

If you're really feeling fancy you could even cleverly detect nops and skip over them. Like regexes, except you're doing it on binary data.

This would be impossible without implementing your own disassembler, because x86 opcodes don't have a fixed length like they do on many other architectures. So the "nop" opcode can actually appear in the middle of another opcode, and the only way to detect a true "nop" would be to diassemble everything to make sure you know the opcode boundaries.

but that would require real effort on SE's part

This is the main reason it won't happen. It's unfortunate though that it would take about an hour on their part to do this in its crudest form, and it would be more effective than anything else they've done to date (which is very little).

[Raineer]

We sent someone to the ebon panels while fighting AV once. I don't know what he saw there, but now he won't come for AV anymore.

l m a o

wins the internet

[ikariffxi]

We sent someone to the ebon panels while fighting AV once. I don't know what he saw there, but now he won't come for AV anymore.

lol

[JoOeetheplatypuS]

We sent someone to the ebon panels while fighting AV once. I don't know what he saw there, but now he won't come for AV anymore.

holy shit lmfao

[aurik]

Very simple to look for a function that doesn't change. When you compile a function it will turn into a series of bits. Identify which bits in that function are generally the same from compile to compile (hint: stuff like opcodes, constants, etc) and just do a memory compare. For example, a certain function might have the characteristic of having the first 32 bits, then skip 5 bits, then the next 27 bits, then skip 50 bits, then the next 16 bits always match the exact same thing. This characteristic is the "signature" of the function. If you know that the pointer to the correct memloc is the value at (for example) 16(SP), all you need to do is intercept the memory at 16(SP) during the function and you're golden.

By "function signature" I assumed you meant the unique identification of a function based on its name, return type, and argument list. But yea, you could look for "patterns" in the sequence of code bytes that either exactly match or are vaguely similar to some known "snapshot" that you've taken. Just that you you will quickly start getting into the realm of what is and isn't deterministic, and the x86 instruction set is ridiculously complicated, you would basically have to write your own entire disassembler for it to be feasible. The complexity of this algorithm to find the dynamic memlocs would explode with each very minor attempt by SE to thwart the hackers.

If you're really feeling fancy you could even cleverly detect nops and skip over them. Like regexes, except you're doing it on binary data.

This would be impossible without implementing your own disassembler, because x86 opcodes don't have a fixed length like they do on many other architectures. So the "nop" opcode can actually appear in the middle of another opcode, and the only way to detect a true "nop" would be to diassemble everything to make sure you know the opcode boundaries.

[quote:7bd44]
but that would require real effort on SE's part

This is the main reason it won't happen. It's unfortunate though that it would take about an hour on their part to do this in its crudest form, and it would be more effective than anything else they've done to date (which is very little).[/quote:7bd44]

It's actually not that much work to come up with a good signature for a function if you know what you're doing in a debugger. Then you're just doing a few million byte comparisons when your app starts. You hardcode the stuff that you want to find (like "give me SP when PC=0xdeadbeef") and use pattern matching to fill in the right PC for 0xdeadbeef. And yea it would be dead easy to foil Just find the function that the hacker is attaching too and reorder the operations and reorder the parameters.

As for nop detection, all you need is a function which references the length of an opcode to the first few bytes. If you're in a segment of interest (ie, it matches the pattern of the function so far) just look at the current bits which you "think" is an opcode and if it looks like a nop, just advance by the number of bits in a nop.

I'm not terribly familiar with x86 (I work mostly with PPC assembly, and only very reluctantly) but there simply must be a deterministic (and simple) way to determine "given that an instruction starts at memory location X, how long is it?" Yea, you will get misaligned a lot, but it's not a critical flaw: it just means you'll fail the pattern match.

That said, why would someone bother writing such a complex piece of code when, if they had that kind of programming ability, they could be making 6-figure salary as an engineer, and then just buy gil to get what they want

[divisortheory]

I'm not terribly familiar with x86 (I work mostly with PPC assembly, and only very reluctantly) but there simply must be a deterministic (and simple) way to determine "given that an instruction starts at memory location X, how long is it?" Yea, you will get misaligned a lot, but it's not a critical flaw: it just means you'll fail the pattern match.

That said, why would someone bother writing such a complex piece of code when, if they had that kind of programming ability, they could be making 6-figure salary as an engineer, and then just buy gil to get what they want

lol, although admittedly it would be a fun exercise. You kind of can't figure out the length of the opcode without exhaustively searching the entire opcode map for the instruction set. I'm actually in the process of writing a disassembler / PE file editor so this is the type of crap i've been learning lol. If you know how long the opcode is, you've looked at enough information already to completely disassemble it. Hence my comment about writing a disassembler. There's probably more complex instruction sets out there, but I sure as hell can't think of one. Go look at the instruction set reference manual for the instruction "MOV". That instruction alone has about 15 different possible ways of being encoded.