Tutorial IDA + LLDB Tutorial [Noob Friendly]

January 12, 2018

Damn this is a good ass tutorial, I'm gathering up some tuts for Drapes and I stumbled across this one. There's some errors though

LDR             R1, [R0,#0xAC] //Loads the value of R0,#0xAC into R1 (ammo)
SUB             R1, R1, #1 // Substracts the value of one from R1 (ammo) into R1 (ammo)
STR             R1, [R0,#0xAC] //Stores R1 (ammo) into R0,#0xAC]
LDR             R1, =(unk_C80D00 - 0x15281C) //I've no idea, it does load something into our ammo atleast.

The LDR R1, [R0, #0xAC] isn't loading the value of R0,#0xAC because that isn't a value. It's loading the value stored in R0+0xac. R0 is holding the address for some object, and R0+0xAC is the instance variable (or something similar) for ammo. The value held in R0 (0x1501c9c0) is the address for the object stored in memory. 0x1501c9c0 + 0xac (which is 0x1501CA6C) is the memory address for the instance variable of the object at 0x1501c9c0 that holds ammo. Same issue here with the STR R1, [R0, #0xac], its not putting ammo back into R0,#0xAC, its storing the updated value into R0(our object address)+0xac(our ammo instance variable).

Edit: go back to your watchpoints and check out the memory address for ammo. its 0x1501ca6c! again, you set a watchpoint on the instance variable for ammo

On 9/10/2017 at 12:58 AM, Ted2 said:

We can see in the 'register read' output we wrote down, R0 = 0x1501c9c0 in hex decimal, which is 352438720 in decimal value.
This is a big number & get's loaded into our ammo it says.
This doesn't make sense to me, because if that's true we had lots of ammo

Expand

You should update the comments in the assembly and this part with what I typed.

On 9/10/2017 at 12:58 AM, Ted2 said:

How we hack the LDR:

- LDR R1, [R0,#0xAC] to LDR R1, [R7,#0xAC] --> What this does is load R7 (803 million) into our ammo instead of what the normal value should be.

Expand

This is incorrect. R7 typically stores a large garbage number so if the game tries to access R7+0xAC, it 99.9% will crash because its trying to access memory that doesn't exist. Or maybe it won't crash, but it will fail to load the ammo, leaving ammo to be a large uninitialized garbage number when its stored back, making it infinite. Its the same concept as above. R0 is the correct address of our object, R7 is some random thing. R0+0xac = where our ammo instance variable is stored, R7+0xac = ???? And your description of the hacked LDR is wrong, its loading uninitialized memory into R1, and that's what makes it infinite.

Updated January 12, 2018 by Guest

Ted2 · January 12, 2018

On 1/12/2018 at 3:21 AM, shmoo said:
@Ted2

Damn this is a good ass tutorial, I'm gathering up some tuts for Drapes and I stumbled across this one. There's some errors though
LDR             R1, [R0,#0xAC] //Loads the value of R0,#0xAC into R1 (ammo)
SUB             R1, R1, #1 // Substracts the value of one from R1 (ammo) into R1 (ammo)
STR             R1, [R0,#0xAC] //Stores R1 (ammo) into R0,#0xAC]
LDR             R1, =(unk_C80D00 - 0x15281C) //I've no idea, it does load something into our ammo atleast.
The LDR R1, [R0, #0xAC] isn't loading the value of R0,#0xAC because that isn't a value. It's loading the value stored in R0+0xac. R0 is holding the address for some object, and R0+0xAC is the instance variable (or something similar) for ammo. The value held in R0 (0x1501c9c0) is the address for the object stored in memory. 0x1501c9c0 + 0xac (which is 0x1501CA6C) is the memory address for the instance variable of the object at 0x1501c9c0 that holds ammo. Same issue here with the STR R1, [R0, #0xac], its not putting ammo back into R0,#0xAC, its storing the updated value into R0(our object address)+0xac(our ammo instance variable).

Edit: go back to your watchpoints and check out the memory address for ammo. its 0x1501ca6c! again, you set a watchpoint on the instance variable for ammo

You should update the comments in the assembly and this part with what I typed.

This is incorrect. R7 typically stores a large garbage number so if the game tries to access R7+0xAC, it 99.9% will crash because its trying to access memory that doesn't exist. Or maybe it won't crash, but it will fail to load the ammo, leaving ammo to be a large uninitialized garbage number when its stored back, making it infinite. Its the same concept as above. R0 is the correct address of our object, R7 is some random thing. R0+0xac = where our ammo instance variable is stored, R7+0xac = ???? And your description of the hacked LDR is wrong, its loading uninitialized memory into R1, and that's what makes it infinite.
Expand

Thanks, will read & fix when i'm on pc ??. Also, isnt the 0x AC in here [R0,#0xAC] some kind of variable, cause I thought it was, I've never really added it or never seen someone added it to the offset. In unity games, you can actually see what thess #0x.... numbers mean, not that I use that while hacking.

Updated January 12, 2018 by Ted2

Xylla · January 12, 2018

Still, too noob for this

Updated January 12, 2018 by Xylla

Rayan- · January 12, 2018

On 1/12/2018 at 8:59 AM, Xylla said:

Still, too noob for this

Expand

Get good

January 12, 2018

On 1/12/2018 at 8:48 AM, Ted2 said:

Thanks, will read & fix when i'm on pc ??. Also, isnt the 0x AC in here [R0,#0xAC] some kind of variable, cause I thought it was, I've never really added it or never seen someone added it to the offset. In unity games, you can actually see what thess #0x.... numbers mean, not that I use that while hacking.

Expand

read the LDR and STR locations as register+number. The LDR loads whatever is at R0+0xAC into R1

EvilDevilReX · February 3, 2018

wow a lot to do

trumansh0tmail.de · March 11, 2018

F*ck, iOS 11 is not supported, I guess, LLDB have to be rebuilt.

lldb
dyld: Library not loaded: @rpath/liblldb.3.8.dylib
  Referenced from: /usr/bin/lldb
  Reason: no suitable image found.  Did find:
    /usr/bin/../lib/liblldb.3.8.dylib: code signing blocked mmap() of '/usr/bin/../lib/liblldb.3.8.dylib'
    /usr/lib/liblldb.3.8.dylib: code signing blocked mmap() of '/usr/lib/liblldb.3.8.dylib'
Abort trap

Installed libffi, readline via dpkg and Python via cydia.radare

On latest Electra.

Deadfly · March 15, 2018

On 1/12/2018 at 8:59 AM, Xylla said:

Still, too noob for this

Expand

I feel

Juku · March 15, 2018

On 3/11/2018 at 11:29 AM, trumansh0tmail.de said:
F*ck, iOS 11 is not supported, I guess, LLDB have to be rebuilt.
lldb
dyld: Library not loaded: @rpath/liblldb.3.8.dylib
  Referenced from: /usr/bin/lldb
  Reason: no suitable image found.  Did find:
    /usr/bin/../lib/liblldb.3.8.dylib: code signing blocked mmap() of '/usr/bin/../lib/liblldb.3.8.dylib'
    /usr/lib/liblldb.3.8.dylib: code signing blocked mmap() of '/usr/lib/liblldb.3.8.dylib'
Abort trap
Installed libffi, readline via dpkg and Python via cydia.radare

On latest Electra.
Expand