Jump to content

MSHookFunction on sub_x has odd result. Any clue/experience?


Go to solution Solved by Guest,

10 posts in this topic

Recommended Posts

Posted

Been hacking an iOS app. It's a sub_x app thats been a pain in my ass. I've reached the point where I know enough to start hooking.

 

Problem is, while hooking the function i need, via an address (accounting for ASLR), the app crashes when run.

 

So I debug the app via lldb, and something odd is happening.

 

I load the app, attach lldb, and set a breakpoint for the address which I have hooked. I press the button in app and the breakpoint halts the app.

 

The next line to be run, which SHOULD be a B or BL to branch to the new/replacement function is, intead:

.LONG   0x6B007712 (or some address/value large like that). The comment showing is that it's an invalid lvalue.

 

In addition, all subsequent lines are all wrong - it's like MSHookFunction is putting too much data into the address, which is mangling the line, and throwing all other lines off.

 

I'm used MSHookFunction many times before to hook named functions, and it works, and I'm aware of it's uses. This one is a sub_x however, and I've solved the ASLR issue and I've found the memory address for the function (as proven by the lldb breakpoint stopping at the right spot).

 

Has anyone else seen something like this? I feel like I'm missing something really simple. 

Posted (edited)

As it shows in IDA right now its from 0x33f224 through 0x33f2C6, so it's 0xA2/162 bytes long (in assembly).

 

My next trial tomorrow is going to be to lldb debug a mshookfunction that I know works and see how the function is changed, but I am ASSUMING that the first line/s is/are rewritten to a branch and return, and the old_function returned by mshookfunction is a copy of the original. Obviously setting the line to be: .LONG then some huge out of range memory address is incorrect. Driving me batty.

Updated by infernusdoleo
Posted

I've used MSHookFunction on sub_x before. More than once and it has worked well in all cases for me.

Posted

I'm having a hard time understanding your problem but did you include the +1 that you need for thumb binaries? Or maybe you got the branch hex wrong

  • Solution
Posted

+1 for thumb binaries? As in shift the memory address up by 1 so I'm hooking an odd number?

Yeah for thumb you would need a +1 after the offset for some reason

Posted

I'm assuming that if I were hooking a function with a symbol and hooking it by name, it would know that automatically, and maybe my issue is that since I'm hooking by address it doesn't know?

 

I'm gonna give it a shot here shortly, been busy today and haven't had time to break out the hacking tools yet this morning. I'll post my results.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
  • 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