You're missing the fact that you're working in THUMB mode, where you have two bytes per instruction (for most instructions at least), and that link describes ARM mode, where every instruction has 4 bytes.
(How do i know you're in THUMB mode? Apart from your last question, your 0x60ECE B loc_60EE6
isn't 4-byte aligned, so it must be THUMB).
If you add 4 bytes to the instruction at loc_60ECE
, you get 0x60ED2
. Subtract this from 60EE6
to get 14
, or 20 decimal. Divide by 2 (2 byte instructions in THUMB mode) to get 10
decimal, or 0A
hex.
As calculating offsets can be hard and is error-prone, i let the gnu arm assembler handle it for me. First write an assembly file, like this (named q.s, choose any name you want):
.thumb
.arch armv7a
.syntax unified
.org 0x60ECE
B codecave
original:
.org 0x60EE6
codecave:
movw R2, #0x123
B original
then assemble it and check the result:
arm-linux-gnueabi-as q.s
arm-linux-gnueabi-objdump -s a.out | grep -v "00000000 00000000 00000000 00000000"
Contents of section .text:
60ec0 00000000 00000000 00000000 00000ae0 ................
60ee0 00000000 000040f2 2312f1e7 ......@.#...
You see your 0ae0
at 60ece
, and 40f22312f1e7
at 60ee6
. You can patch this in IDA directly, or use the idapatcher plugin to copy/paste the hex. I found this to be much easier than crafting the patched bytes manually.