0

I have an Android .so file that uses ARM-V7A instruction set.

I drag it into IDA, and there is one line that shows :

0x1000: b #0x102c

And the hex window shows that the binary code of b #0x102c is 14 e0.

14 e0 has binary format of 0001 0100 1110 0000, which is not how ARM-manual encoded this instruction.

UNLESS

1    4    e    0
0001 0100 1110 0000
8 ----- 1 16 ---- 9

8 -- 1 means 1 bit to 8 bit, 9 -- 16 means 9 bit to 16 bit

Why is instruction encoded this way in .so file ?

For example if I wanted at runtime to change some instruction at some address. Would I change it to 0x14e0 (which is how instruction is encoded in .so file), or change it to 0xe014 (which is how instruction is encoded in ARM-Manual)?

Sep Roland
  • 33,889
  • 7
  • 43
  • 76
user16387400
  • 89
  • 5

1 Answers1

3

Looks like IDA is breaking it into bytes so you'd expect the low 8 bits to be first, as a byte-stream. 14 e0 is the same thing as little-endian e014, a single 16-bit halfword.

(IDA was probably first developed for x86, where machine code is a variable-length byte-stream, not a sequence of 16 or 32-bit chunks, and ported to ARM. This is still a valid way to hexdump ARM machine code, though.)

Re: the title question:

The .text section of an executable or library will get mapped into memory like mmap, without modifications. Except in rare cases of "text relocations" to fix up absolute addresses, e.g. in jump tables in .rodata or movw/movk in .text itself.

But position-independent code generally avoids that, because that's the whole point of being position independent. It's definitely not byte-swapped!

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
  • I misunderstand the word "little endian", I thought it sort all bit other way than `big endian`, but infact it just sort **byte** the other way – user16387400 Jan 21 '22 at 01:19
  • 1
    @user16387400: Yup, byte order is something that happens when you have a way to address individual some smaller parts of a larger thing. (e.g. bytes within words). Since memory is byte-addressable not bit-addressable, bit-order isn't a thing. (In case you were wondering why it's like that; you're correct that it's just a byte order.) – Peter Cordes Jan 21 '22 at 01:22