This is just some part of the article Android Native Hook工具实践. I translate it in English because there are several e-mails in English sent to me with questions I’ve written in the Chinese article.
I wish I can finish this in the future, I will explain some important part of the project.
How to fix the opcode?
Some e-mails was sent to me about the B.. problems. They find I change BLS to BHI, BNE to BEQ and they think I make a mistake. In fact, I changed them all :
- BEQ –> BNE
- BNE –> BEQ
- BCS –> BCC
- BCC –> BCS
- BMI –> BPL
- BPL –> BMI
- BVS –> BVC
- BVC –> BVS
- BHI –> BLS
- BLS –> BHI
- BGE –> BLT
- BLT –> BGE
- BGT –> BLE
- BLE –> BGT
But I do this on purpose. Let’s see the picture below, it’s beautiful right? Every code has a piece of fix codes, because there isn’t any B.. code.
If there is an B.. code in it, the fix can be the picture below. OMG, I feel sick! The fix code is in two part! And the second part is at the end of the entire fix code! And the X in BLS X is hard to know… , but I use pstInlineHook->backUpFixLengthList to predict and get value of X.
Even worse when there are two B.. code, it’s more complicated, and I wanna vomit:
So how to make the two part in one? I try this, and the fix code is beautiful again~:
But the 12 bytes with 3 jump? I think maybe it can be more beautiful… More pithy and more short, an great idea come to my mind —- opposite logic! This can be 4 bytes shorter in arm32 and thumb32 without adding NOP. And the jump logic is less. It’s like this:
Now the fix code with B.. is beautiful and short. Hahahahaha……..
That’s why you can see the BNE is changed to BEQin fix code.
If you still have some questions please create issue in the repo so the other people can see and help us. I will try my best to answer them in English.
