[IDA][mac] Bytes aren't being listed correctly for PPC?

[Tanaris4]

Sorry I know I'm a bit of a n00b in this area, but I have been able to determine byte offsets for around 20 of the locations my bot uses.

I'm now trying to find similar signatures for the PowerPC version of WoW, obviously it's a different instruction set so the Intel signatures will not work. But I'm a bit stumped, I set the opcode length in Options->General to be 8, but it doesn't show more than 4, ever. Clearly there are more bytes here (and the byte signature plugin does the same thing). My guess is the PPC support in IDA may be spotty? Or I'm a n00b and missing something:



The object list manager is 0x11D76CC

Edit: The WoW 3.2.2a binary: http://dump.ifeedr.com/WoWBinaries/W...t%203.2.2a.zip (just choose the PPC when loading obviously)

[_Mike]

There's nothing wrong with IDA's ppc support, all instructions are 32 bit long.
Refer to PowerPC assembly

All PowerPCs (including 64-bit implementations) use fixed-length 32-bit instructions.

[Tanaris4]

where is the extra data stored then that is outside of the 32-bits? If you look @ the 2nd line with dword_11D76CC, it only shows the 011D to the left of it. Where is the 76CC stored?

[_Mike]

where is the extra data stored then that is outside of the 32-bits? If you look @ the 2nd line with dword_11D76CC, it only shows the 011D to the left of it. Where is the 76CC stored?

You really should read that link I gave you, it contains some basic stuff on how ppc assembly works.

--------------------------------------------------------------------------
|    opcode    | src register | dest register |     immediate value      |
|    6 bits    |   5 bits     |    5 bits     |         16 bits          |
--------------------------------------------------------------------------

The number of fields and their sizes will vary by instruction, but the important point here is that these fields take up space in the instruction. In the case of addi, after just those three fields are placed into the instruction, there are only 16 bits left for the immediate value you're adding!

That means that li can only load 16-bit immediates. You cannot load a 32-bit pointer into a GPR with just one instruction. You must use two instructions, loading first the top 16 bits and then the bottom. That is exactly the purpose of the @ha ("high") and @l ("low") suffixes. (The "a" part of @ha takes care of sign extension.) Conveniently, lis (meaning "load immediate shifted") will load directly into the high 16 bits of the GPR. Then all that's left to do is add in the lower bits.

This trick must be used whenever you load an absolute address (or any 32-bit immediate value). The most common use is in referencing globals.

Look at the following addi instruction for the rest of the 32-bit address.
The reason you're getting

lis     %r29, dword_11D76CC@h
addi   %r29, %r29, dword_11D76CC@l

(guess what the @h and @l means)
and not the actual instructions used

addis r29,0,0x11D
addi r29,r29,0x76CC

is because IDA is smart enough to know what that instruction combo does and lists it in a more human-readable format. Although there's probably a setting somewhere to show real instructions if you prefer it, I haven't looked.

Now as to the reason those 2 "instructions" (lis isn't a real intruction, it's a mnemonic) aren't immediately following each other is probably because of compiler optimization.

[Tanaris4]

@_Mike VERY helpful, thanks so much - it makes a lot more sense now