Welcome guest, is this your first visit? Click the "Create Account" button now to join.
Results 1 to 10 of 13

Hybrid View

  1. #1
    Member
    Join Date
    May 2010
    Location
    None
    Posts
    16
    Rep Power
    0

    Default

    I've just read that rgn 41 are the Non Volatile Memory with personal data.
    But i've read also that rgn 5 and 43 are linked to the boot.bin of the GCD. I think that this are not true, because rgn 5 are only a little bit smaller than boot.bin, and the code of the two binary files are so different ....
    Last edited by ataro1; 4th May 2015 at 12:10 AM.

  2.    Advertissements


  3. #2
    Member
    Join Date
    May 2010
    Location
    None
    Posts
    16
    Rep Power
    0

    Default

    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.
    Code:
    Please Login or Register to see the links
    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.
    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).

  4. #3
    AlexWhiter
    Guest

    Default

    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.

  5. #4
    Member
    Join Date
    May 2010
    Location
    None
    Posts
    16
    Rep Power
    0

    Default

    Quote Originally Posted by AlexWhiter View Post
    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.



    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.
    I'm happy that You decide to implement my code in Dakota 10/20 JNX patch. You are a big, as big are your huge work.

 

 

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •