[not an issue ]Unpack jiagu 360

[apkunpacker]

Awesome blog on unpacking qihoo , i get few sample from koodus but they are packed with jiagu , so i tried frida to dump the dex , dex is dumped but all oncreate method is native . No idea how to get those native oncreate, request to share something to unpack jiagu completely. Thanks

[fvrmatteo]

First of all, sorry for the delayed answer. It's really likely that Jiagu integrated new techniques since when the blogpost has been written, in fact other protectors are using different tricks to "convert" a method to be native.

• SecNeo for example is using a technique that I call "stolen bytecode" that simply consists in encrypting the bytecode of a method during the protection phase and decrypting/loading it at runtime with the help of some libart.so hooks.
• Firehash instead took the game a step further and actually converts the original method into a native counterpart (with the help of the JNI interface).

I don't know which technique is currently being used by Jiagu, but I suspect something similar to SecNeo, so I invite you to check out the ART internals and verify if Jiagu is hooking or taking advantage of any internal function.

If you can provide the Koodous links to some of the apps protected with the Jiagu version you are investigating I'll take a look (time permitting).

[apkunpacker]

0b84f093a94a2a9cbdc87250c077149cd720e80442a6160e0c7233996a7c740a

7c905a48dd2484c43c2cc3ac1a22653059a56af4629baefc10ea70fc46e1b2a1

27d1884b9d2b9cfb4a052b5cbba553186ad787a757dcbb6f095d8a35f05d5230

These are some sample hash from koodus . But I am facing problem with all jiagu packed apk
Specialy
https://t.ly/Bg5eB
or
https://t.ly/0ZdLg

This t. Ly apk has native oncreate in dump.dex if dumped by frida or xposed

[apkunpacker]

Packer scan for above t.l y apk is here
https://github.com/apkunpacker/jiagupacked

[fvrmatteo]

So I took a quick look at live.aiplex.software, the whole unpacking stage is more or less unchanged but, as you mentioned, after dumping the new dynamically loaded dex files there are some methods (not only onCreate) that are marked as native.

Looking at each of the classes containing those methods it's clear that there's always a call to the Jiagu internal function: com.stub.StubApp.interface11(I)V which seems to be a setup function for the "stolen" native methods. In fact on ARM32 a new executable segment is mapped containing stub functions that redirect the execution to a main big function inside the second ELF executable loaded by Jiagu.

Looks like the dispatcher is parsing the shorty descriptor of the incoming method (to properly handle the parameters) and then diverting the execution to other native functions. This looks really similar to what have been done by another protector, Firehash, that actually converted the Dalvik bytecode into JNI functions. The classes protected in this way are in fact marked with the Java annotation @QVMProtect which hints to the possibility that the big dispatcher is actually a Qihoo Virtual Machine (would explain the big switch-case in IDA).

My suggestion is to dump the second ELF stage (the one decompressed by zlib->uncompress()), hook art::JNI::RegisterNatives in libart.so to dump the class/name/signature/address of the JNI registered methods (both Jiagu internal functions and the native stubs) and then analyse interface11, stub and dispatcher with a debugger so it's easier to follow the rationale behind the parsing of the ArtMethod.

Another suggestion would also be to hook all the JNI functions and verify if they are called in a meaningful way during the execution of the big dispatcher.

In this particular sample it seems like there are ~238 stolen methods. If you decide to spend some time on it reversing the logic, please update this GitHub issue. I won't be able to look more into it any time soon, but with these information you should be able to start a proper debugging session focusing on the correct functions.

Any progress about this?

Btw I found a chinese blog that he successfully unpacked OnCreate method, but i'm not much good in reversing protected APK ;-; https://zhuanlan.zhihu.com/p/98456403

[marcussacana]

Sad I have a apk that need a intensive cpu usage, I wanted unpack to see if he will run better without the virtual machine but looks very complex task, better forget and found alternative apps.

[fvrmatteo]

@Toshiba1127 @marcussacana I didn't spend any more time on it, but contributions are welcome if someone wants to explore the implementation of the QihooVM given the head-start information I provided in my previous message.

The shared blogpost is describing exactly the recovery of the onCreate method, what is needed is a tool that automates the conversion from the Qihoo bytecode to the Dalvik bytecode, so analysing the big switch-case I was talking about is a good start.

[marcussacana]

I am still learning, I think the task would be too advanced for me, but it is complicated, I know that trying will not succeed, but if I never try I will not learn.
Also my 'target' have a open source alternative with less features, so I lose motivation to try.

[matrixboot]

Can someone get the original DEX of this APK ?
packer : Jiagu