Ocarina

[biolizard89]

something I've never fully understood about cheat code engines is this:

If I move Arena1Hi (top of memory heap) down 32kb, wouldn't that push memory locations in the game down, thus making cheats which rely on patching specific memory locations fail by making them actually write over other values?

Example:
Lets say that Player 1 health for game X is at 0x817F0000 and is 4 bytes long.. I have a cheat to keep it at 99% full at all times which would write to that location 99 over and over. If I bump Arena1Hi down 32kb so I can reserve it for my stuff, wouldn't Player 1 health now lie in another location in memory?
So wouldn't the cheat engine all of a sudden try to write to player 1 health (but now is really at 0x817E8000) at 0x817F0000?

Or have I totally mistaken how clever a cheat engine actually is?

Hmm, well, if I recall correctly, the only addresses that change when you reserve the top of memory (in most games) are the FST (they shift down a constant amount). At least, it works for GCARS-CS, and I think Action Replay also reserves the top of memory. If nothing else, it will behave the same as the GCARS engine does in Swiss as long as you reserve exactly 32KiB of memory (which is what the GCARS engine does), so any AR codes that work in GCARS/Swiss will work this way too.

There are a few games that are known to complain if you mess with the top of memory (Starfox Adventures is one), but that's just due to the FST not wanting to be moved. I'm pretty sure that if you reserved, say, 1MiB of the top, it would change memory allocation or crash the game, but very few games actually store anything at the top 32KiB other than the FST, thus there's no reason for the allocator to do anything different.

[emu_kidid]

I'll make the move to the higher location then and implement Ocarina/Wiird support.

[Dragoon]

You are my hero dude
Well not yet, until I have a USB Gecko ofcourse :p

[WiiPower]

I was afraid of the same thing, which is why i hesitated to activate Ocarina on backups in NeoGamma, but apparently it works well. At least codes that relate to the fst will be messed up, but shouldn't be a problem for hackers to port. NeoGamma takes 16KB from Arena1Hi btw. when loading backups with Ocarina.

Because i can choose wheter to put the dvd read code at 0x80001800 or Arena1Hi, i can get Pokemon Box to work. But this is the only game i know of that NeoGamma gets to work this way.

[Hells Guardian]

Nope anyone that can run the debugger will quickly be able to search for the codes again. of course since we'd know a constant offset we could easily just adjust the code ever so slightly. the first 2 digits of an ocarina code tell us the code type and the next six are the offset in ram. the last 8 don't really mean anything for this point. bassically you add or subtract the offset to the 6 digits I mentioned and the code should be at the right location. if it doesn't work a quick search with Wiird would readily revealy the correct locations.

Did I mention I'm a code maker? It's one of the few things I have any talent at in the scene but hey I'm also just starting school here too....


Grand! I've been wanting ocarina support!

[biolizard89]

I was afraid of the same thing, which is why i hesitated to activate Ocarina on backups in NeoGamma, but apparently it works well. At least codes that relate to the fst will be messed up, but shouldn't be a problem for hackers to port. NeoGamma takes 16KB from Arena1Hi btw. when loading backups with Ocarina.

Because i can choose wheter to put the dvd read code at 0x80001800 or Arena1Hi, i can get Pokemon Box to work. But this is the only game i know of that NeoGamma gets to work this way.

GCARS-CS automatically modifies AR FST codes to compensate for the different addresses; Ocarina codes are slightly more complicated because of the ba and po variables, but it should be possible for Swiss (or NeoGamma, for that matter) to make a similar modification to codes. Or, as you said, they can be manually ported; it's just subtracting 16KiB or 32KiB from the address, so anyone with Windows Calculator can do it.

For reference, here's the code that GCARS-CS uses (credit goes to Fuzziqer):

Code: Select all

    //this fixes file-swapping codes to allow them to work with GCARS 
    codes = (u32*)GCARS_CODELIST;

    for (x = 0; x < codesactive; x++)
    {
        if (((codes[x * 2] & 0x01FFFFFF) | 0x80000000) > *(volatile u32*)0x80000038) codes[x * 2] -= 0x8000;
    }

[emu_kidid]

biolizard89, did you have similar code for Ocarina or are they much more complex as you say?

[biolizard89]

biolizard89, did you have similar code for Ocarina or are they much more complex as you say?

