Encrypted Mach-o binary cannot be disassembled/traced with GDB

Question

I'm trying to analyze an encrypted Mach-O binary (non-iPhone one), and I am observing the following strange behaviors:

• when I load this binary into GDB and try to disassemble the code at the address indicated by the entry point, GDB returns garbage instead of any meaningful asm.
• the same happens with radare2
• Hopper disassembler shows the same entry point address but delivers a clear disassembly.

I've tried to execute this application in GDB - nothing works at all. Surprisingly, executing this app from terminal works plenty well.

I'm afraid that my target has been packed/compressed/obfuscated in some way GDB/radare2 cannot cope with. Surprisingly, Hopper processes it pretty well.

Unfortunately, I don't own a full version of the Hopper. Moreover, I would like to be able to debug this app in GDB. Is there any way to do this?

Has anyone else run into something like this? If so, how should I proceed?

Answer 1

Actually, GDB rely on the GNU binutils to open and disassemble the binary. So, the management of the binary format is done through libbfd.so.

Usually, MacOS X binutils comes with the Mach-O management, but it might be that you are using a buggy package. Or, you may also try to open a Mach-O on another system than MacOS X, and on other systems the Mach-O support is extremely rarely added to the default package.

The best way to get the Mach-O support (and all possible formats and architectures in GNU binutils) is to compile the package with the option --enable-targets=all.

Personally, I am using a Debian unstable. and I am used to recompile the whole package taken from sources. Here are the steps to follow:

1. Add the following line to your /etc/apt/sources.list:

   deb-src ftp://ftp.debian.org/debian/ unstable main contrib
   

2. Update your list of packages:

   su -c 'apt-get update'
   

3. Get the packages needed to compile the binutils packages:

   su -c 'apt-get build-dep binutils'
   

4. Get the sources of the binutils packages:

   apt-get source binutils
   

5. Go into the binutils source directory:

   cd binutils-x.x.x/
   

6. In binutils-x.x.x/debian/rules rewrite the following line like this (remove all other targets):

    multiarch_targets = all
   

7. Build the packages (this might take quite a while):

   dpkg-buildpackage -rfakeroot -us -uc
   

8. Install the binutils-multiarch package:

   dpkg -i binutils-multiarch_x.x.x_amd64.deb
   

Answer 2

Many thanks for your answer!

I did some more research and found the following out:

• because my target is a part of the Macintosh system, the so-called "Apple binary protection" protects that from being disassembled/debugged directly.

otool -l [target]" reveals the following information:

Load command 0
  cmd LC_SEGMENT
  cmdsize 532
  segname __TEXT
  vmaddr 0xb8000000
  vmsize 0x001df000
  fileoff 0
  filesize 1961984
  maxprot 0x00000007
  initprot 0x00000005
  nsects 7
 flags 0x8          <-------- "WARNING: encrypted!!!"

Therefore, I need to find a way to decrypt the binary before trying to use GDB on it. I've read that it's possible to do manually using GDB, dd and any suitable hex editor but I couldn't find any stepwise instructions.

This tool claims to be able to do the decryption: http://tumblr.alanquatermain.me/post/97884723/apple-binary-protection-tool

but it doesn't work for me.

Has anyone else here ever dealt with such a binary? Many thanks in advance!

Here some more descriptions of this protection schema: <Link>

http://reverse.put.as/2009/06/30/how-to-dump-an-apple-protected-binary/

UPDATE: I've finally managed to decrypt my target using this tool: http://www.insanelymac.com/forum/topic/285375-apb-decrypt-for-mountain-lion-lion-and-snow-leopard-apple-protected-binary-decryptor/

GDB shows a correct disassembly with "disas 0xb800e5c4" where 0xb800e5c4 indicates the entry point. While the decrypted binary works when launched from terminal, stepping and running inside of GDB still doesn't work though...