Quote Originally Posted by ataro1 View Post
I've disassembled the routine that load the JNX files on GPS (starting from AlexWhiter work) and here i propose another version, that use a little numer of bytes and solve some not optimal thing in the jnx firmware patch.
This is the patch (Dakota 20, firmware version 580). Installed on GPS obviously works perfectly.
000CC7AC: D1 E0
000CC9F1: 00 01
000CC9FB: 7C 3F
000CC9FC: 4E E0
000CCAAE: D0 E0
00876F86: EF 7A
As in AlexWhiter patch, the first byte at address CC7AC bypass the Demo JNX handling. Differently from AlexWhiter patch, the second one at CC9F1 bypass the Garmin Hash CRC32 test result. The following 2 bytes at CC9FB bypass completely all the code written for JNX Signature test, and that solution are a little bit better respect original patch, because otherwise the remaining executed code in original patch call the memory heap routines to allocate and lock a zero lenght block of memory and than read from the JNX a zero lenght block of bytes. Sure that original patch is working, but i think that a more clean approch is better.
The last byte at CCAAE, like original patch, bypass the JNX Device Id test matching.
Thanks for sharing this!

You are correct, the current implementation of the patcher does not remove the unnecessary calls (in fact it does but only in firmwares for a couple of latest device models).

At first, I simply didn't care about optimizing the patched code - all I wanted was to make it work correctly
And now it's too late. See, if I change the replacement patterns in the patcher, it would be necessary to re-test the firmwares in all devices. That means a lot of error-prone work and possibly bricked GPSes.
So I prefer to make slightly better patterns for newly released devices, and for new firmwares where the old patterns refuse to work (from time to time Garmin makes more or less radical changes in the JNX loading routine).

I'll change the pattern used for Dakota in the next release of the patcher, so it will make the minimalistic code changes.


Quote Originally Posted by ataro1 View Post
We also can save 3 bytes of patch and the result are more simple to patch because no procedure call is involved (as into the original patch that implies to patch 4 bytes that change from a firmware version to another).
The patch won't be simpler, because no offsets are hardcoded in the patcher, the regular expressions search is made instead, and the call offsets are simply skipped in the patterns.