Tutorial IDA + LLDB Tutorial [Noob Friendly]

[Guest]

@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

On September 9, 2017 at 8:58 PM, 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

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

 

On September 9, 2017 at 8:58 PM, 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.

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 39.2k iPhone 13 Pro 16.0 Donor]

5 hours ago, 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.

 

 

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 1.4k iPhone Xs 16.6.1]

Still, too noob for this

Updated January 12, 2018 by Xylla

[Rayan- 160 iPhone 7 Plus 11.1.2]

1 hour ago, Xylla said:

Still, too noob for this

Get good  

[Guest]

3 hours ago, 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.

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

[EvilDevilReX 2.1k iPad Pro (5th gen) 16.3]

wow a lot to do

[trumansh0tmail.de 0]

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 17 iPhone 8 Plus 12.0]

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

Still, too noob for this

I feel

[Juku 5k iPhone SE 11.3.1]

On 3/11/2018 at 7: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.

ios 11 is supported 

[Deadfly 17 iPhone 8 Plus 12.0]

44 minutes ago, Juku said:

ios 11 is supported 

How doth thou install?