ROM Hack Developing EZ Flash IV client replacement, undocumented header patch? Help please.

[foobar_]

Old, I know, but I recently bought an EZ Flash IV, and I'm in the middle of developing an alternative EZ Flash 4 client, to replace the crappy one they provide you with.

I've managed to replicate the official EZ4 client's SRAM patching, but I've noticed a discrepancy between my patches and the official client's behavior: the official client modifies the header in a strange way.

Here's a screenshot (the game is Tony Hawk's Pro Skater 2):

That's the only difference between my output and the official client's output.

While my patched game runs on my EZ4, it doesn't automatically save when I turn off and turn on the console. The official client's patched game saves fine. Stranger still, is when you uncheck both the "reset" and the "save" patch options on the official client, this header patch will still be applied.

According to GBATek, the header is modified in two areas, one in the reserved area (for which I've found no documentation on), one in the complement check. The header patch is different for each game, but I don't know how it's generated.

I can take care of the complement check, but how is the reserved area patch generated? And out of curiosity, what significance does the reserved area have? If anyone more knowledgeable can shed some light on this I'd appreciate it

 

[FAST6191]

Odd, I did not see that when I reversed some of the patches a while back though I was more concerned with GBATA patches at the time*. It should have no bearing on the nature of saves either, GBATA and everything else should leave it untouched and they worked fine (even making up for shortcomings) assuming you manually created a save file for the game. Worse I have seen problems with the NOR when various areas of header around there were patched (I guessed it used those 00 values as a section end for a read or something, common enough in C family stuff) and it would not display the ROMs when written to the NOR.

What version of EZ4 are you testing with (older style or the 2013 model being the two distinctions as far as I am concerned here)?

*the wordy version of the resulting method was run a ASCII search for SRAM, FLASH or EEPROM, if you are doing proper patching (necessary for flash carts, VBA was less interested) then read the following bytes to figure out sub type, use sub type to direct two patches a few bytes further ahead (the difference in spacing between said patches being the only different as the patches themselves were the same between versions, though likely being SRAM unlock codes and write commands/width limits that is hardly surprising. I stopped short of playing with assembly and reading SRAM datasheets for this one) and you have your save patching. Sleep, soft reset and cheats were slightly more tricky but the former two are largely solved problems as well (kuwanger should have some nice python code you can look at).

As far as I am aware the reserved area means nothing, reserved areas have been used on other consoles (the DS later used one of its reserved areas in the header for signatures to avoid having to update the DSi and 3ds whitelists all the time, it is why we got a bunch of largely pointless redumps).


No argument that the client is a clunky piece of junk but punch it hard enough and it usually works fine. What was the straw that broke the camel's back?

 

[foobar_]

I've got the older version (assuming the 2006.03 on the circuit board is year/month) of the EZ4.

It seems the official client uses the reserved area to store something specific to the EZ4, VBA doesn't care about it at all.

I made a mistake, the header is modified in 3 areas, not 2: reserved area, software version, and complement check.
From my testing, the software version appears to have something to do with the save file size: click (all tested with EZ4 patched roms). Super Mario Bros (J) is an exception, however. Although it doesn't seem to matter what you change the software version to, as long as the reserved area patch is correct, the game will auto save normally.

I got a lot of roms I want to swap on/off my mini sd card, and 2GB isn't enough to store them all.
The official EZ4 client crashes when I try to transfer more than ~15 roms at a time, it gives them weird file names, and sometimes there's a rom with an ID that's not in the EZ4's database. It then decides to rename the rom to ".gba", no filename, only extension. Transferring multiple non-database searchable roms causes the ".gba" file to be overwritten multiple times with different roms, and I have no idea which ones were missing from the transfer. The only safe way to transfer roms is to add them in one by one, then manually rename them. Really drives me crazy. Not to mention both the EZ4 client themes are extremely ugly...

On the plus side, having my own client code is useful for cross-platform purposes. It's also a great learning experience; one can never know too much.

 

[FAST6191]

The PCB datestamp on the mash did not change at all from what I have seen. If you got it recently then chances are it is the 2013 edition, the main difference seems to be a new NOR chip which needs new loaders.

If you downloaded the client from ezflash.cn then you might prefer the version I put together http://filetrip.net/nds-downloads/flashcart-files/download-ez4-client-2009-04-03-f31119.html
If nothing else it should have a more complete database with it.

I can see using junk areas of the header to store info. Nothing jumps out at me on the changes there but my guesses would be something along the lines of pointer to save, soft reset or something along those lines (it is only 6 bytes rather than 8 I know but many GBA addressing systems will do things like this if the address is always going to be 02XXXXXX or 08XXXXXX or something along those lines -- see a lot of cheats, granted most sensible permutations of that would have it outside the onboard RAM).

 

[Kompot]

Hello,
Seems that algorithm of patching rom - commercial secret.
You can try reverse engineer EZ4Patch.dll or just call some methods from that lib to patch rom. There are no documentation at all.
There are few useful links:
http://sosuke.com/ezflash/viewtopic.php?f=12&t=890 - thread about alternate client
http://sourceforge.net/projects/ez4clientplus/ - unfinished alternate client

 

[Kompot]

You can use some dll tracer and dll methods extractor utils for understanding EZ4Patch.dll lib.
For example:
DLL export viewer for getting methods signatures:

and API Monitor for tracing EZ4Patch.dll calls and parameters:

 

[migles]

hope this still is in development, the ez client for me only works when sending the games (reset patch never work, it crashes when changing reset keys options) at first time it didn't patched well my zelda rom (the cartridge did get really weird when trying to save random characters appearing on screen, really long time to save, but after another tries i managed to make it work)

 

[foobar_]

Hello, it's still in development, but on hiatus currently, as I have other projects I want to work on first. The basic functionality is there, just a few kinks to iron out and the reserved area patch, which I still haven't figured out. I've tried interpreting the reserved area patches as addresses as FAST6191 suggested, but I still see no discernible pattern. I'll have to take a look at those links though, they seem interesting.

If those links don't explain the reserved area patch, then this will be my first adventure into the world of reverse engineering. If this is the case, there will be a lot for me to learn here. Wish me luck.

 

[FAST6191]

moledj's stuff was mainly focused on the DS and still used the EZPatch.dll or whatever it was -- the EZTeam did actually send him a function list and how to call them for the DS.