Flag: Tornado!
Hurricane!
|
|
 No blog entries found for specified user.
Topic created on: by  .
continue reading the paper....
You read:
"After examining the boot loader, called bootrom in /boot/<current version>/rom the loading offset appears to be read from offset 0x14 of the VxWorks file. The value found there is 0x108000. This is used to rebase the image in IDA Pro and start another analysis of the binary with increased accuracy in the results."
it continues...
"The results are still far from optimal with problems like strings not being detected correctly. Searching through the binary will reveal strings for standard C programming function names, located adjacently. After these strings is what looks like a symbol table. IDA Pro is flexible enough to support a scripting language called IDC which can be used to automate a lot of the cleanup tasks."
<screen shot of IDC code>
"In addition to the symbol table the auto-analysis misses detection of numerous functions. Since this VxWorks software was designed to run on a Intel x86 processor it has a standard function prologue of 0x55/0x89/0xE5 in hex or push ebp, mov ebp, esp in assembly. Creating another IDC script that can recognize the prologue and mark functions accordingly will shorten the analysis time. The scripts created for this demonstration are simple with hardcoded offsets for the strings and symbol table. These hardcoded offsets need to be changed for new versions of the image."
|
Thanks for the help.
"it continues..."
Right. I wrote up an IdaPython script to locate the standard function prologues and make-function on each. The trouble that I run into is that string xrefs are messed up. The paper indicates that they had this problem too. What I get is something like this in a data section:
" login: "
There will be a data x-ref pointing to the 'g' part of this string. The data x-ref is a pea, but the call that happens after this is to a function that performs some floating-point maths. So the data x-ref is probably off by more than a few bytes.
My binary does have a list of strings at the end of the file that look like standard c function names ("_printf" and similar stuff appear there), as well as some custom libraries probably ("_companyname_getDBdata"). These strings are one after another, with no data in between. The file just has these strings, all the way up to the end. I guess that the paper authors had some luck and their binary either had debugging symbols or was dynamically linked. My binary doesn't look the same, although I wonder why my binary would have these strings at all -- it doesn't seem like they would be very useful to a binary. The Wind River compiler writers are probably the only ones who can answer ;-).
I am familiar with ELF and BFLT format binaries, but this doesn't look the same. Still, I would guess that it has the information I need to base the file correctly so that these data xrefs work out. I sorta feel like this will be my best bet to making sense of the binary.
|
Found it!
Apparently the loading offset pointer (0x14 in the binary file) shows where the file should be loaded. On three of the binaries I have looked at so far, loading 0x20 bytes into the file into this location yields valid disassemblies (make-code at application base yields a lot of automatic analysis, doing preamble search yields valid data xrefs on all subsequent disassembly). So maybe the header doesn't have anything to do with it, maybe it's just a 'vxworks thing,' but I haven't seen anyone notice it before.
So in the paper authors' example, they should actually base the image that they grabbed to 0x107fe0. This would give them proper string xrefs. That certainly helps analyze the binary, as this one has a lot of debug printfs in the code to let me know how the developers were thinking :).
I still don't know what the other parts of the application header are doing exactly. That knowledge might be useful. I would have to guess that it includes things like stack and heap size, and maybe even base addresses for both, but so far it doesn't make sense...
|
Note: Registration is required to post to the forums.
|
|
|
|
There are 31,328 total registered users.
|
|
![[+] expand](/imagery/files/soysauce_blueprint.gif){kind=link}