<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
Peter Stuge wrote:<br>> On Wed, Mar 26, 2008 at 04:27:11AM -0700, Viswesh S wrote:<br>>> I modified the makefile and copied the coreboot before the<br>>> stripping to vis_1strip and then did an objdump.<br>> <br>> coreboot.rom is not an ELF file so elfutils can't really do much good<br>> with it, as you have noticed.<br>a v2 coreboot.rom actualy IS a elf file (the payload) with some stuff <br>(even another elf and a load of binary code) appended...<br>> <br>> <br>>> [viswesh@arka image]$ objdump -D --start-address=0xfffffff0 --stop-address=0xffffffff vis_1strip<br>>> vis_1strip: file format elf32-i386<br>>> Disassembly of section .ram:<br>>> Disassembly of section .rom:<br>>> Disassembly of section .reset:<br>>> fffffff0 <reset_vector>:<br>>> fff0: e9 51 53 ff ff jmp ffff5346 <_start+0x2><br><br>you should do -mi8086 see below<br><br>> <br>> Remember I wrote that it is common to have a far jump very early?<br>> <br>> <br>>> So here I can actually see the flash location and the opcodes in<br>>> that location.<br>>><br>>> But when I do the same, as you mentioned, when I try to dump the<br>>> last 0x20 bytes in coreboot.rom file, I should actually see similar<br>>> instructions and basically there should be a jump in the last 16 bytes.<br>> <br>> If you use an x86 disassembler on the last 16 bytes of coreboot.rom<br>> you will get the above instruction. You can use objdump but it needs<br>> some help. First make a new file starting from the address you are<br>> interested in:<br>> <br>> stuge@n410c ~/co/v2/targets/gigabyte/m57sli/m57sli $ dd if=coreboot.rom of=out bs=$[524288-16] skip=1<br>> 0+1 records in<br>> 0+1 records out<br>> 16 bytes (16 B) copied, 0.000135259 s, 118 kB/s<br><br>i agree (524288 is you chip size......<br>> <br>> Then disassemble:<br>> <br>> stuge@n410c ~/co/v2/targets/gigabyte/m57sli/m57sli $ objdump -b binary -m i386 -D out<br>wrong should be<br><br> objdump -b binary -m i8086 -D out<br>remember that ALL cpus of teh x86 famaly EVEN the most new ones start <br>basicaly as an 8086 aka in realmode (it has some tricks in place with CS <br>but thats another story and quete hard to follow)....<br>bottom line is that objdump does proetct mode disassemble when dont give <br>a -m of give -mi386 ...<br>-mi8086 makes it do realmode disasmbly and that what you will need for <br>the first ??(100 ?? orso) bytes that get executed .. basicaly that jump<br>then some segment discriptor setup and the switch to protected mode<br><br>> <br>> out: file format binary<br>> <br>> Disassembly of section .data:<br>> <br>> 0000000000000000 <.data>:<br>> 0: e9 11 f0 ff ff jmp 0xfffff016<br>> 5: 00 00 add %al,(%eax)<br>> 7: 00 e9 add %ch,%cl<br>> 9: 5f pop %edi<br>> a: f0 ff lock (bad) <br>> c: ff 00 incl (%eax)<br>> ...<br>> stuge@n410c ~/co/v2/targets/gigabyte/m57sli/m57sli $ <br>> <br>> The addresses say 0 but if you prefer just use the --start-address<br>> option.<br>> <br>> <br>>> [viswesh@arka image]$ objdump -D coreboot.rom | grep -ni reset_vector<br>>> [viswesh@arka image]$ objdump -D coreboot.rom | grep -ni _start<br>> <br>> Will not work since coreboot.rom is not in a file format that objdump<br>> can parse correctly.<br>> <br>> <br>>> [viswesh@arka image]$ objdump -D coreboot.rom | tail<br>>> 13cf96: 00 00 add %al,(%eax)<br>>> 13cf98: 00 00 add %al,(%eax)<br>>> 13cf9a: 00 00 add %al,(%eax)<br>>> 13cf9c: d1 e5 shl %ebp<br>>> 13cf9e: 10 00 adc %al,(%eax)<br>>> 13cfa0: 08 00 or %al,(%eax)<br>>> 13cfa2: 00 00 add %al,(%eax)<br>>> 13cfa4: 27 daa<br>>> 13cfa5: e7 10 out %eax,$0x10<br>>> ...<br>>> [viswesh@arka image]$<br>>><br>>> So here also we dont see any jump to a specific location.<br>> <br>> Again, objdump treats coreboot.rom as an ELF file, which it is not,<br>> and so you get garbage output.<br>it is .. and you are looking at the payload ....<br>> <br>>> So basically where should be the code which should be flashed into<br>>> the location 0xfffffff0.<br>> <br>> It is 16 bytes from the end of coreboot.rom.<br>> <br>>>From your previous work you may be used to working with hex files or<br>> S-records which contain both address and data. Because x86 always<br>> starts at top of 4GB there is no need for address information.<br>> <br>> The flash chip must always be at the top of 4GB. The binary flash<br>> file is always written to the top of the flash.<br>> <br>> <br>>> (or) how can I locate the code inside the coreboot.rom,if it is<br>>> there inside the rom file.<br>> <br>> The dd and objdump trick I show above will work but is very clumsy<br>> and does not scale well.<br>you can also force objdump to start at the end of the file wit <br>--start-address= but you still need to specify -bbinary (and -mi8086 for <br>the parts before the pmode switch)<br>> <br>> I recommend the DOS utility HIEW (Hackers View) if you're going to be<br>> taking apart binary files. It has some useful disassembly options.<br>> <br>> The thing with dd and objdump is that because there are bytes in the<br>> coreboot.rom stream that are not instructions but instead data, it is<br>> not neccessarily possible to disassemble the entire coreboot.rom file<br>> in one go and then take it apart. When data at one byte position is<br>> parsed as an instruction it may parse the following byte as part of<br>> the same instruction which causes an error in alignment in the<br>> disassembler because the data byte in the first position was actually<br>> the last data byte and the following byte was the first byte of an<br>> instruction. This is why you usually have to explicitly chop up the<br>> binary file at whatever boundary you are interested in.<br>> <br>> <br>> But why are you doing this anyway? Wouldn't it be easier to just look<br>> at the source code?<br>> <br>> <br>> //Peter<br>> <br>Reinder<br><br><br /><hr />Express yourself instantly with MSN Messenger! <a href='http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/' target='_new'>MSN Messenger</a></body>
</html>