OpenRCE

About Articles Book Store Distributed RCE Downloads Event Calendar Forums Live Discussion Reference Library RSS Feeds Search Users What's New

Customize Theme

Flag: Tornado! Hurricane!

Topic created on: December 30, 2009 23:11 CST by reidmefirst .

I have an x86 vxworks binary file that I am staring at to make sense of.

I found this nice paper:

https://www.blackhat.com/presentations/bh-usa-07/Maynor_and_Graham/Whitepaper/bh-usa-07-maynor_and_graham-WP.pdf

It describes the tiniest detail of a vxworks binary, namely that offset 0x14 contains the base address to load the binary. What I don't get is, what is the start address in the actual file that vxWorks loads into that base address?

Like in the paper, my binary file contains 0x0108000 at offset 0x14, but if I load the raw binary file into Ida at that offset, all the data xrefs are messed up. Anyone know of a good 'vxWorks binary file format primer' for reverse engineers?

phn1x		December 31, 2009 09:26.59 CST
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."

reidmefirst		December 31, 2009 10:27.51 CST
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.

reidmefirst		January 4, 2010 13:25.50 CST
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.

Active in Last 5 Minutes
	jesucito81

There are 28,225 total registered users.

Recently Created Topics
Reverse Engineering ...	Jan/23
Career: DoD Agency I...	Jan/22
"Disappearing&q...	Jan/17
Career: Software Sec...	Jan/11
Where is the call st...	Jan/07
IDA Pro 6.1 Breakpoi...	Jan/01
How to create data s...	Dec/30
can i search all mod...	Dec/23
IDA symbol table exp...	Dec/20
An anti-attach trick	Dec/17

Recent Forum Posts
Reverse Engineering ...	NirIzr
"Disappearing&q...	NirIzr
Reverse Engineering ...	charlie
"Disappearing&q...	charlie
An anti-attach trick	Bass
An anti-attach trick	waleeda...
An anti-attach trick	Bass
An anti-attach trick	waleeda...
An anti-attach trick	Bass
Looking for value in...	NirIzr

Recent Blog Entries
	cmathieu	Feb/07
Hacker Carnival
	waleedassar	Feb/06
OllyDbg v1.10 And Hardware ...
	waleedassar	Jan/31
Yet Another Anti-Debug Trick
	RolfRolles	Jan/22
Finding Bugs in VMs with a ...
	waleedassar	Jan/13
An OllyDbg Bug Disables Sof...
More ...

Recent Blog Comments
	waleedassar on:	Feb/07
OllyDbg v1.10 And Hardware ...
	NirIzr on:	Feb/07
OllyDbg v1.10 And Hardware ...
	NirIzr on:	Feb/05
Yet Another Anti-Debug Trick
	trolotou on:	Feb/05
Doudoune Moncler -Pennies F...
	waleedassar on:	Feb/01
Yet Another Anti-Debug Trick
More ...

Imagery

SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit