11

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?

  • 1
    What is the binary? How do you get the "address indicated by the entry point" and how do you disassemble code? Show us some screenshots or text dumps. The more details, the better. – Igor Skochinsky Jul 26 '13 at 22:13
  • Ok, the binary I'm trying to analyze is the part of the Mac OS system software. It appears to be the one of the so-called "Apple-protected" binaries. I've recently found several descriptions of this protection: osxbook.com/book/bonus/chapter7/binaryprotection and even a command-line tool claiming to be able to remove such an encryption here: tumblr.alanquatermain.me/post/97884723/… I've just tried that out but it produces even more garbage... – user1815381 Jul 26 '13 at 23:13
  • What port are you using ? MacPort or another port ? – perror Jul 27 '13 at 12:17
  • Is radare2 using libbfd ? I thought it was using his own library to manage binary format, no ? – perror Jul 29 '13 at 7:19
  • Radare2 uses its own Mach-O parser which doesn't seem to support encrypted binaries. Unfortunately, it contains bugs: the disassembly listing is shifted by four bytes. I'm about to submit an appropriate bug report. – user1815381 Jul 29 '13 at 20:08
10

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
    
9

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: http://osxbook.com/book/bonus/chapter7/binaryprotection/

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

  • 4
    Don't post comments as answers. If necessary, edit your question to add details. – Igor Skochinsky Jul 26 '13 at 23:59
  • 3
    I agree with Igor, and moreover, this is another question. Please fill another question and start from the beginning. – perror Jul 27 '13 at 12:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.