Hello!

How can I dissasemble (correctly) a image?
CPU : AMD x86 embedded

IDA isnt working well, it says I gotta point EP ..
Btw, image (part of it?) is compressed, I assume that's normal.

String inside it says :
"PKWARE Data Compression Library (R) for DOS
Copyright 1989-1995 PKWARE Inc. All Rights Reserved.
PKWARE Data Compression Library Reg. U.S. Pat. and Tm. Off.
Patent No. 5,051,745
Version 1.10"

Also interesting strings such as : "4.46-00-120110 'knevotcn'ê^@^@^W^O´t]v^@^@¬E
^C^@0^G^@hExploding file KBRIDGE.CMP => KBRIDGE.BIN
^@Done!
^@Error in compressed file! Halting..."

Thank you very much for any info that you can provide me!

And, of course, you have NOT followed the instructions of the FAQ and explained what YOU have done to try to solve your own problem and have not explained what searching you have attempted, either here or on the net.

Those things are expected here BEFORE you get help from the members here.
How about you check the FAQ and start again.

Regards,

The simple answer is you'll need to dump the uncompressed file from memory to get a correct disassembly, or explore it "live" with a debugger.

Interesting, it sounds like a non-Winzip implementation of the PKWARE compression. A guess that their .CMP extension stands for 'compressed'. So why can't you disassemble the .bin file, because it's firmware? Now outline what you've done.

Kayaker

Thank you, Kayaker, for quick response!

IDA identifies it as Binary file (ofcourse) and processor type Intel 80x86 metapc. Says "IDA Pro can't identify the entry point automatically as there is no standard of binaries. Please move the what u think is an entry point and press C..."

First 3 bytes of file starts with : 0xE9, 0xB5, 0x43
At 7th byte I've got signature of firm : "Copyright 1991-2001 by XXX Inc."

Mentioned file "KBRIDGE.CMP => KBRIDGE.BIN" isnt this file. (KBRIDGE is inside this file?)
This is knrgotcn-vSOME_VER.bin

Hmm, can I 'catch' some important information while uploading this image into HW?

Btw, is it possible to debug a firmware !? Well, disassemble ok, but debug? Only if I have a emulator, right?

Packed firmware, cool.

Depends on what kind of firmware. You must first identify type of the chip-procesor used by the device using that firmware. After this only thing that remained is to select type of it in ida like ARM, C166, ATMEL, MOT etc. For real debugging of firmware exist specialized external hardware with dedicated software. Also u can use software emulator for those much better then ida. Also must take care if the firmware is crypted or not. For example in new NOKIA devices this firmware is stored crypted in flash chips and decrypted on fly while running. offcourse u need a good knowledge of instruction sets different "bugs" u may study.

Br

If data is sended by serial port u may catch it using a serial sniffer. Also bad bad is that bootloader of the device could take care of data while sended.

Br

Ok, I've got more information :

CPU :
STPC Elite
32-bit 5x86 core with L1 cache and FPU

http://us.st.com/stonline/products/support/micro/stpc/elite.htm

From my experience dealing with embedded devices:

Debugging in any manner is usually not an option, as ROM does not permit
setting breakpoints inside. The limited debugging capabilities you might have
usually do not include setting debug register breakpoints, so for me debugging
was pretty much out of the picture.

When faced with the flat executable, you can proceed in different ways:
You could manually track the floppy boot loader. If it's an x86 system, the
device will boot from the ROM image just as if it was a floppy with boot sector,
and then you'll have some very retro DMA code to transfer stuff into memory
and unpack. The disadvantage here is that you don't really care about most
of the code, statically emulating a pkunzip routine is rarely fun. What I used
with great success is grepping the ROM image for PK headers, then using
your favourite hex editor to carve .zip files out of it. Unpack, and repeat
the process (many ROM's have multiple layer of zipping -- e.g. a bootstrap
layer that unzips and loads an embedded OS image that unzips and loads
a bunch of executables). Once you've reached the end, you take a few
educated guesses as to what file format you have in front of you -- in
many cases it'll be ELF or a.out.

The odds of encountering a file format for which IDA has no loader are low,
as most larger embedded devices have their software written in C and
compiled to a.out or something.

I am _very_ interested in hearing more feedback on this, and in talking
to more people that are into ROM disassemblies. It's an important hobby
of mine these days, and I'd like to meet likeminded people

Cheers,
Halvar

