I'm working on an embedded system Coldfire ROM. Currently, I'm trying to reverse engineering it to gain some more in-depth knowledge about its structure.
ROM code quality seems pretty low, and I see a lot of redundancy and dead code lay around, as if the code was compiled with a very low level of optimization.
I'm telling you that because I do not understand if this fact is somehow related to the question I'm about to pose.
Checking the code, not infrequently, I'm stepping into jumps inside a single multi byte instruction. I'm new to this technique, so I wonder if someone can put me in the right track to understand this, that I consider a strangeness.
Here an example of what I'm referring to: I have a function which starts at ROM:00005474
[...] .ROM:00005490 30 07 movew %d7,%d0 .ROM:00005492 4a 80 tstl %d0 .ROM:00005494 66 0c bnes 0x0000000c :12 .ROM:00005496 70 00 moveq #0,%d0 .ROM:00005498 60 00 00 a8 braw 0x000000b2 .ROM:0000549c 4e b9 00 00 36 f8 jsr 0x000036f8 : the jump points inside here .ROM:000054a2 32 06 movew %d6,%d1 .ROM:000054a4 48 c1 extl %d1 .ROM:000054a6 20 01 movel %d1,%d0 [...]
In another area of the ROM, I have another function which starts at ROM:00012016
[...] .ROM:000120c0 72 00 moveq #0,%d1 .ROM:000120c2 12 00 moveb %d0,%d1 .ROM:000120c4 20 3c 00 00 00 ff movel #255,%d0 .ROM:000120ca b2 80 cmpl %d0,%d1 .ROM:000120cc 66 00 01 92 bnew 0x00012260 .ROM:000120d0 4e b9 00 00 54 9e jsr 0x0000549e :here the jump I do not understand .ROM:000120d6 72 00 moveq #0,%d1 .ROM:000120d8 12 00 moveb %d0,%d1 .ROM:000120da 20 3c 00 00 00 ff movel #255,%d0 [...]
If I try to follow the jump and begin to disassemble the function starting from the address ROM:0000549e I get a translation which leads to the following interpretation. I understand it is executable, but I do not get the big picture in this action.
[...] .ROM:0000549e 00 00 36 f8 orib #-8,%d0 .ROM:000054a2 32 06 movew %d6,%d1 .ROM:000054a4 48 c1 extl %d1 .ROM:000054a6 20 01 movel %d1,%d0 [...]
Is there, behind this technique, some old practice I should know. Why this ROM developer should have used such a strange technique? To reduce the code size? If so, it is not fit with the rest of the code which is very redundant and has dead code in it which won't be ever executed!
At byte 0xc000 it begins a block of code extends to 0x40000 whose first function appears to be incomplete in its beginning part.
The weirdness seems to begin from this point forward and extends to the byte 0x40000 where the second part of the firmware begins.
In this code blocks, there are roughly 200 functions of various dimensions and the JSRs with a weird absolute address are not present in all the functions in this block.
The functions in this block seem to interact with each other seamlessly, but they occasionally occur to present inconsistent addresses.