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:
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:
So it looks like this is the code that displays the message of interest. Good luck
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.
Last edited by kunix; 4th September 2012 at 09:56.
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:
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?.
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).
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.
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.
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.
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.
Last edited by kunix; 6th September 2012 at 17:07.
Hello, I do not know that Memory disassemble the boot.
I can use the same script.idc to boot?.
boot.bin is just an extremely small firmware. On most devices it even shares the same loading address with fw_all.bin.
But be careful with patching it, as boot.bin contains the bootloader and, sometimes, the x-loader and it flashes them on some conditions. If the bootloader or the x-loader crashes then the device is 'bricked' and can't be recovered without unsoldering the flash chip. So if boot.bin crashes while flashing the bootloader or the x-loader, it corrupts them and bricks the device. That's why we should be careful while patching boot.bin.
Originally Posted by haute
Thank you very much for your help .... not many people who enjoy this.
I hope to find someone with the same interests as me