firmware is uploaded to device with snmp, you connect cross cable between pc and device and with provided application you connect to device with snmp and then upload firmware and key with application.
It's not serial connection.

halvar,

Sorry, I've been away. I'll check your advice and look more into it...

I'll keep you posted, if you're interested ...

Cool :-)

It's really interesting!

Ok, I've done next step by identifying couple of instructions...
Looking for 3 bytes (push ebp; mov ebp, esp) gives me couple of small routines. Code seems valid, except addresses used in instructions seems wild (read: big, not-normal), but I dont have expirience with firmware so maybe data is mapped at that location (?).

File is custom format...

It's holding loader, BIOS, drivers, ... inside it, so any advice on how to identify it and taking it apart ... ?

As I said before, it's x86 compatible so I'm disassembling it with correct tool (IDA)...

Check an old x86 book on boot loaders -- there's an offset in the file
at which the code will start to execute. It will start in 16-bit mode, and
then usually do something like set up descriptor tables and switch into
pmode.

Ok, Halvar, I'm looking more into it, but not that easy ...

Disassembling inside IDA with code as 16 bit (2 choice at beginning : 16bit or 32bit code) looks much more better.
Still no EP, since it's unknown file format, BUT IDA disassembles couple of routines automatic!

I'm getting crazy now ...

I've uploaded stuff here :

hXXp://web.vip.hr/fritz_hr.vip/image.bin
hXXp://web.vip.hr/fritz_hr.vip/KCFLDR

If anyone get anywhere with this, I'm be incredible happy and I'll continue to move on with my life...

It is crucial that you start the disassembly at the entry point,
e.g. at the point where the boot loader would start. Check some
old boot disk code -- in the case of Cisco PIX you just started
at the offset that a boot disk loader would start, and you had
a fairly quick switch into protected mode afterwards. Then go
from there. "Blindly" disassembling the file will yield bad results
because you can't tell if a particular piece of code will be executed
in 16 bit or 32 bit mode if you do so.

Halvar,
Thank you for your replies, since anyone else of reversers isnt familiar with this subject...

I've taked some small time and checked boot process ...
Status I've done so far :
http://web.vip.hr/karlit0.vip/re1.txt

As you will see, I'm stuck on jumping to next part of code...
Which is mapped somewhere where I can't go untill I figure out memory part ... Right?

Hey Jan,

this looks fairly standard -- it just reads the file from the "disk" (rom),
and sets up the segments. You probably need to read sub_95A6 and
see where on the disk it "seeks" to, and the textfile isn't complete
enough to understand things. How come the code is starting at 0x9494 ?
That is not the standard offset for boot loaders...

The trick is to understand how that thing sets up memory, e.g. which
parts of the rom are moved into segment 7D0. Then start setting up
things in IDA properly and move there.

It is a bit of tedious and oldschool work, but ROM disasm is soo omuch
fun...

Sorry for not posting more disasm results myself, my life is a bit crazy
right now (exam time in uni + private shit).

Cheers,
Halvar

Halvar,