I don't have similar code, but now that I think of it, the same code should work fine, as long as you also verify that each line of code that you apply this to starts with a byte ranging from 00 to 05. This is because almost all FST codes use codetypes between 00 and 05, and in GameCube mode, those codes will be consistent regardless of the ba or po variables. If someone is bizarre enough to use other codetypes to write to the FST, then those codes will need manual porting, but I doubt you'd see any codes like that.

So yeah, just use Fuzziqer's code, but add an extra condition in the if statement, something like:

Code: Select all

    //this fixes file-swapping codes to allow them to work with GCARS
    codes = (u32*)GCARS_CODELIST;

    for (x = 0; x < codesactive; x++)
    {
        if ( ((codes[x * 2] & 0xFF000000) < 0x06000000) && ( ((codes[x * 2] & 0x01FFFFFF) | 0x80000000) > *(volatile u32*)0x80000038 ) ) codes[x * 2] -= 0x8000;
    }

(I haven't tested this code, nor even tried to compile it, so if I made a typo / error I take no responsibility.)

[WiiPower]

You could do this after reading the fst, so you would know which codes relate to the fst and which not. If the 2-4 byte are always offsets, you don't need to look at the code tpye. I think it would be best if hackers would port the codes they create in Swiss to the offsets Gecko OS uses.

[Hells Guardian]

I can confirm that the codes would be easy to adapt and as a staff member of GSCentral.org I'd be happy to rally a group of hackers to do this for the swiss users. besides I'd want to maintain use of the original engine for anything other than hacking new codes. Ocarina is nice but most GC codes are in raw or encrypted action replay format codes and for this reason it's easiest to use an engine that supports the code types with no further conversion needed. At least that's how I'm seeing it.

[WiiPower]

Well, when implementing the engine, i hope both (Ocarina only and Ocarina&debugger) code handlers will properly be implemented. At least to give the users the choice which cheat engine to use. Also i thought that Ocarina supports all kinds of AR codes, but AR doesn't support all Ocarina codes.

[Hells Guardian]

It does support AR codes however requires the use of a conversion tool to prepare Some codes for use on top of decrypting them. It's an easy process but still the current engine in swiss supports them as is in decrytped form I believe So I'd personally prefer to use it over ocarina for GC. The only reason I can find in adding ocarina is for the debugger. It's really a matter of personal opinion but the current engine also has no issues with codes that work with the FST and if that issue is fixed in ocarina then cool. If not I will just use the other engine for cheating in swiss. for debugging purposes the Ocarina engine is ideal.

[biolizard89]

It does support AR codes however requires the use of a conversion tool to prepare Some codes for use on top of decrypting them. It's an easy process but still the current engine in swiss supports them as is in decrytped form I believe So I'd personally prefer to use it over ocarina for GC. The only reason I can find in adding ocarina is for the debugger. It's really a matter of personal opinion but the current engine also has no issues with codes that work with the FST and if that issue is fixed in ocarina then cool. If not I will just use the other engine for cheating in swiss. for debugging purposes the Ocarina engine is ideal.

As a hacker, I really prefer the Ocarina code types; something like GeckoTunnel would be a major pain in the rear to implement using AR code types, and GeckoTunnel needs the expanded code list space of the non-debugger Ocarina engine.

You say you're a staff member at GSCentral? Do you have access to the AR code database there? It would probably be fairly easy to run that database through James0x57's AR to Ocarina converter, at which point the resulting codes could be posted on the GeckoCodes database (meaning that they would show up in Accio Hacks and be downloadable as TXT/GCT files, so no code entry or manual conversion would be necessary).

It's probably also possible for emu_kidid to ask James0x57 for the source code to the converter, so that it could be run on the GC side when loading codes.

Just my $0.02.

[Hells Guardian]

I do not have access to the DB. My domain is the message boards. Rune is currently the only GSC.org member with the password for the data base. He likes to keep it under wraps so that no one is ripping off our database again like the BSfree website that sprang up hosting a stolen copy obtained by an attack on the main page... either way I can check with rune and see if He would be against at the very least hosting a converted code page for users to obtain the ready to use codes on GSC and expanding accio hacks to check the GSC pages too. I'm sure James would be for that if Rune won't let the GC AR DB be copied to Gecko Codes... Thanks for the Idea. I'll start sending a few emails and see if this can't be arranged in some way.