In this blog post, I present an obfuscation analysis for the latest variant of “InstallCore” PUP/PUA Adware that I encountered in the wild. The adware acts as Installer and deploys multiple apps on the user’s computer. In its latest version, the main Mach-O executable applies code obfuscation which makes it more difficult to identify and debug it. I will investigate and explain how this obfuscation works.
A quick look at the installer:
And how the “offers” of the installer look like:
When I load the main Mach-O executable of the app bundle in the IDA disassembler, I can see that there are no proper instructions at the entry point (0x100001160) and that the opcodes look obfuscated:
Therefore, I can understand that the code needs to be deobfuscated at runtime and loaded to the memory properly before it gets to the entry point and must have some deobfuscation functionality that I should find and investigate.
Note, that because the opcodes will be overwritten at runtime, I cannot use software breakpoints (int 3/cc opcode) to debug the program, consequently, I will set a read/write hardware breakpoint at the entry point, execute and see where the program will break, I can assume that it will be at the place where the deobfuscation occurs:
Here is our deobfuscation routine.
An additional way to find it is to look at the executable segments:
I can notice the “__violably” code segment which looks unusual and has a clean and understandable code:
I can see that it is at the same place where our hardware breakpoint took us earlier.
I can start to analyze this function by finding references to it, to see who calls this function (HeroineshipAflight) and what arguments it passes:
Here I can find the data structure that contains: the length of the data that needs to be deobfuscated (at offset 0), the deobfuscation key (at offset 0x10), and more:
After spending some time debugging this function I identified that the opcodes from the entry point were deobfuscated in chunks of 0x1000 (4096) bytes and XORed with 32 bytes key (shown above). Every deobfuscated chunk of code is saved to a temporary space and then copied (_memcpy) to the original entry point address (In this case our code length is 0x3D9B. There will be 4 chunks in total).
Furthermore, when I put a breakpoint at the end of this function and run the program when it breaks, I see that the code at the entry point is overwritten and looks like a proper code.
After some IDA code reanalyzing, you can see the following understandable and readable code:
Note: In other analyzed “InstallCore” samples, those variants with the obfuscation all contained the same deobfuscation algorithm and the routine is always at the fourth segment, but with a different name. Also, the “HeroineshipAflight” function name changes from sample to sample.
Unlike previous versions of “InstallCore”, it tries to improve its stealth level and evade AV solutions. Even though the obfuscation method is not sophisticated (xor with 32 bytes key), it can impact the detection and make the analysis more challenging. Another interesting aspect that we’ll perhaps mention in a future post is that on top of encrypting the main Mach-O file, the entire app bundle is also encrypted. This is certainly a level up in the actor’s activity.
IoC (Indicators of Compromise)