How To Port "Long" Assembly Codes

You may have wondered when looking at an assembly code C0 or C2, how to port it. You might know how to port a C2 code, same as a direct RAM write, but did you know there are sometimes hidden addresses within the code?

Let's begin!

Infinite Health Campaign [Seth@WiiPlaza]
C0000000 00000004
3D606A6A 3D8080B3
398C7999 616B6A6A
916C54C3 4E800020
4E800020 00000000
E0000000 80008000

Here we have Seth@WiiPlaza's code, Infinite Health Campaign (SM8E52). So, where's the address? It is different than direct RAM write codes and the F2 codetype where the address is shown in red below.

No Flash White [Bully@Wiiplaza]
F2355964 FCCB2801
38000000 00000000

In Seth's code, the address is in the assembly itself.

C0000000 00000004
3D606A6A 3D8080B3
398C7999 616B6A6A
916C54C3 4E800020
4E800020 00000000
E0000000 80008000
Whenever you see an 8080, most often after 3D, it is an address. Depending on whether it is on the right side or left side of the code will determine where the second half of the address is.

If you see it on the left, it will be the last 4 digits on the right.

3D808012 XXXXYYYY

Where Y is the second half of the address.

If it is on the right, it will exactly as shown above.

Now, let's put together the address:

C0000000 00000004
3D606A6A 3D8080B3
398C7999 616B6A6A
916C54C3 4E800020
4E800020 00000000
E0000000 80008000

3D606A6A 3D8080B3

>>80B3<<

The start of the address is on the right side, so go to the next line.

398C7999 61B6A6A

It was on the right, so this will be on the left, the last 4 digits.

>>7999<<

80B37999

Great! Now we have our address.

Open up HxD and the dump of the region of the game this code is for, and the dump of the region you want to port to.

Go to this address. Copy a bit of bytes, and search for them in the dump you are porting to. Once you find a good comparison, it is most likely a correct port. Now, all there is to it is to put the new address back into the code.

Let's say the new address is 123456.

Infinite Health Campaign [Seth@WiiPlaza]
C0000000 00000004
3D606A6A 3D808012
398C3456 616B6A6A
916C54C3 4E800020
4E800020 00000000
E0000000 80008000

It's as simple as that.

Thanks to Bully telling me this, you can use ASM->WiiRD, which is included with Gecko dotNET, to see if there is an address within an ASM code by seeing if there is a large number. A simple look at the code can tell you this though, as I have shown you above. This is a neat trick though, which does come in handy if you aren't too sure.



And that's pretty much all there is to it.

Sorry, if the tutorial is not really written good. I've had very little sleep the past week, 2 hours at most a night.

Anyways, hope you enjoyed! Get porting, bud!

Good job, all correct. I also love how code stealers got confused when they couldn't see the address so easily due to a C0 code being used.

One more thing: I was working on a new code porter for offsets with many options and better speed. Maybe it will help you once it's done and released.

That's a very interesting, and very well-developed program, I must say. That's a great job you did on it.    One thing I've had trouble with on some games, particularly the Call of Duty series is you get lines like this:

80 E7 EF F4 88 07 00 18 2C 00 00 00

The address's value changes slightly on some bits in other dumps.
For example, it could be 88 05 03 24. As you know, in HxD there's no option to include placeholders with "wildcards". For example, your program could ask the user if they want to include placeholders. A dialog opens up and they can see the memory of at least 30 bits up and down, that they can scroll through, and choose which bits to include in the "wildcards" placeholders. It would give the program just an extra way of searching for the correct offset.

That's just my tip.  

SnB@BWH wrote:As you know, in HxD there's no option to include placeholders with "wildcards". For example, your program could ask the user if they want to include placeholders.

The porter will not look for default values to be equal at all. It only tries to find search templates to locate the possibly correct offset/memory region/function.

