{"id":784,"date":"2017-11-02T06:40:11","date_gmt":"2017-11-02T14:40:11","guid":{"rendered":"https:\/\/www.pnfsoftware.com\/blog\/?p=784"},"modified":"2017-11-02T06:40:11","modified_gmt":"2017-11-02T14:40:11","slug":"having-fun-with-obfuscated-mach-o-files","status":"publish","type":"post","link":"https:\/\/www.pnfsoftware.com\/blog\/having-fun-with-obfuscated-mach-o-files\/","title":{"rendered":"Having Fun with Obfuscated Mach-O Files"},"content":{"rendered":"

Last week was the release of JEB 2.3.7<\/a> with a brand new parser for Mach-O, the executable file format of Apple\u2019s macOS and iOS operating systems. This file format, like its cousins PE and ELF, contains a lot of technical peculiarities and implementing a reliable parser is not a trivial task.<\/p>\n

During the journey leading to this first Mach-O release, we encountered some interesting executables. This short blog post is about one of them, which uses some Mach-O features to make reverse-engineering harder.<\/p>\n

Recon<\/h1>\n

The executable in question belongs to a well-known adware family dubbed InstallCore, which is usually bundled with others applications to display ads to the users<\/a>.<\/p>\n

The sample we will be using in this post is the following:<\/p>\n

57e4ce2f2f1262f442effc118993058f541cf3fd: Mach-O 64-bit x86_64 executable<\/pre>\n
Let\u2019s first take a look at the Mach-O sections:<\/p>\n
\"\"<\/a>
Figure 1 – Mach-O sections<\/figcaption><\/figure>\n
Interestingly, there are some sections related to the Objective-C language (“__objc_…”<\/em>). Roughly summarized, Objective-C was the main programming language for OS X and iOS applications prior the introduction of Swift. It adds some object-oriented features around C, and it can be difficult to analyze at first, in particular because of its way to call methods<\/a> by “sending messages”.<\/p>\n
Nevertheless, the good news is that Objective-C binaries usually come with a lot of meta-data describing methods and classes, which are used by Objective-C runtime to implement the message passing. These metadata are stored in the “__objc_…”<\/em>\u00a0sections previously mentioned, and the JEB Mach-O parser process them to find and properly name Objective-C methods.<\/p>\n
After the initial analysis, JEB leaves us at the entry point of the program (the yellow line below):<\/p>\n
\"\"<\/a>
Figure 2 – Entry point<\/figcaption><\/figure>\n
Wait a minute\u2026 there is no routine here and it is not even correct x86-64 machine code!<\/p>\n
Most of the detected routines do not look good either; first, there are a few objective-C methods with random looking names like this one:<\/p>\n
\"\"<\/a>
Figure 3 – Objective-C method<\/figcaption><\/figure>\n
Again the code makes very little sense\u2026<\/p>\n
Then comes around 50 native routines, whose code can also clearly not be executed “as is”, for example:<\/p>\n
\"\"<\/a>
Figure 4 – Native routine<\/figcaption><\/figure>\n
Moreover, there are no cross-references on any of these routines! Why would JEB disassembler engine \u2013 which follows a recursive algorithm combined with heuristics \u2013 even think there are routines here?!<\/p>\n
Time for a Deep Dive<\/h1>\n
Code Versus Data<\/h3>\n
First, let\u2019s deal with the numerous unreferenced routines containing no correct machine code. After some digging, we found that they are declared in the LC_FUNCTION_STARTS<\/em> Mach-O command \u2013 “command” being Mach-O word for an entry in the file header.<\/p>\n
This command provides a table containing function entry-points in the executable. It allows for example debuggers to know function boundaries without symbols. At first, this may seem like a blessing for program analysis tools, because distinguishing code from data in a stripped executable is usually a hard problem, to say the least. And hence JEB, like other analysis tools, uses this command to enrich its analysis.<\/p>\n
But this gift from Mach-O comes with a drawback: nothing prevents miscreants to declare function entry points where there are none, and analysis tools will end up analyzing random data as code.<\/p>\n
In this binary, all<\/strong> routines declared in LC_FUNCTION_STARTS<\/em> command are actually not executable. Knowing that, we can simply remove the command from the Mach-O header (i.e. nullified the entry), and ask JEB to re-analyze the file, to ease the reading of the disassembly. We end up with a much shorter routine list:<\/p>\n
\"\"<\/a>
Figure 5 – Routine list<\/figcaption><\/figure>\n
The remaining routines are mostly Objective-C methods declared in the metadata. Once again, nothing prevents developers to forge these metadata to declare method entry points in data. For now, let\u2019s keep those methods here and focus on a more pressing question\u2026<\/p>\n
Where Is the Entry Point?<\/h3>\n
The entry point value used by JEB comes from the LC_UNIXTHREAD<\/em> command contained in the Mach-O header, which specifies a CPU state to load at startup. How could this program be even executable if the declared entry point is not correct machine code (see Figure 2)?<\/p>\n
Surely, there has to be another entry point, which is executed first. There is one indeed, and it has to do with the way the Objective-C runtime initializes the classes. An Objective-C class can implement a method named “+load”<\/em>\u00a0— the + means this is a class method, rather than an instance method –, which will be called during the executable initialization<\/a>, that is before the program main()<\/em>\u00a0function will be executed.<\/p>\n
If we look back at Figure 5, we see that among the random looking method names there is one class with this famous +load<\/em> method, and here is the beginning of its code:<\/p>\n
\"\"<\/a>
Figure 6 – +load method<\/figcaption><\/figure>\n
Finally, some decent looking machine code! We just found the real entry point of the binary, and now the adventure can really begin\u2026<\/p>\n
That\u2019s it for today, stay tuned for more technical sweetness on JEB blog!<\/p>\n","protected":false},"excerpt":{"rendered":"
Last week was the release of JEB 2.3.7 with a brand new parser for Mach-O, the executable file format of Apple\u2019s macOS and iOS operating systems. This file format, like its cousins PE and ELF, contains a lot of technical peculiarities and implementing a reliable parser is not a trivial task. During the journey leading … Continue reading Having Fun with Obfuscated Mach-O Files<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,2,13,5],"tags":[],"class_list":["post-784","post","type-post","status-publish","format-standard","hentry","category-jeb2","category-malware","category-native-code","category-obfuscation"],"_links":{"self":[{"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/posts\/784","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/comments?post=784"}],"version-history":[{"count":0,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/posts\/784\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/media?parent=784"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/categories?post=784"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.pnfsoftware.com\/blog\/wp-json\/wp\/v2\/tags?post=784"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}