revisiting garmin etrex processor

Elsewhere in this newgroup it's mentioned that Garmin Etrex-series GPS
units use ARM processors. I'm attempting to disassemble the software
using:

$ arm-elf-objdump.exe --target=binary --architecture=arm
--disassemble-all 013001000214.rgn

And getting nonsense (like branches to nonexistent addresses) even
where the raw data LOOKS like code, e.g. not like text or bitmaps or
pointers. This was on Cygwin using the toolchain from the eCos
installation at http://ecos.sourceware.org/getstart.html .

Any pointers on what I'm doing wrong is appreciated.

Hmm, maybe because I'm used to processors with variable-length
instructions, which in a disassembly normally tend to "right"
themselves after a block of data. The ARM, which has all fixed-length
32-bit instructions, doesn't do that.

I went to the Hacking Your GPS Firmware page,
http://www.extremetech.com/article2/0,1697,1780421,00.asp , and using
hexedit, entered the before and after byte sequences into 2 files,
before.rgn and after.rgn. Then tried disassembling using increasing
offsets until I got something that looked as though it made sense:

jcomeau@intrepid /cygdrive/c/Program Files/Garmin
$ arm-elf-objdump.exe --target=binary --architecture=arm
--disassemble-all --start-address=2 before.rgn

before.rgn: file format binary

arm-elf-objdump: before.rgn: no symbols
Disassembly of section .data:

2: 24f50203 ldrcsbt r0, [r5], #515
6: 1c010203 sfmne f0, 4, [r1], -#12
a: 20004a05 andcs r4, r0, r5, lsl #20
e: 58d300c3 ldmplia r3, {r0, r1, r6, r7}^
12: d002428b andle r4, r2, fp, lsl #5
16: 00000001 andeq r0, r0, r1
1a: 00000000 andeq r0, r0, r0
...

jcomeau@intrepid /cygdrive/c/Program Files/Garmin
$ arm-elf-objdump.exe --target=binary --architecture=arm
--disassemble-all --start-address=2 after.rgn

after.rgn: file format binary

arm-elf-objdump: after.rgn: no symbols
Disassembly of section .data:

2: ba6d0203 blt 0x1b40816
6: 1c010204 sfmne f0, 4, [r1], -#16
a: 20004a05 andcs r4, r0, r5, lsl #20
e: 58d300c3 ldmplia r3, {r0, r1, r6, r7}^
12: d002428b andle r4, r2, fp, lsl #5
16: 00000001 andeq r0, r0, r1
1a: 00000000 andeq r0, r0, r0
...
-------------
My guess is that the hacker who wrote the article overwrote a load
instruction with a branch instruction. Since I don't know the size of
the firmware file (016901000228.RGN), I don't know if that address is
valid or not.

jcomeau_ictx wrote: