Topic created on: March 2, 2011 20:09 CST by EFIUnlimited  .
I am at a block, and I need another perspective. I am reversing PowerPC code, and IDA correctly identifies data locations, but when I decode the instructions manually, I don't come up with the same answer IDa does. I can't figure out where I am wrong, and IDA is right.
RAW code:
3C 60 00 0D 38 63 D0 C0
IDA Disassembly:
lis %r3, ((unk_CD0C0+0x10000)@h)
addi %r3, %r3, -0x2F40 # unk_CD0C0
Based on information I have, I know that address 0x0CD0C0 is the correct target data address. However, manual decoding indicates the target address to be 0x10000 higher (0x0DD0C0). How does IDA know to subtract 0x10000???
Brian
|
IDA is not subtracting 0x10000. it is telling you that the address is 0xCD0C0 + 0x10000 == 0xDC0C0 or the same thing that you decoded by hand. The reason that IDA has formatted the operand this way (probably) is that it has created a huge blob of data (probably an array of bytes) beginning at address unk_CD0C0 (0xCD0C0) and the address 0xDC0C0 lies within that declared block. IDA wants to name every location that gets referenced, but this location lies in the middle of data that is already named. Rather than breaking up the data block, IDA uses the name+offset form to format your operand. If you undefine the blob at 0xCD0C0, you can name the byte at 0xDC0C0 and you will see IDA change the operand to reflect your new name.
|
Chris,
The thing is, I have alternate information sources that confirm IDA is correct with address 0xCD0C0, there is no need to rename/move it.
The main area that contains data in this image ranges from 0x91800-0xFFFFF. The location at 0xDC0C0 is currently undefined.
I am figuring this is a PPC specific thing, and there may be some offset register, or something that I am not aware of.
PS: 'The IDA Pro Book' was a good read! I reference it regularly. Unfortunately, I don't know a good source for PPC specific info.
Brian
|
Chris,
Coincidentally, I just saw IDA do what you described above, with respect to creating an offset if the pointed data was already defined. Thing is, it doesn't do this with the location in question. Moreover, there are numerous other similar data references I have found to other locations that all have the same 0x10000 offset.
Brian
|
|
This is somewhat a "feature" of IDA and PowerPC data addresses. Generally speaking, provided what Chris said isn't true, you can mostly ignore the additional offset addition. Those of us that have used IDA with PowerPC long enough pretty much mentally parse that out anyway.
|
aeppert,
I trust what it is doing, so I have been largely ignoring it. It seems to universally apply this 0x10000 offset to any lis/addi pair. I found a lis/ori pair that doesn't have the offset. The reason I am so interested, is statements like this
lbz %r9, -0x2B4C(%r13)
cmplwi %r9, 0
bne loc_106D4
%r13 is used frequently as a base address in this code. I am curious how IDA knew to offset the lis/addi pairs, so I would know if I need to do the same thing to %r13.
Brian
|
0x10000 is added to compensate for the signed low part. The high part actually loaded into r3 is 0xD while the high part of the final address (0xCD0C0) is 0xC. It's done just so the disassembly lines up. It has nothing to do with blobs of data, sorry Chris :)
P.S. IDA 6.1 will have an option to set the r13 base, similar to thr current rtoc/r2 setting.
|
igorsk,
It would be great if IDA would generate xref's relative to %r13. Until I get 6.xx do you know of an IDC that will do it? Otherwise, I'll probably wind up writing one.
I think you have the answer, but I am having trouble following from A-B-C. Is it clobbering the lower bit of 0x0D? Would you mind expanding your explanation?
To refresh,
RAW code:
3C 60 00 0D 38 63 D0 C0
IDA Disassembly:
lis %r3, ((unk_CD0C0+0x10000)@h)
addi %r3, %r3, -0x2F40 # unk_CD0C0
My understanding says this translates to
addis %r3, %r0, 0x000D
addi %r3, %r3, 0xD0C0
Brian
|
Ok, I got it! The problem is I was looking at the ADD like an OR, when really it's a signed long added to a signed short. Here is the break down.
lis %r3, ((unk_CD0C0+0x10000)@h)
This results in 0x000D0000 being placed into %r3. For those with a calculator, this is 851,968 decimal.
addi %r3, %r3, -0x2F40 # unk_CD0C0
This then adds 0xD0C0 to it, which is -12,096 decimal.
When you add 851,968 + (-12,096) you get 839,872, which is 0xCD0C0.
BAM! just like that! Thanks for everyones input!
Brian
|
Igorsk: How do I set the r2 or rtoc base in IDA? Thanks
> igorsk:
>
> P.S. IDA 6.1 will have an option to set the r13 base, similar to thr current rtoc/r2 setting.
|
Note: Registration is required to post to the forums.
|
![[+] expand](/imagery/files/soysauce_blueprint.gif){kind=link}