I wanted to reverse engineer an old game for Mac OS X, but I can't figure out how the entry point jumps to other code. The binary is an x86 Macho-O executable and, according to Detect it Easy, it was compiled with the Mac OS SDK 10.5.8. I included screenshots of the relevant disassembly from Ghidra.

The entry point seems to be looping, however the the instruction at 0xa747 does an unaligned jump back up to the previous instructions which I find weird in a user space binary like this. Seeing an ARPL is also weird in this context. And what is really weird is that there are no JMPs or CALLs outside of this initial block. I would expect some dynamic linker shenanigans, however the entry point is contained in .__TEXT,.__text which is read and execute only, so modifying anything directly in that section is also very non standard an probably not possible.

The beginning seems to match start.s from the Apple Csu used in Mac OS X 10.5.8 (https://opensource.apple.com/source/Csu/Csu-75/start.s.auto.html) up until the first call in the source file and 0xa730 in my binary .

Perhaps someone who is familiar with Mac OS X can recognize this pattern or give ideas on how a binary like this could execute?

                             LAB_0000a704                                    XREF[1]:     entry:0000a739(j)  
        0000a704 da 8f 9c        FIMUL      dword ptr [EDI + 0xcc33f09c]
                 f0 33 cc
        0000a70a 63 c6           ARPL       SI,param_1
        0000a70c ff              ??         FFh
        0000a70d 90              ??         90h
        0000a70e 90              ??         90h
        0000a70f 90              ??         90h
                             *                          FUNCTION                          *
                             undefined __regparm3 entry(void)
             undefined         AL:1           <RETURN>
             undefined4        Stack[0x0]:4   local_res0                              XREF[1]:     0000a71a(R)  
             undefined4        Stack[-0x1c]:4 local_1c                                XREF[1]:     0000a724(W)  
             undefined4        Stack[-0x20]:4 local_20                                XREF[1]:     0000a71d(*)  
                             entry                                           XREF[1]:     Entry Point(*)  
        0000a710 6a 00           PUSH       0x0
        0000a712 89 e5           MOV        EBP,ESP
        0000a714 83 e4 f0        AND        ESP,0xfffffff0
        0000a717 83 ec 10        SUB        ESP,0x10
                             LAB_0000a71a+1                                  XREF[0,1]:   0000a747(j)  
        0000a71a 8b 5d 04        MOV        EBX,dword ptr [EBP + local_res0]
        0000a71d 89 5c 24 00     MOV        dword ptr [ESP]=>local_20,EBX
        0000a721 8d 4d 08        LEA        ECX=>Stack[0x4],[EBP + 0x8]
        0000a724 89 4c 24 04     MOV        dword ptr [ESP + local_1c],ECX
        0000a728 83 c3 01        ADD        EBX,0x1
        0000a72b c1 e3 02        SHL        EBX,0x2
        0000a72e 01 cb           ADD        EBX,ECX
        0000a730 53              PUSH       EBX
        0000a731 d3 b8 31        SAR        dword ptr [EAX + 0x9c8e3231],CL
                 32 8e 9c
        0000a737 39 da           CMP        EDX,EBX
        0000a739 7b c9           JNP        LAB_0000a704
        0000a73b b0 3f           MOV        AL,0x3f
        0000a73d d8 ca           FMUL       ST2
        0000a73f 6a 59           PUSH       0x59
        0000a741 63 b0 b2        ARPL       word ptr [EAX + 0x1783afb2],SI
                 af 83 17
        0000a747 7c d2           JL         LAB_0000a71a+1
        0000a749 04 c1           ADD        AL,0xc1
        0000a74b 29 53 ba        SUB        dword ptr [EBX + -0x46],EDX
        0000a74e f4              HLT

First part of assembly Second part of assembly

  • it’s best to paste code snippets as text, not images (use code formatting)
    – Igor Skochinsky
    Oct 28, 2023 at 13:30
  • @IgorSkochinsky thank you for telling me. Added the disassembly as text.
    – Ajadaz
    Oct 30, 2023 at 6:15

1 Answer 1


It seems the call __start from start.s is not being disassembled correctly. Possibly Ghidra does not handle some relocation/fixup info. I would suggest verifying with another disassembler and/or filing a bug report.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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