sub_95A6 is pretty short. As u can see here :
(link below)
EP isnt at that offset, 0x9494
Oh ... damn ...
EP : It's starts at offset 0x0000...
Sorry, this new disassembling in 16bit reveals much different output and I was confused also (I'm tired of exams on unis. also ... )

There is much more code before this one in re1.txt

Additional info,check this out :
hXXp://web.vip.hr/karlit0.vip/re2.txt

I'll have to check can somehow be showed/emulated next part of memory at next segment 7D0 in IDA ...

After more understanding situation, I think I can be more specific now with my goal.

I'm interested in one algorithm (protection part) in this firmware.
Commented part of disassembly, that's from KCFLDR. That is BIOS + loader, maybe I shouldn't work on this at all...

Since goal-part that I'm chasing, as I suspect, is in image.bin
The problem with image.bin, it's also unknown file format, seems partionally packed with PKWARE as there are strings inside and IDA can't do much work as done in KCFLDR (which isnt packed).

What's the next step in this long journey ... ?

I think that is preaty safe to say that loader does not have any protection scheme inside it, becouse that loader is used also on rg device and many others.
Jan, did you discover wich file format is used with older version of image.bin 3.x ?

What protection? It would appear that there is none, and, that the packing algorithm used has been identified. My suggestion would be to head over to the DataCompression.info Lempel-Ziv page which links to a description of the format and also some source for unpacking it. http://datacompression.info/LZSS.shtml

Yes, but more common than you may think. My PocketPC ROM contains mostly packed binaries, as I discovered when attempting to create custom flashes for it.

Ok, I'm getting somewhere...step by step...

Thank you for that information.
Now I know that PKWARE DCL is used here and that it's not public compression/format.
But, some Ben did RE on it and thanks to him, Mark Adler (zlib) wrote a decompressor (zlib/contrib/blast).

Now, the problem is how to locate compressed stream...
It looks simple, format, but this one is inside a image and that's a problem.

Anyone?

with respect,
Jan

from http://groups.google.com/groups?q=author:Ben+author:Rudiak-Gould&hl=en&rnum=1&selm=34259d52.0108131038.21dd88f9%40posting.google.com

A PKWARE Data Compression Library compressed stream consists of a
two-byte header followed by a bitstream of arbitrary length.

The first byte of the header is either 0 or 1, and determines the way
in which literal bytes are represented in the bitstream (see below).

The second byte of the header is equal to 4, 5, or 6, and determines
the size of the sliding-window dictionary: 4, 5, and 6 indicate a 1K,
2K and 4K dictionary respectively.

this might cut down the possibilities.

Anti.

Anticode,

Yes, thank you, but I've seen it, as oddbog pointed me before.
The problem was with locating it inside a file. That you for that header,but .. still...
I was speaking with compression guru, M. A., he said that I should start decompressing all, moving step by step, untill decompressed output makes sense.
So, I'll start with that. The problem is, as u know, decompressed output isnt text, it's code so I need to decompress and disassemble every time...

Sounds like a long journey ...

with respect,
Jan

Well if are in compresed file you have some strings, you will know when you uncompress from right start byte.

According to this method:
1) Decompress the stream, disassemble the output, see if it makes sence.
Yes -> done.
No -> advance one byte, jump to step 1).

You get tens thoushand of possibilities. not to mention the hard work and waisted time.

My Method:
1) Binary scan the file for these patterns:
00h,04h
00h,05h
00h,06h
01h,04h
01h,05h
01h,06h
and mark those addresses.
2) Decompress the stream at the current addresses, disassemble the output, see if it makes sence.
Yes -> done.
No -> advance to next address in the list, jump to step 2).

You get few hundred possibilities max.

Now what method a wise man would choose!?

I'm a little out of my league in this section of the forum, but I've worked as a computer tech in the past. The E9 seems to be a jump instruction and that would make sense. It's probably a bootstrap loader.

If you load it in IDA as a binary, highlight the E9, and change it to code, it might unfold a whole bunch more code for you. That would depend on you finding the correct start of code, however (try 0x0 and 0x100...like in an old COM file). As I recall. however, you have to tell IDA whether it's 16 or 32 bit on the way in, and I think you have to set up your own segments. I've had luck with bin files in the past using just one segment.

Well, at least on newer PIX images, the meat of the OS are contained in a pkzipped file that is decompressed via a secondary boot stage, unless they went back to their older flat file format recently?

No, PIX (or any larger Cisco device) is still best
done by looking for the PK headers and dumping the
zip files out of the .bin. This doesn't change the fact
that if there's no zip headers in the image file, you'll
have no choice but to disassemble the boot loader
and see what it does

First, moderators, excuse me for reviving old thread.

Hello Halvar, Anticode & thewhiz.
I'm pretty busy with college, exams ...

Anyway, I dont have much time for doing this, so disassembling the bootloader and analyzing every step-by-step is pretty long journey, as we all know.

I was thinking lastnight ... how could I debug a bootloader and code after that...
The problem is that it wouldn't be classic debugging, since this isn't under any OS so we can pullout the debugger and start hacking...
So, solution would be debugging a whole 'computer'... Like if there would be machine under machine... Then it hit me, virtual computer (vmware, bochs, ...).
After looking, there is no such thing that can debug EVERY step in virtual computer except bochs. Bochs support such operations. So, I'll have to load that loader under Bochs and debug it. Then I could analyze everything I need... even dumping from there a uncompressed image ... right?

I was talking with Bochs developers and they said that Bochs would be solution, yes.

Looks like new approach

Comments?

Bochs would be an interesting solution to this problem. I have personally used a hardware approach to this in the past -- an incircuit emulator, but that is generally cost prohibitive to the average hacker.