Anti-Disassembly & obfuscation #1: Does Apple follow its own mach-o specifications?

Original address: http://reverse.put.as/2012/02/02/anti-disassembly-obfuscation-1-apple-doesnt-follow-their-own-mach-o-specifications/

When I think of this feature, I am very happy! Because I like to break through the shackles and write a crackme to show this interesting feature.

The problem arises because Apple does not follow its own documents and standards (MACH-O), but the reverse tools follow.

When the Mach-o file for section information is modified in reverse, Ida may crash, output incorrect disassembly results, and confuse strings.

LLDB output Incorrect disassembly results (not gdb), Class-dump will fail, and the reverse engineer sees the Mach-o file header as meaningless.

Finally, this is an interesting way to confuse. ^_^

When you use Ida to load Crackme, the program will report such an error: Negative section size or offset.

When the sections information (offset or size) exceeds the file size, Otool also outputs the wrong result.

The specific approach to this problem is to modify the section information for Mach-o. Under 32 bits, the structure of the section is as follows:

struct section {/* for 32-bit architectures */charsectname[16];/* name of this section */charsegname[16];/* segment this Section goes in */uint32_taddr;/* memory address of this section */uint32_tsize;/* size in bytes of this section */uint32_ toffset;/* file offset of the */uint32_talign;/* section alignment (Power of 2) */uint32_treloff;/* file offset O F Relocation Entries */uint32_tnreloc;/* number of relocation entries */uint32_tflags;/* flags (section type and attribute s) */uint32_treserved1;/* reserved (for offset or index) */uint32_treserved2;/* reserved (for count or sizeof) */};

Let's start with the offset field that's most likely to cause problems. The definition of standard offset is as follows: Indicates the offset value of the current section in the file.

My understanding is: This field is used to indicate the location of the code or data in the file. You understand that, right?

Since it is an offset value, then theoretically the section is not necessarily ordered in order or in the specified sequential order (mainly refers to: there is no need to match the section in segment). This opens the door to the wrong.

What if we point offset to a different address? For example, IDA needs to read the corresponding data according to the address the offset points to.

Let's do a test, modify the offset value of the CString setion, and then use IDA to load the modified file.

Well, the string in the program is now "confused" because Ida has loaded the wrong data.

It's interesting, isn't it? If you modify the section information (change the offset to an incorrect value) and then run the corresponding program, the program behaves exactly the same!

Similarly, when you modify the text section of the cheap, the program's instructions should be wrong, but the program can still run normally.

Why is the program running correctly? This is very interesting. I think the main reason is that the kernel simply loads the file into memory linearly and ignores the offset.

The description of the EXECVE () system call on page 812 of Mac OS X Internal can explain the cause of the problem.

The Exec_mach_imgact () function (BSD/KERN/KERN_EXEC.C) calls the Load_machfile () function,

The latter is primarily used to load executables, handle specific Mach-o loading commands, and so on. The code snippet is as follows:

@bsd/KERN/KERN_EXEC.C

/*         * Actually load the image file we previously decided to load.         *        /Lret = Load_machfile (IMGP, Mach_header, thread, map, &load_result);

The Parse_machfile () function is called inside Load_machfile () to parse the file.

@bsd/kern/mach_loader.c

Lret = Parse_machfile (VP, Map, Thread, header, File_offset, Macho_size,                              0, result);

Here we can see interesting notes:

/* * The file size of a Mach-o file is limited to + bits; This is because * the "the limit on the Kalloc" () of enough bytes for a mach_header and * the contents of its SIZEOFCMDS , which is currently constrained to a. Bits in the file format itself.  We read into the kernel buffer the * commands sections, and then parse it in order to parse the mach-o file * format Load_c Ommand segment (s).  We are only interested in a subset of * The total set of possible commands. */

In the lower part of the implementation, we can see a loop that handles all the command, where the section command is handled under the SEGMENT (lc_segment/lc_segment_64) command.

Because we need to look at the implementation of the Load_segment ().

Within load_segment (), we found that the validation of executable file legitimacy was done only on the segment level and did not validate the section.

This also causes us to be unable to confuse segment:-)).

When the Parse_machfile () function returns, all the parsing work is done, the linked library is loaded, and the program's entry function is called.

The layout of the program is consistent with the file system (which is what I said earlier), and the section information is not used at all.

This is an implicit convention: The format of the executable file is correct.

Does this behavior (meaning the kernel loads the executable file) correct? I think it's wrong. Because the kernel doesn't follow the mach-o standard, or am I wrong about the standard understanding?

This is another example of trusting untrusted data, and we should explicitly validate the input data.

We should continue to understand the loading process, and another interesting feature in Crackme;-).

We can also change these fields of these section structures: Flags,size, section and segment names, section order.

This can confuse tools and reverse engineers. It is important to note that the same implicit convention follows the kernel, ignoring fields like above.

It's a little weird, isn't it?

I hope you enjoy the analysis process as above, and bring you the power to read xnu and Dyld source code.

With fun,

fg!

Update 1:

The following is the POC of this article's view. The code is a 32-bit, Non-fat mach-o file, console program. If this feature is applied on the objective-c target,

can cause a load error because not all sections can be confused.

Manglemacho.c.gz

SHA256 (manglemacho.c.gz) = D79a612b72130732d7e47b2925fba7fc0b63824622d05f08e7f33641d522a8b5

Update 2:

The actual situation is that all the fields in the upper section can be 0 and will not have any adverse effects (except Mod_init_func).

I tried this, but I didn't take notes. Without further confusion, IDA can sometimes be smart enough to disassemble,

The reason is that the entry address is legal. We can further confuse IDA by modifying size and offset.

You can set all fields of section to 0 by setting the second parameter of the following tool.

Manglemacho_v0.3.c.gz
SHA256 (manglemacho_v0.3.c.gz) = 4b33dc5f43bbb9114e6a8c18dba8894ca44b991cd69a5e5e54bfdcd03607fc9c

-------------------------------------------------

Moqtada

This article describes how to implement anti-disassembly by modifying the section information of Mach-o.

Next we should think about how to restore the modified Mach-o file?!

If the modified Mach-o program also contains: Integrity check, anti-debugging, embedded breakpoint anomaly detection and other characteristics.