Hot answers tagged

14

I highly recommend radare2 which seems to suit you the best: radare2 is an open source framework for reverse engineering and binary analysis which implements a rich command line interface for disassembling, analyzing data, patching binaries, comparing data, searching, replacing, visualizing and more. It has great scripting capabilities, it runs on ...


13

There are tools for that, as well as a codesign flag --remove-signature First two should work the same. The codesign flag is undocumented and so YMMV (A user reported in a comment the codesign produced a corrupt executable). You should use any of them with caution and backup the application before using them.


11

When single-stepping through code, the T flag is set so that the CPU can break after the instruction completes execution. When an interrupt occurs, the state of the T flag is placed on the stack, and used when the iret instruction is executed by the handler. However, the iret instruction is one of a few instructions that causes a one-instruction delay in ...


10

Essentially, it's the following workflow: r2 -A /path/to/binary // load the binary and perform initial analysis afl // print function symbols pdf @sym.of.interest // disassemble pdc @sym.of.interest // "decompile" or generate pseudo code Here is an example of how to disassemble a function of MachoViewer: @0x4B6169:/$ r2 -A /...


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


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


6

Well, my Mac fu isn't too strong, but I have terminal access to a Mac and will give it a wild shot, hoping to provide you with the insight required to proceed. info sharedlibrary on the GDB prompt will tell you details about the ranges of the shared libraries inside of which those functions reside. But we know that already from the function names. ...


6

For the first instruction (0x90000008) it matches the opcode below for PC relative addressing instruction. 0x90000008 = 0b10010000000000000000000000001000 so we have op=1 (ADRP), immlo=0, immhi=0 and Rd=8 (X8). The instruction decodes to ADRP X8, #0. This is going take the current page the instruction pointer is at, add 0<<12, and store in register ...


5

This is not free and open source but Hopper Disassembler is $99US for personal use which compared to IDA Pro is super cheap. There is a free trial version if you would like to check it out. https://www.hopperapp.com/


5

As mentioned in your comment, the corresponding opcode to je 0x1000021c0 is 74 D9. Thus, there's no doubt that you are facing a relative JMP. Hopper is translating the relative JMP so it'll be easier for a reverse engineer to understand the flow of the code without having to calculate addresses. I'll demonstrate what Hopper does with a simple example using ...


4

As of 2020, Ghidra should be considered as a major contender. It is challenging IDA Pro in many areas. The integrated decompiler is one of its greatest assets. The support for debugging was added recently on the official repository. It will be added to the next official build. Ref


4

There is no reliable resource which gives an answer to the concrete question if a order exists or not. The question is why would you expect a fixed order of fat_arch sections? The kernel simply loads the Universal Binary at execution time, parses the fat_arch structure(s) and selects a matching architecture type. So in my understanding there is no need for ...


4

Update: Admirably, after just a few days after I sent in a request to include a feature to send input to command line applications, the sole developer of Hopper disassembler has included the feature. Notice the new 'application output' tab in the new Hopper disassembler 3.3.3:


4

If you think the encoding is wrong then you can try these 2 things: Try using x/hs as described here Each time you specify a unit size with x, that size becomes the default unit the next time you use x ... Use x /hs to display 16-bit char strings set the character set in gdb as described here gdb has no way to automatically recognize which ...


4

I wrote a Python script that parses entry points and imports from a Mach-O executable for one of my projects. The trick is to parse the LC_DYLD or LC_DYLD_ONLY loader commands. These two commands encode three import tables: bound symbols, weak symbols, and lazy symbols. struct dyld_info_command { uint32_t cmd; uint32_t cmdsize; uint32_t rebase_off; ...


4

the numeric argument is is an offset into the "compressed dyld info" stream of bytecodes. see https://stackoverflow.com/a/8836580 (iOS/arm but still applies)


3

Dynamic instrumentation tools like Frida or DynomoRIO are probably your best bet. Traditional code injection approaches like mach_inject on os x or detours on windows are things you could look into as well.


3

Code before This is my string relies on addresses/offsets of data (and possibly code) after This is my string. When you insert the string new, you're effectively shifting the code/data after This is my string to the right by 4 bytes. When code before This is my string tries to access that content, it access the wrong content since the location has been ...


3

This is not really an RE question but anyway... On x86, the advantage of using dedicated EBP was that the instructions using it are smaller than those using ESP. It also makes it easier for a compiler (or a human when writing assembly) to track accesses to the stack frame - when using ESP you always need to compensate for every stack pointer adjustment. ...


2

Just use rabin2 -c .... now i have to fill silly text to fill 30 chars


2

There aren't any. Radare is the only open source disassembler (that works on OSX) worth mentioning, and its capabilities are still far away from what you're looking for. https://github.com/radare/radare2 or brew install radare2


2

Since a few versions ago, LC_UNIXTHREAD has been deprecated in favor of the new command, LC_MAIN. #define LC_MAIN (0x28|LC_REQ_DYLD) /* replacement for LC_UNIXTHREAD */ struct entry_point_command { uint32_t cmd; /* LC_MAIN only used in MH_EXECUTE filetypes */ uint32_t cmdsize; /* 24 */ uint64_t entryoff; /* file (__TEXT) offset of main() */ ...


2

Another blunt way that seemed to work for me on Catalina (note that this strips all attributes): xattr -cr /path/to/your/program.app


2

The Mach-O format does support relocations but they appear rarely outside of the object files; usually linker does pretty good job using PIC addressing inside the final linked module. As for imports from other libraries on iOS, they don't use relocations anymore but special tables handled by the dynamic loader (dyld). I've described how they work previously....


2

The officially supported debugging package for Mac OS X is lldb. You can always try GDB which is the legendary GNU Debugger. It is not in any way as fancy as IDA buy you can always spice it up with GDB-Dashboard or gdbgui.


2

otool uses 0-based indexing for load commands and section numbers so it's probably the next section which is problematic. Note that the OS loader only uses segments for mapping the image to the memory so even if the file offsets of the sections are off it should not affect runnability of the program. Some sections may be used by the runtime components like ...


1

If you can run it in QEMU, you can try connecting to the QEMU's GDB stub. Note that this will provide you the CPU-level view, with the OS kernel included, so it may take some work to get to the app's code.


1

Although they are not free, you can try either Hopper Disassembler and Binary Ninja. Both can be bought starting from $99.


1

The offsets in the LC_SEGMENT command are counted from the beginning of the Mach-O header in the file. Normally the Mach-O header is at file offset 0, however OS X and iOS support so-called "fat" files which can contain several Mach-O files (usually for different architectures). You need to account for that and add a corresponding delta to the file offset, ...


1

the addresses are different because the binaries are not identical and differ in their layout. as for finding out which functions are being called: easy solution: use -V to have otool print hints about the symbols being called. hard solution: disassemble target addresses and figure out how the dynamic calls work in OS X and how dyld resolves symbols. it ...


Only top voted, non community-wiki answers of a minimum length are eligible