Analysis of the sig3 signature of a novel app
1. Objectives
This sample is somewhat similar to the previous short video app. The signature name and algorithm are probably the same. So if you understand this, you can probably understand the latest version of the short video app.
So what is the difference between reading novels and watching short videos?
The more I read novels, the sleepier I feel. The more I watch short videos, the more awake I feel. This proves that AI knows you better than you know yourself.
Today our goal is a novel App v1.0.0.2
2. Steps
1:Search for __sig3
There are only 5 results. After careful searching, I found this atlasSign function.
Searching for the atlasSign function again, although the place of the call is correct this time, we found an old friend at a glance
com.kxxxxxou.android.security.KSecurity
First of all, its name is very unique. Secondly, it was also his signature when I analyzed the short video app last time.
Hook atlasSign
var KSecurityCls = Java.use("com.kxxxxxou.android.security.KSecurity");
KSecurityCls.atlasSign.implementation = function(a){
var rc = this.atlasSign(a);
console.log(TAG + "atlasSign a = " + a);
console.log(TAG + "atlasSign >>> rc = " + rc);
return rc;
}
After running it, the result is there, but the hook outputs 48 bits of data, not the 70-plus bytes of messy data we captured.
There are two options:
- We firmly believe that we are right. To make the __sig3 signature, atlasSign must be called. It is just possible that the 48-bit signature is changed in some way. In this case, we just need to print the stack;
- The result of the captured packet still looks very much like Base64. Although there is no required Base64 feature such as ==, based on the experience of so many issues, you can still try to hook Base64.
Stack
h1yxxs: java.lang.Thread.getStackTrace(Thread.java:1720)
h1yxxs: com.kxxxxxou.android.security.KSecurity.atlasSign(Native Method)
h1yxxs: k.w.e.a1.t.a(SourceFile:34)
h1yxxs: k.w.e.a1.t.a(Native Method)
h1yxxs: k.h.d.h.d.intercept(SourceFile:111)
The fox’s tail is out, this kwea1.ta should be our target
var ffSignCls = Java.use("k.w.e.a1.t");
ffSignCls.a.overload('java.lang.String', 'java.lang.String', 'java.util.Map').implementation = function(a,b,c){
var rc = this.a(a,b,c);
console.log(TAG + "a = " + a);
console.log(TAG + "b = " + b);
console.log(TAG + "c = " + c.entrySet().toArray());
console.log(TAG + ">>> rc = " + rc);
return rc;
}
Run it again, and the result is __sig3.
h1yxksxs: >>> rc = VVftYQGnh_1jN2Q2ODU4NTVjN2U0NmU1ZGM4ZjhjOGQwYjA0MDA5OGMyNDhkN2Y2OTM5ZTkwODY
After some analysis, it turns out that he just made a Base64 of the result of atlasSign and replaced all the obvious + / =.
There is also a dpbs in the input parameter that is encrypted, but this is easier to solve and is in the kwea1.ta class.