Jump to content

IDA + LLDB Tutorial [Noob Friendly]


95 posts in this topic

Recommended Posts

Posted (edited)

@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 xD

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 by Guest
Posted (edited)
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 by Ted2
Posted
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

Posted

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.

Posted
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 

Guest
This topic is now closed to further replies.
×
  • Create New...

Important Information

We would like to place cookies on your device to help make this website better. The website cannot give you the best user experience without cookies. You can accept or decline our cookies. You may also adjust your cookie settings. Privacy Policy - Guidelines