infernusdoleo

The hack I'm developing is for a wide user base, across both iOS and Android. While I don't even own an Android and that will be another hill to climb at a later date, a massive portion of the community on the iOS side do not have jailbroken devices. Knowing full well that mobilesubstrate hooking and all the goodies it relies on require a jailbroken phone, and after countless hours of debugging and reverse engineering my target app, I had an idea this morning. I know it's possible to sideload 3rd party apps with Xcode 7. Then there's Extensify, which I've heard of but havent actually seen (assuming it's for real). Plus there are other web-related ways to install apps like GBA4iOS. Assuming it's possible to get a 3rd party app onto your device, wouldnt it be theoretically possible to patch a hooking tweak directly into an app binary? From what I've seen in my face meltingly long hours in gdb and lldb, when you hook a function, the first line of the function is overwritten, redirecting the process flow to the new/replacement function. The original function is copied elsewhere (I think? I havent checked on that part) or at the very least it's callable in a non-mofidied format. Couldn't the binary be patched so that the original function contained the redirect codes the hooking applies, and the binary code from the dylib (clearly visible on a disassembly dump inside lldb) just be correctly appended to the end of the executable? This is all theory - thought of it in the car this morning. But if it's possible, tweaks could be rolled into app bundles and sideloaded into non-JB devices. Or am I insane?

Yup. Like that. I'm a backend coder. Frotn end/GUI shit is not my forte. Need somewhere to start learning that stuff. Read that whole thread, and not sure if thats something you did with a package (the IG in the corner makes it look like it's a package of some sort?) or totally original code. Googling igmm and in game mod menu hasn't gotten me very far.

There's a feature I'd like to code that would require (or at least, really benefit from) having a popup window that could be opened over top of the app as it runs, sort of like how FLEX has the movable/hidable window that floats on top of the app, and doesn't interfere with the app running. Problem is, as I google for some guidance on how to code this, a tutorial, anything, all I get is links for cydia tweaks that popup info (no source code tho) or the video overlap feature/app/tweak. I tried looking at the FLEX source code, and it's SO complicated - I'd like to start somewhere a bit easier. Anyone aware of a tool that has a simple overlay window, or a tutorial on how to do one? I checked the tutorials here, nothing. That I saw anyway. Anything would help. Thanks again.

Nevermind, I found where the code links. The really weird part is there's a function call a few lines back, and about 4 functions deep into that one, the mangler is called. Not sure why the program keeps breaking way after it though. Either way, mystery solved. Sorta.

As I progress in figuring this code out, I just ran into something REALLY weird. The software I'm hacking uses some number mangling function to hide the values in memory. It's hard to tell for sure since it's a sub_x program, but from of what I've seen, it appears that all integers are fed through this function before storing to memory or pulling them back out for use. For example: storing a variable: char_level = mangle_it(mangle_it(old_level)+1); whats_my_level = mangle_it(char_level); Not sure what I wrote above makes 100% sense, I've been staring at code for hours today. Anyway - this function is called 100x a second. Trying to hook and log it almost killed the syslog on my iphone. So I found a memory address I wanted to watch. I set a watchpoint on it. I had the # increase. The program halted inside the mangle function. The weird part - the backtrace never once called the function. The next previous frame was at this line in the assembly: ldr r0, [sp, #0x28] Lines above and below it didn't call the function either. Nothing anywhere near it called the code. Is there some way in C or assembly to hook a variable access so that any time it's read or written it calls a function? It would make sense, given so much is hidden by this function. I'm basically trying to intercept the values before they are set, but without having any clear place WHERE it's set, and it suddenly just popping into this mangler function, seemingly out of nowhere. Any clue?

I'm getting closer to getting this thing hacked to pieces. My next hiccup: I need to search the in-use memory ranges for the app. If I debug it in gdb, I can run: info mach-ranges and it shows me every allocated memory range. In lldb... nothing? Nothing I can see anyway... A link I googled said to use image dump sections, but that only shows me the memory ranges of the program itself and it's loaded libraries etc. NOT the memory that the program malloc'ed AFTER it started. For example, this program malloc's a large 10mb memory range after it fires up. When I run info mach-regions, I can see that range. If I detach, and attach with lldb, and run image dump sections, it doesnt show that range, at all. And no other lldb command I can find will. Any clue how I get this info without using both tools manually? I'm trying to script some stuff. Doing this part manually really kills the whole "script it so its faster" thing.

Havent had much luck figuring out how in lldb. I know how to dump *A* range but not the entire memory range of an app.

