Help/Support Disassembled code in IDA does not match that in GDB/LLDB

infernusdoleo · December 16, 2015

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.

ITz_kser · December 16, 2015

Did you get the correct address from IGG/GP?

Also the LLDB address isn't always the hackable function look around it

and you can breakpoint the function to see if it correct or not

infernusdoleo · December 16, 2015

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...

infernusdoleo · December 16, 2015

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

ITz_kser · December 16, 2015

On 12/16/2015 at 2:35 PM, infernusdoleo said:

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...

if it the ASLR then you can remove it easily also is your binary cracked?

because the cracking tools normally remove the ASLR

also thin your binary before using IGG to know the address if you didn't before

On 12/16/2015 at 3:36 PM, infernusdoleo said:
Thats the issue. The next one is when I disable ASLR the app won't run anymore. This is a damn nightmare!

sign the binary and make the permissions 777

also the binary need to be cracked before use it in IDA also thin it

infernusdoleo · December 18, 2015

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.

Elreys · February 1, 2016

Hey infernusdoleo , how you did a rebase in IDA Pro? I have the same problem on my Reversed App, wrong offset and wrong llldb address please if you have time write me back,

Thanks

ELREYS

Updated February 1, 2016 by ELREYS

Diversityy · February 3, 2016

On 12/18/2015 at 3:50 AM, infernusdoleo said:
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.

Hey bud,

Since Remove ASLR isn't working for you, maybe you should give this a go? The tool, linked below, can thin binaries, remove ASLR, class dump, strings, and symbols.

https://iosgods.com/topic/20338-binary-tools-online-strings-symbols-binary-thinning-class-dump-and-remove-aslrpie/

Rook · February 6, 2016

On 12/18/2015 at 3:50 AM, infernusdoleo said:
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.

On 2/1/2016 at 7:22 PM, ELREYS said:

Hey infernusdoleo , how you did a rebase in IDA Pro? I have the same problem on my Reversed App, wrong offset and wrong llldb address please if you have time write me back,

Thanks

ELREYS

^^

You can also defeat ASLR without removing it: https://iosgods.com/topic/19378-how-to-defeatremove-aslr-on-ios-9-armv7-and-arm64-devices/