Flag: Tornado!
Hurricane!
|
|
Topic created on: March 29, 2008 18:46 CDT by memo5  .
Hello All
I'm working on reversing an embedded system, its my first attempt and need some advice, first of all the program file is in Intel-Hex format, so the code address is obtained by IDA, the target platform is x86 compatible, I'm facing some difficulties in setting the segments addresses and values cs,ds,es segments values.
I appreciate any help.
What's the CPU? Is the code 16-bit or 32-bit? Is it the initial code (bootloader, BIOS) or is it something that's more high level? Are there datasheets available? Is the binary available for download somewhere or can you upload it?
In short, list as much info as you can and try to describe the actual problem you're having in more details. "Some difficulties" is not much to work with.
See also this.
|
Ok igorsk thank you for your advice.
And hope that this information will help.
The CPU Is Turbo186 the code is 16 bit.
The CPU run in extended mode using 24bit addressing capability.
-The paragraph is not 16 byte its 256 byte so the CPU address space is 16MB-
and the EA calculated as: EA = (segment << 8) + offset.
The code is not just a Bootloader or BIOS it's the full firmware of a multimedia related control board.
Unfortunately I can't upload the binary file, and it's not published any ware.
The firmware mapped to address 0x600000, and the size of the firmware is 2MB
When I load the binary into IDA and disassemble the code I got code like this:
seg000:6005CD push bp
seg000:6005CE mov bp, sp
seg000:6005D0 push si
seg000:6005D1 mov si, [bp+6]
seg000:6005D4 push si
seg000:6005D5 call far ptr 6019h:0B1Fh --> Call 601900:0B1F
seg000:6005DA pop cx
seg000:6005DB cmp ax, 1
seg000:6005DE jnz short near ptr 5E4h ---+
seg000:6005E0 xor ax, ax |
seg000:6005E2 jmp short near ptr 5EBh ---+ |
seg000:6005E4 --------------------------- | |
seg000:6005E4 push si | <--+
seg000:6005E5 call far ptr 6306h:1Ch | --> Call 630600:1C
seg000:6005EA pop cx |
seg000:6005EB pop si <--+
seg000:6005EC pop bp
seg000:6005ED retf
You can notice that IDA could not recognize calls or jumps to near or far addresses.
To be specific how can I make IDA recognize the (24Bit) addressing mode, and correctly identify calls and jumps to other addresses?
|
I'm afraid it's not possible with current IDA version. The PC processor module is hardcoded to the standard x86 segmentation (ea = segment<<4 + offset). The best you can do is report this issue to Ilfak. This will probably need a new configuration flag in the processor module.
In the meantime you could probably write a plugin or an IDC script which would walk through all the call instructions and fix the cross references.
|
|
You might consider writing a plugin that hooks the processor_t::custom_emu and/or processor_t::custom_outop notifications to modify the behavior of IDA's existing x86 processor module to suit your needs.
|
Thanks
I think that building a new processor module will solve this limitation.
So I appreciate any link to document or tut that explaine how to build custom processor module for IDA.
|
http://www.openrce.org/articles/full_view/28
??
|
|
Coding a processor module in this situation would be overkill. I suggest you follow igorsk's advice, and, if that turns out to be too simplistic, follow cseagle's advice.
|
Ok Thank you all for your suggestions.
Actually, until now I could not make it work.
As Rolf said writing a processor module is overkill, and I add, it's very hard especially for processor like X86 with rich instruction set, and duo the fact that there is now developer guide or article explain when and how to write an IDP.
Igorsk suggested writing a plugin or an IDC script to fix the cross references,
Actually IDA didn�t create any xref, It couldn�t identify any function in the first place.
cseagle suggested writing a plugin that hooks the processor_t::custom_emu and/or processor_t::custom_outop notifications to modify the behavior of IDA's existing x86 processor module, The truth is I didn't try this but I think that this will just make the code-view more prettier, I am afraid that other plugins like Sabre BinDiff will ignore this modifications, I need to modify the actual data structs used by IDA to hold information about the instructions and its operands.
What I did:
===========
I did write a plugin that identify all the functions as a first stage and I got about 3800 function and I noticed that the code heavily use jump tables (switch..case) .
My plane was to expand the functionality of my plugin to patch the instruction operands and correct the segment and or selector value but I realized that it is not so easy, The problem is IDA use the specval_shorts member field of op_t struct to store segment register index or value and selector value for IBM PC module, as you can see the tow fields are ushorts, so there is no way to patch this fields to hold segment value greater than 0xFFFF.
So if this true, is there any one know what to do, to change the way that IDA use to interpret this field (specval_shorts).
// IDP SPECIFIC INFORMATION
union {
ea_t specval;//This field may be used as you want.
struct { //this structure is defined for your convenience only
ushort low; //IBM PC:segment register number(o_mem,o_far,o_near)
ushort high;//IBM PC:segment selector value(o_mem,o_far,o_near)
} specval_shorts;
};
==== fragment of op_t class ua.hpp IDA sdk====
|
Okay, I think I figured out a solution for your problem, and it doesn't even involve extra plugins :)
Open the selectors window (View-Open Subviews) and add a selector (Ins) 0x6019 with the value of 0x60190. This should fix your reference at seg000:6005D5. You will probably need to do the same for all possible segment values (an IDC script?).
In IDA terminology, selector is a possible value of a segment register (such as ds, cs, es). It considers the segment part of segment:offset expression as a selector when calculating the linear address it refers to. In real mode the linear address is usually equal to segment<<4 but in protected mode it can be about anything, thus the concept of selectors.
|
Thank you igorsk
This trick work's for far calls and jumps but I still need to get correct xref for near jumps and jump tables, do you have another good idea work for second problem.
|
|
Well, you probably need to split your binary into 64K segments so that near xrefs line up...
|
Ok I have tried this yesterday but when I did that another 2 new problems raised
1- IDA can manage 16 segments MAX.
2- IDA fail to interpret the jump tables produced by the compiler to represent (switch. case), and xref locations at other functions.
|
Sorry igorsk my previous reply was completely wrong.
The (16) MAX limit is for segment registers not for segments count.
So I was able to create more than 280 segments.
And IDA now disassemble the program correctly, one note about these segments is I have used the same tech. I have used to collect info about the selectors and create segments instead of just selectors
|
Note: Registration is required to post to the forums.
|
|
|
|
There are 31,314 total registered users.
|
|
![[+] expand](/imagery/files/soysauce_blueprint.gif){kind=link}