The next step in my project is to see where items are loaded into memory. The app loads data from encrypted binary files on disk. Once the app is up and running, I can see the data, somewhat*, in memory by using iGG to search for some of it. What I'd really like to see is what functions are loading it into memory. My end goal is to find the array structure for the data. I think the best way to do this is to breakpoint or hook the loading functions and see whats happening. Problem is, I don't know what is loading it exactly. If I have a memory location, is there any way at all to see WHAT put it there? The location is different each time I run the app, and it's not ASLR different, even accounting for that it's in a different area, so I can't use that. So I can't find it until after it's there. Another option is to breakpoint in some way on file access, but as far as I'm aware thats not possible. Or maybe some other alternative? * What I mean by I can see it 'somewhat' is that the data is loaded into multiple locations. For example, I'm trying to find an item number 1234567, and when iGG searches for it, it finds it 17 times. So manually poking around each memory location trying to figure out any sort of structure would be a huge amount of work. Tracing the info would be easier. If possible.

Sorry I haven't had time to reply - that was exactly my issue. I added 1 to the address and it worked perfectly. Thanks!

My original issue is this dylib was not compiled to be used on iOS9, and I don't have the source, and the devs are highly unresponsive (months to answer a question from what I've seen). Just trying to find some way to use it. Annoying as hell that I can rebase the thing in IDA but not save the modified version. Thats all I need, I believe, from my understanding of segalign. I looked at a working dylib - it started at x5800 or someting similar. This non working one starts at 0x1680. segalign 4000 sets the segment alignment to 4000. And it's probably not THAT simple, but if I can't save it anyway, it's moot. Back to google...

But isn't a linked binary just a bunch of obj files bundled together? Part of my question was is it possible to de-link them? My disassembler can clearly see the different linked libraries inside it. It just has no functionality to save them separately. Wait a moment, I just had an idea. This is a dylib. Is it possible to wrap that inside another dylib? Could code be written that calls functions in the dylib, and have it hard link the library? Can you do that with a dynamic library? Can it be converted with objfile?

Not what I asked. I dont want to recompile it. I want to re-link it. You don't need the source code to link object files. (Unless I'm completely brain farting - I'm almost positive I used to change a library file and re-link the original .o files without having the source code nearby).

Been doing some reverse engineering and would love to use Spark Inspector on a 3rd party iOS app on a jailbroken iphone. Problem is, the dylib that comes with spark inspector will not load on iOS 9 - like with all jailbreak tweaks, it needs to be recompiled with -Wl,segalign,4000 for iOS9 to work with it. Obviously, I have no access to the source code to recompile it. I tried rebasing the program in both IDA and hopper, but neither will write the binary back with the new section alignment. Is there any way to re-link the library, or to unlink, or rebase/realign it without having the source code? It's infuriating - every tool I use or try to is incompatible in some way or another. So I buy a macbook so I can use more commonly available tools, only to find out some of THEM don't even work in iOS 9. I've considered trying to get iOS 8 on this thing somehow, but then god knows how many OTHER things that I've got working will break! Or, alternately, anyone aware of a live debug and trace tool other than spark inspector? I tried Reveal, but that seems to be 99% geared towards UI layout and design, they posted on reddit that they dont have method swizzling and all that to keep the UI design aspect as clean and fast as possible. All other tools I've come across seem to have been abandoned around iOS 6 or 7 and also don't work in 9. Please, save me from going bald. I've already torn out many a handful!

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.

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

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.

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.

In my continuing quest to figure out how this app works (so I can dismantle the hell out of it) I've found myself against a wall and need some more advice. I need to figure out where the program goes when a button is pressed. I thought I had it figured out based on snooping the HTTPS traffic, but after a day of coding, it seems the HTTPS traffic happens AFTER what I'm trying to see happens. So here's my problem. I press a button. Shit happens. The stuff I know to break on is after the button press, but before the known breakpoints. Without being able to live trace the execution, I cannot break the program at the right spot. It's a sub_x program so I have no clue which function to break on without seeing it happen. The problem is if I break on the function that happens after - it's not in the stack. There's a loop, which if I break on it, keeps stopping. But it's a HUGE function. What I'm looking for happens in that function, but it's before something that happens later - it descends into it, does what I need to see, returns back out, moves forward, then descends into what I can break on. That clears that other function from the stack. Is there any way to live trace with lldb? I have access to every platform now - Windows, OS X, linux, iOS directly on the device. Wish I could interrupt the process, press the button on the screen, then 's'tep into the function, but that doesn't work. Process needs to be running to pick up my click. But if it's running, it steps through the process too fast. And the function that loops checking for the click is enormous - to manually check every subroutine would take a week. Anyone? Any clue? Thanks.

No matter which method I use to remove ASLR it crashes when I run it. I'm just connecting, checking the ASLR offset, then rebasing IDA with that value. Annoying when I need to restart the app, but it works.

Thats the issue. The next one is when I disable ASLR the app won't run anymore. This is a damn nightmare!

Yes I got the address from iGG, and I confirmed that it's right. Dumping the memory at that location, after I change the data in-app dumps the new data. But regardless, when I disassemble the code around the address in the frame that lldb tells me is what cause the memory to change, the same code in IDA looks different. Thats my problem. Either lldb is disassembling it wrong (because it thinks it's armv7s instead of armv7) or IDA is disassembling it wrong, having the wrong offsets. Thats the issue, not that I cannot find the code. Hmm it seems my issue may be due to ASLR. Googling...