Also, it supports placeholders but only in the search template. I called it "maximum allowed byte failure count" which lets you specify how many bytes are allowed to be wrong in the search template to still find the offset. Maybe this options is pointless but better more options than less.

If you can tell me some examples I can use to test the tool better, that would be useful.
Then I'm almost ready to release it when it's fully done.

That's good that it uses search templates, instead of default values for match findings. This is especially good for codes, like the one I ported earlier, your Wallbanger Aimbot code, because the default value is different for Spec Ops and Zombies. I had to rely on my own skills and knowledge, instead of default value matching, which regularly, is the most common way for finding the corect offset.

What exactly do you mean by search templates though, like rules or a custom following of certain values or ranges?

One thing I could suggest is making a rule for the program, if you haven't already, to only deem a match if it is within close range of address in memory to the source offset. For example, if it finds a match at address 0x80254EB8, yet the source offset is 0x80598CD8, then it will skip over that "possible" match. It is pretty well impossible that the correct offset would be that far in memory from the source / destination dump.

SnB@BWH wrote:One thing I could suggest is making a rule for the program, if you haven't already, to only deem a match if it is within close range of address in memory to the source offset. For example, if it finds a match at address 0x80254EB8, yet the source offset is 0x80598CD8, then it will skip over that "possible" match. It is pretty well impossible that the correct offset would be that far in memory from the source / destination dump.

Right, I already made this feature. However, on other systems (not the Wii), having such a big offset is actually legit sometimes. Lately I like to make universal hacking utility tools in C++, something you can use as an all time classic regardless of the system you're "hacking". Hence, you can configure them to your liking but they lack specific features like handling codes or understanding which RAM is assembly and which isn't.

Right on. I know that on the NES, it is pretty easy to tell what's assembly and what isn't... if it's below 0x8000, it's regular RAM, if above, it's assembly, lol Remember a while back, you said it would be useless to create a PPC to Hex conversion chart? Would it still be useless, at least in the sense of coding it into the program for differentiating? I'm just thinking of some ideas that could be utilized in that sense.

SnB@BWH wrote:Right on. I know that on the NES, it is pretty easy to tell what's assembly and what isn't... if it's below 0x8000, it's regular RAM, if above, it's assembly,  lol  Remember a while back, you said it would be useless to create a PPC to Hex conversion chart? Would it still be useless, at least in the sense of coding it into the program for differentiating? I'm just thinking of some ideas that could be utilized in that sense.

I did this before but you can analyze the memory bytes and determine if it's likely assembly or not. How exactly is a mystery or to be researched lol. But for the porter it does not matter, it will grab "random" search templates and try to port the offset repeatedly till it seemingly succeeded (e.g. both memory dumps only have 1 instance of the search template found).

I had the idea to include a disassembler in the program so it can look at the assembly directly but I didn't know how to make good use of it, yet. Maybe to find better templates? But that's also kind of redundant besides maybe speeding up the porting sometimes.

For strings (alphabet), you could match each left-most char of a byte in a sequence to either 5, 6, or 7. If the right-most char of 5 or 7 does not exceed "A" in a sequence, it is most likely a string, and not a value or assembly. But other than that, I don't know... yet. You can look at the disassembly of a dump, and know what's assembly and what's a value. It's just getting the computer to know what we know.

SnB@BWH wrote:For strings (alphabet), you could match each left-most char of a byte in a sequence to either 5, 6, or 7. If the right-most char of 5 or 7 does not exceed "A" in a sequence, it is most likely a string, and not a value or assembly. But other than that, I don't know... yet. You can look at the disassembly of a dump, and know what's assembly and what's a value. It's just getting the computer to know what we know.

True but what does it accomplish? We don't care which search template the porter uses. It will just keep trying till it succeeds. To know what is what, it would be easier if it's a certain file format like an EXE. Then I could parse the structure. But for a simple offset porter I don't want to do this, it would be a lot of effort for little gain and it destroys generality (e.g. it would need its own structure parsing for each console, file format etc. which is completely unrealistic).