Log in

View Full Version : Unpacking Mac OSX Dock

crassy
May 7th, 2012, 10:18
Not really malware, but unpacking... I'm curious how the Mac OSX dock (/System/Library/CoreServices/Dock.app/Contents/MacOS/Dock) is encrypted.

The entry point (from the Mach-O header) is 0x1000af4d0

Disassembling the binary gives me bullshit:
Code:
__text:00000001000AF4B0                 db 49h, 3Bh

__text:00000001000AF4B2 ; ---------------------------------------------------------------------------

__text:00000001000AF4B2

__text:00000001000AF4B2 loc_1000AF4B2:                          ; CODE XREF: __text:startj

__text:00000001000AF4B2                 out     dx, eax

__text:00000001000AF4B3                 xchg    eax, r15d

__text:00000001000AF4B5                 xor     cl, bl

__text:00000001000AF4B7                 db      64h

__text:00000001000AF4B7                 in      eax, 43h        ; Timer 8253-5 (AT: 8254.2).

__text:00000001000AF4BA                 xor     edx, [rdi]

__text:00000001000AF4BC                 and     esp, [rax-28h]

__text:00000001000AF4BF                 push    rcx

__text:00000001000AF4C0                 mov     ecx, 0FAFE72B8h

__text:00000001000AF4C5                 nop

__text:00000001000AF4C6                 pushfq

__text:00000001000AF4C7                 nop

__text:00000001000AF4C8                 std

__text:00000001000AF4C9                 punpckhbw mm2, qword ptr cs:0CE50D06Bh

__text:00000001000AF4D0

__text:00000001000AF4D0                 public start

__text:00000001000AF4D0 start:

__text:00000001000AF4D0                 jbe     short loc_1000AF4B2

__text:00000001000AF4D2                 and     bh, [rbp-7Fh]

__text:00000001000AF4D5                 rcr     byte ptr [rcx+38h], cl

__text:00000001000AF4D5 ; ---------------------------------------------------------------------------

__text:00000001000AF4D8 qword_1000AF4D8 dq 8C3EC142500B0FD6h, 316E8AD7EF8C917Ah, 1F425F5349509045h


When starting the process with GDB and putting a breakpoint at the same address I get a much more sensible disassembly:
Code:
0x1000af4d0:	push   0x0

0x1000af4d2:	mov    rbp,rsp

0x1000af4d5:	and    rsp,0xfffffffffffffff0

0x1000af4d9:	mov    rdi,QWORD PTR [rbp+0x8]

0x1000af4dd:	lea    rsi,[rbp+0x10]

0x1000af4e1:	mov    edx,edi

0x1000af4e3:	add    edx,0x1

0x1000af4e6:	shl    edx,0x3


So probably *something* is writing to the process memory before it gets started... But how is that something started? And why doen't gdb break when I put a write breakpoint at that address?

Anyone can point me in the right direction here?
rendari
May 7th, 2012, 11:30
Its probably packed the same way iOS apps are packed on iphone. There is a crypt flag in the mach-o header that you can check just to be sure. Anyways, breakpoint anywhere, and once code section is decrypted dump it to disk. Replace original code section with dumped one, and turn off crypt bit in mach-o header.

Disclaimer: i've only done this on iOS. Might be more work on OS X but i doubt it...
crassy
May 7th, 2012, 13:43
Thanks mate, did the trick.
OHPen
May 8th, 2012, 02:26
@crazzy: the encryption which is used on MacOSX for binaries is quite easy to understand and rendari correctly pointed out a possible solution how to break it.

Here is small paper which describes some parts of the encryption:

http://osxbook.com/book/bonus/chapter7/binaryprotection/

The reason why your write breakpoint is not working can be explained easily. The decryption is part of the loading process of the binary and not trigger by the binary itself. Therefore it is obvious that such an breakpoint won't be triggered. You can set a breakpoint in the loading procedure inside the system itself. If you then set a breakpoint immedialty after the binary image was mapped to memory it will trigger for sure when the decryption is executed.

Hope that helps a little bit.

Regards,
OHPen