Thread: Garmin eTREX 20 working as an eTREX 30

hello.

This is a comparison of the PCB of the two models of Garmin GPS Etrex 20 and 30.
As you can see, the Model 20 has no more sensor if they are in version 30.
That is why the 20to30 firmware does not work exactly like a etrex 30.

In the images leave the 3 models of chips used, if anyone WANT add.
Although I think only the barometric sensor is easy to solder.

Furthermore you can see in the last picture the 3 main chips used in these models.

CPU: STA8088EXG
2GB Memory: Samsung KLM2G1DEHE-B101 This memory can have two configurable boot. ¿Region 5 - Boot Block? and ¿region 12- Boot.bin?
256kb Memory: K5N5629ATA [NOR 256Mb] Could this be the NV?


Combining KLM2G1DEHE-B101 + K5N5629ATA [NOR 256Mb] is widely used in some mobile phones, so maybe you could read and write these memories with some software used in phones, to repair firmwares (boots corrupt).

Someone can provide more info?

[Only registered and activated users can see links. ]

I've written a new disasm script. I think it's better than the previous one I posted in this topic. It works by treating all the 4-bytes aligned 4-byte integers as pointers and judging if each one points to a function. Also smart_disasm requires that the firmware entry point is named "fw_base".

Code:

Please Login or Register to see the links

Originally Posted by kunix

I've written a new disasm script. I think it's better than the previous one I posted in this topic. It works by treating all the 4-bytes aligned 4-byte integers as pointers and judging if each one points to a function. Also smart_disasm requires that the firmware entry point is named "fw_base".

Code:

Please Login or Register to see the links

I think that this row have to be changed as
if((ptr % 2) == 0 && ...........

and also
addr = Dword(p);

i think that return program code at address p, not the address in p, as seems used in script ...

Do you think I should incorporate the script into the loader? Hm, I don't know... It's much easier to keep them separated. Also starting disassembling right after loading the firmware is a bad idea, so disassembling should be called by a separate function, and I don't know how to add a new function from a plugin.

What firmware did you use?
The procedure is the following: name the entry point as "fw_base" and the run smart_disasm(), it will calculate the disasm region bounds and call smart_disasm_region().
Calling smart_disasm_region for a small part of the firmware is a bad idea, as pointers may be very distant from the corresponding functions.
This script is better than the previous because it has a very small amount of false positives. And false positives frequently make IDA disassemble data, not code, and then the disasm looks awful. The old script is especially awful for nuvis 34xx, 24x5 (when the firmware uses Thumb2 instructions).

UPD
Yeah, it does miss functions, can't yet explain why.
I thought that any function is either called indirectly (and then its address is stored as integer), or it's called directly by some function and then we can proceed recursively with the caller. By this reasoning the new script should disassemble all functions.
I'm aware that this reasoning is false sometimes (the italic part), as some functions are first copied to another location and only after they are called, also there is infinite amount of perverted ways to call a function (but only small amount of them is used by the compiler). But I'm hoping that it's false for not too many functions.

So, in conclusion, the new script is better because the disasm is clearer (no images/other data is disassembled!), while almost all usable functions are found.