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.

There are 31,322 total registered users.

Recently Created Topics
[help] Unpacking VMP...	Mar/12
Reverse Engineering ...	Jul/06
hi!	Jul/01
let 'IDAPython' impo...	Sep/24
set 'IDAPython' as t...	Sep/24
GuessType return une...	Sep/20
About retrieving the...	Sep/07
How to find specific...	Aug/15
How to get data depe...	Jul/07
Identify RVA data in...	May/06

Recent Forum Posts
Finding the procedur...	rolEYder
Question about debbu...	rolEYder
Identify RVA data in...	sohlow
let 'IDAPython' impo...	sohlow
How to find specific...	hackgreti
Problem with ollydbg	sh3dow
How can I write olly...	sh3dow
New LoadMAP plugin v...	mefisto...
Intel pin in loaded ...	djnemo
OOP_RE tool available?	Bl4ckm4n

Recent Blog Entries
	halsten	Mar/14
Breaking IonCUBE VM
	oleavr	Oct/24
Anatomy of a code tracer
	hasherezade	Sep/24
IAT Patcher - new tool for ...
	oleavr	Aug/27
CryptoShark: code tracer ba...
	oleavr	Jun/25
Build a debugger in 5 minutes
More ...

Recent Blog Comments
	nieo on:	Mar/22
IAT Patcher - new tool for ...
	djnemo on:	Nov/17
Kernel debugger vs user mod...
	acel on:	Nov/14
Kernel debugger vs user mod...
	pedram on:	Dec/21
frida.github.io: scriptable...
	capadleman on:	Jun/19
Using NtCreateThreadEx for ...
More ...

Imagery

SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit