Garmin eTREX 20 working as an eTREX 30

AlexWhiter · 4th September 2012, 04:11 AM

kunix,
What haute wants to do is to remove the check for the currently installed firmware version, so the device would flash any GCD file independent of the FW version, and without any prompts.

**kunix** · 4th September 2012, 09:45 AM

haute
Here are a few hints for you. All info below is for valid eTrex 20 firmware version 2.80.
eTrex is a multi-language device, so localizable strings won't be referenced directly from the firmware. Instead, some code will be used when referencing strings. And indeed there is a function for loading localizable strings which takes an integer as a string index:

Code:

Please Login or Register to see the links

There is a default English locale, which is the only locale contained in the firmware. The string of interest at 0x 80845EF8 is a part of the English locale.

Code:

Please Login or Register to see the links

Also there is a list of tags used for loading localizable strings from localization XML files:

Code:

Please Login or Register to see the links

The tag of interest is the following

Code:

Please Login or Register to see the links

The corresponding string index is (0x80841834-0x808413BC)/4 = 0x11E.
Then I suggest disassembling the firmware by issuing disasm(0x80100000,0x803C0000), which is defined in the following script: [Only registered and activated users can see links. ].
After that I suggest searching for text "0x11E" (Alt-T). Then we can find where integer constant 0x11E is used for loading strings:

Code:

Please Login or Register to see the links

So it looks like this is the code that displays the message of interest. Good luck

P.S.
Also I think this way of searching for particular peace of code isn't universal, as some localizable strings may be referenced by data structures defining complex windows, and not the firmware code itself. Even worse, these data structures may be constructed dynamically.
I don't know how complex windows are displayed in tourist devices, so maybe AlexWhiter will shed some light on it.

haute · 4th September 2012, 02:57 PM

Kunix Hi, thanks for the explanation of the tag list. You've explained it well enough for you to understand me. I have no knowledge of language C, C + +, only some asm and Basic language. I come from the era of Amstrad 464 and 6128.

I tried your script idc apply, but I get an error: Variable "SEARCH_DOWN" is undefined. I set the variable in the script: # define SEARCH_DOWN 0x001, but I get another error variable definition: Variable "BADADDR" is undefined.
I think I need to add something to the IDA Pro.
I tested in versions 5.5 and 6.1 of IDA Pro. Little endian 32bit ARM. I get the same error.
I have a lot of disassembled code, but not everything is complete. What I did with Ctrl + U and C, I have worn fingers, lol. The script would do the job easier for me I guess. I have not well linked the TAG list, only the top of the table is connected, the rest of the table nothing.
The script will connect well all tag list?.

A greeting.

AlexWhiter · 4th September 2012, 02:48 PM

I'm afraid I don't know how the message output is made in the code.

But there is a couple of other things to try to search in the firmware.
At first, there are the references to the current FW version. For eTrex firmware version 2.80, the version WORD is located at 0x807d904e. I could only find the following refs to the version:

Code:

Please Login or Register to see the links

Near the latest offset, there's also ANSI string "&updt_lock_smphr", which is rather interesting.

Another option to try is to locate the "GUPDATE" strings. Again, there are only several strings in the firmware:

Code:

Please Login or Register to see the links

**kunix** · 4th September 2012, 04:24 PM

I'm sorry, I've extracted this script from my big IDC file and forgotten to add #include <idc.idc> at the beginning.
The script won't take care of the tags. But why do you need it? Press SHIFT-F12 and you'll get all the tag strings there. Or look for the tag string of interest using Alt-B.
Then you can find the tag table entry of interest by searching for the tag string address (Alt-B).

haute · 6th September 2012, 01:20 AM

Thanks Kunix, as if by magic the disassembler with the script is much easier, I will keep my fingers footprint, hehe.

Regarding the function you said, for many laps I'm giving, not think it's the screen showing the text: TXT_New is older software etc ... ".
The other code that surrounds him is not very logical.

I searched other texts related to above as:
0x47c TXT_updating_gps_Firmware_str_m
0x487 TXT_validating_update_str_m

And I can not find anything. And these two sentences would have to be closely related to the previous one.

I tried to follow the advice of Alex and I can not fix it.

ArgG .. I feel sorry .....

**kunix** · 6th September 2012, 07:07 AM

It's always hard to disassemble GUI code, as it's huge and messy. Also I've tried to start from GCD parsing algorithm but found nothing.
I think AlexWhiter's advices are good. The following place seems to be the only one where SWVR is tested for being less or more than some integer. Also there is a reference to GUPDATE string in the BLS branch. So try to replace BLS at 0x80113B50 with B and replace BNE at 0x80113B6A with B and see what happens.

Code:

Please Login or Register to see the links

UPD:
And, actually, there is a connection with GCD parsing code: 0x80113BA8 -> sub_801136A2 -> sub_8029D7D4 -> sub_801B9D60.
sub_801B9D60 is a GCD parsing and flashing routine.

haute · 6th September 2012, 04:45 PM

Indeed you have come to the right routine, but not easy patch it, because it makes multiple passes through the same routine in the update. And if it gets patched in a loop.
The routine checks if there is an older firmware or newer and performs the update in both cases, matching up the firmware version and then delete the file gupdate.

Would have to install a counter, which always perform the update once, the second time would enter the comparison function normal, and logically verifying the same firmware version installed and gupdate file.
Do not know if it will be worth.

**kunix** · 6th September 2012, 04:56 PM

Wait.... isn't it enough to delete GCD files of the same firmware version? Just don't patch BNE at 0x80113B6A and maybe that's it? I think it's necessary to delete GCD files, because no one else is going to delete them. And you can't delete GCD file you want to flash because it's not firmware who flashes it, the firmware only passes control to boot.bin from the GCD file. So you can delete the GCD file only after it has been flashed. This is why BNE at 0x80113B6A is absolutely necessary and shouldn't be patched.

UPD:
I think that if you really want to flash any GCD file flawlessly, then you need to:
1) set firmware version in the GCD headers to be as high as possible (99.99 is good enough

)
2) patch boot.bin inside GCD file to delete the GCD file after flashing.
This method is better because no patches are required in the old firmware. And you don't have to deal with GUI code when patching new devices. But boot.bin patch is probably tricky, as you need to add a new function call.