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


14

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.


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


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

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

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)


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


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


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


2

This tool claims it can move and remove load commands. Might be worth a look.


2

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


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


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

Executable Mach-O files use segment load commands to represent loadable/mappable memory areas. They can be further split into sections. IDA’s Mach-O loader does not use the file offset field in the section headers. The data from file is loaded into database only using segment headers and then split into sections based on the address fields of the section ...


1

I don't know exactly about Mac applications, but .text, .rodata, .data etc are usually at static locations which stay the same while parsing the ELF in a disassembler and during runtime. There's a feature called Position Independent Executables(PIE) in which even these sections are subject to ASLR. In newer gcc versions PIE is enabled by default unless ...


1

well megabeets was faster here is how to check it in windbg 0:000> ? . Evaluate expression: 1999570342 = 772f05a6 0:000> EB . 74 D9 0:000> U . L1 ntdll!LdrpDoDebuggerBreak+0x2c: 772f05a6 74d9 je ntdll!LdrpDoDebuggerBreak+0x7 (772f0581) 0:000> ? 772F0581 - . Evaluate expression: -37 = ffffffdb 0:000> ? 21E5-21C0 Evaluate ...


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