Flag: Tornado!
Hurricane!
|
|
Topic created on: April 2, 2007 04:18 CDT by trufae  .
I'm analyzing an ARM bootloader that contain strings, but IDA seems not to find correctly the xrefs.
I've been analyzing the code with radare and I got that the four initial bytes are the offset where the code starts, defining this address as base in IDA the disassembly looks fine ( so it's 4-byte aligned ), but I'm unable to find any reference to the strings.
Is there any methodology or technique to find xrefs of strings on raw binaries? Maybe these strings are referenced with absolute addresses in memory.
Anybody experienced with bootloaders on embedded devices?
One common ARM idiom IDA currently doesn't parse properly is the following:
MOV Rx, =delta
<optional code>
ADD Ry, PC, Rx
<use Ry>
Which obviously should be interpreted as:
MOV Rx, =target-(label+8)
<optional code>
ADD Ry, PC, Rx
label:
<use Ry>
So, check if the code has anything like that. You could also upload the binary and we all could have a look at it.
|
is it for a windows ce device?
( at offset 0x40 there will be a signature 'ECEC', followed by a ptr to a ROMHDR struct )
in that case, you can use dumpxip.pl to figure out what address the bootloader is based on.
another thing to be aware of, is that usually a part of the bootloader will execute in physical address mode, and part in virtual address mode.
|
Hi itsme! :)
Nope, it's not htc. But I can't reveal the source.
The bootloader is splitted in three pieces, they're flashed together, but each piece is independent from each other.
I'm just reading the second one but all of them looks pretty similar:
[8 bytes] - in little endian defining the starting address.
..padding..
[initial-offset]
[code]
[strings]
How can I know what's the physical address and the virtual one? looking for hardcoded absolute addresses?
----
igorsk: I got some "LDR Rx, =delta", but no "MOV Rx, =delta", I should guess that LDR is the 32 bit safe addressing for absolute values, right? The delta offsets look like:
LDR R0, =0x20003FF0
There'r some relative:
LDR R0, =0xFFFFFE80
I've manually calculated the relative offset and it exactly points to a subroutine (which shifts R1->R0, R2->R1 and jumps where R0 says (PC=R0)).
IDA doesn't handles this relative offset, so AFAIK most of arm reversing must be done by hand.
I've tried to substract the higher part of the absolute offsets to get 0x3FF0, but this value points out of the file :/ (i've substracted the base address of the entry point and stills out).
Maybe the base address of the program in memory is higher than the physical one in file, so this is the second piece because the first one has no strings.. Maybe I should read the first piece to understand how it loads the rest.
Any idea?
|
why do you think "LDR R0,=0xFFFFFE80" is relative?
it could be an ioport address, for instance with the omap chipsets there is io mapped in the area from 0xfff00000 and up. ( the highest address i could find for omap is 0xfffffe03 )
what i would do to find the base address, is create a list of dword constants referenced in the disassembly,
sort them, calculate the differences between consecutive offsets.
then do the same with subroutine start addresses, and string addresses, also calculate the difference between consecutive offsets.
then try to find matching sequences in these difference lists.
this way you may discover non-linear mappings of the real offsets to the file offsets.
( for instance when the code you are looking at is relocated to different addresses in ram or so, or if you are looking at some not yet completely understood fileformat )
|
>Itsme:
Can you explain your question more specificallay?
............................
http://www.optimize-your-pc.com/
trufae: Hi itsme! :)
>
> Nope, it\'s not htc. But I can\'t reveal the source.
>
> The bootloader is splitted in three pieces, they\'re flashed together, but each piece is independent from each other.
>
> I\'m just reading the second one but all of them looks pretty similar:
>
> [8 bytes] - in little endian defining the starting address.
> ..padding..
> [initial-offset]
> [code]
> [strings]
>
> How can I know what\'s the physical address and the virtual one? looking for hardcoded absolute addresses?
>
> ----
>
> igorsk: I got some \"LDR Rx, =delta\", but no \"MOV Rx, =delta\", I should guess that LDR is the 32 bit safe addressing for absolute values, right? The delta offsets look like:
>
> LDR R0, =0x20003FF0
>
> There\'r some relative:
>
> LDR R0, =0xFFFFFE80
>
> I\'ve manually calculated the relative offset and it exactly points to a subroutine (which shifts R1->R0, R2->R1 and jumps where R0 says (PC=R0)).
>
> IDA doesn\'t handles this relative offset, so AFAIK most of arm reversing must be done by hand.
>
> I\'ve tried to substract the higher part of the absolute offsets to get 0x3FF0, but this value points out of the file :/ (i\'ve substracted the base address of the entry point and stills out).
>
> Maybe the base address of the program in memory is higher than the physical one in file, so this is the second piece because the first one has no strings.. Maybe I should read the first piece to understand how it loads the rest.
>
> Any idea?
|
Note: Registration is required to post to the forums.
|
|
|
|
There are 31,328 total registered users.
|
|
![[+] expand](/imagery/files/soysauce_blueprint.gif){kind=link}