As I said in my first post, pretty new to decompiling and the like, but a long time coder and I pick stuff up quickly. So please excuse any noobishness or ignorance. I'm trying to reverse engineer an app on iOS. Its been one hell of a process getting this far. After hitting many walls, I picked up a refurb macbook air yesterday, as most of the walls I hit seemed to be able to be bypassed by using a mac for the rest of the work. Made it farther than ever before last night - got a watchpoint to break on a known memory location! Yes! Next step, disassemble the code there, find out whats going on, and how to hack/patch it. Brief setup: App running on ipod 6th gen (only device I have that wasnt on iOS 9.1+ already, ie: jailbreakable) iOS 9.0.2. debugserver from Xcode 7 running on it. Debugserver attached to a cracked, thinned armv7 binary, which I had to first load into gdb to patch out the ptrace anti-debug crap (start gdb, break ptrace, set $r0=-1, continue, disconnect - side note, while I wait for help here I'm gonna try patching that out in the binary itself to skip this step in the future). Remote lldb session running from command line on macbook air. So, I find the location of the code where it's modifying the memory. I then do a disassemble --frame, and it spits out code that looks weird. vsub.f32 d18, d18, d22 movt r1, #0xf767 adcs r0, r1 A lot of that doesnt look familiar at all... I go to the same location in my disassembled copy of the same binary in IDA, and the code is totally different. First of all, I have zero lines that have more than 2 "arguments" to it, it's always an instruction then 2 arguments. So the vsub.f32 with the 3 arguments is odd. Second, nowhere in that area of code do I see a vsub.f32 or an adcs anywhere. So I check the starting address for the function, and its 3BEB78 in the lldb output, but the function at the address in IDA starts at 3BEB44. So I think I'm debugging the wrong binary, so I transfer it from the ipod again, and reload it. No change. I think that because its a 32 bit binary on a 64 bit device, maybe I need to open it in IDA differently. I change the arm type a few times, the output changes, but none match. I try IDA64, nothing. I then remember a bug I had in lldb where I tried to load the symbols from the binary I moved over locally (it complained some error, so I stopped doing it). I re-transferred the binary and tried again. Same error. So I do a target info, and I see something weird. Target #0: /path/appname { arch=armv7s-apple-ios, platform=remote-ios, pid=40071, state=stopped } Target #1: /home/me/appname { arch=armv7-apple-ios, platform=remote-ios } The local copy of the binary is listed as armv7 - which is confirmed on the ipod itself via lipo -detailed_info: iPod-touch:~ root# lipo -detailed_info /path/appname Fat header in: /path/appname fat_magic 0xcafebabe nfat_arch 1 architecture armv7 cputype CPU_TYPE_ARM cpusubtype CPU_SUBTYPE_ARM_V7 offset 16384 size 13224544 align 2^14 (16384) But the REMOTE running copy is reporting as armv7s I think that may be changing how my app is being decompiled in lldb. So I google and I see mention of rebasing the program in IDA, by finding the base address with a info proc map in gdb. Failure - my gdb doesn't have that. I have no /proc directory on the ipod. I try procexp and it gives me a base of 0d4000 (I think, the output is odd) and when I go to rebase it, IDA says the base is 0x4000, so its close, so, maybe? I rebase, but no, it's now tottally wrong. I'm at a loss what to do next. Googling how to find the memory map in lldb isnt coming up with anything. I see no options to specify the arch when using debugserver (since I read thats what reports the arch to the client). Cant see how to set it manually in the client. Anyone? I'm dying here. Thanks.

Just noticed something that may explain the hang... When I do an info watch, the 1st watchpoint is hardware. The second just says "watchpoint" - so that may explain the hang, assuming it's software. But what that doesnt explain is why is the HW watchpoint ignored until I add a software watchpoint?

When you say it will crash my app, do you mean it will crash, or hang? I'm having a really weird issue now. Using GDB, got it running. What I'm watching is an 8 byte/64 bit integer. If I do this: watch *(double *)0x12345678 It never actually catches it. Ever. I know the value is changing, I'm changing it in-app. So then I ^C and leaving the original watchpoint in, I add: watch (double *)0x12345678 (notice the lack of the initial *) I then hit C to continue. It immediately breaks telling me the value of watchpoint ONE (not the new one) changed. If I hit continue again, the app freezes and becomes completely unresponsive. If I ^C and delete watchpoint 2, then continue, the app continues to work, and watchpoint 1 stops reporting. If I ^C and re-add the 2nd watchpoint, again, it will immediately break (if the value changed in the meantime) reporting the change (saying it was watchpoint 1 that caught it). Another continue brings us back to hanging. Really weird. Any clue? Or should I just go get a cheap macbook today?

Quick searching came up with LLDB doesnt work since iOS 8.3 and only option is to use a mac (DiDA posted that on 10/28/15). That still true? Am I screwed until I get a mac to run LLDB on? (Or an iOS device I can downgrade to 8.3?) Any other alternatives?