[Feature Request] Add codesign checking function to defense "IPA cracking + temp dev p12 cert"

[wmtj]

Some client-side programs and games that do not depend on the server, which could be easily hacked into the IPA (to modify or remove in-app purchases functions) and re-signed ipa with temp develop p12 cert, and then distributed to the user's phone to bypass in-app purchases.

I hope AIRSDK would add codesign checking function to defense cracking, and maybe it is better than an ANE. Although this only makes it somewhat more difficult to hack(cannot be completely eradicated), I believe it will be helpful for most AIRSDK users.@ajwfrost @marchbold

Here are some references that can be used to defend against ipa cracking :
https://juejin.cn/post/6844904013159202824
https://blog.csdn.net/guoxulieying/article/details/131787414

[ajwfrost]

Hi

We had just been discussing this with another customer (games developer), albeit with a focus on Android where the SWF file is present with all the ActionScript code... for an IPA, your ActionScript has been compiled into machine code already, so it should not be very easy for someone to pull apart an IPA and change the game logic..

So can I clarify what you're trying to prevent, for an IPA? If someone unzips an IPA they could get at the assets, and the SWF files that have had ActionScript removed. Are people adjusting some of these and then re-packaging it (so that essentially they benefit from the game logic/ActionScript stuff still, but with different assets/resources)?

One of the links suggested a mechanism to validate the signing certificate of the bundle, which is something we can do but relies upon the installed app having the same signing certificate as when the package is created with ADT. That may be true for IPA files (at the moment?) but on Android that's not the case as most people would be having their APKs generated and signed by Google, so they'd sign an AAB file with a separate upload certificate, and we wouldn't be able to get at this at runtime.

We're planning to put an initial mechanism for modification-detection in to 51.2, and this will likely go through a number of beta stages before we get something that works suitably! All thoughts on how we could do this are gratefully received, so thank you for the above links!

thanks

[wmtj]

Yes, the actionScript has been compiled into machine code, and the cracker modified the machine code by some tools, not the assets SWF. Cracker can easily locate the in-app purchases functions code, for example: by searching some key words like "Buy" button text, and then change the program logic by simply modifying the "true / false" logic code.

Cracker will re-packaging the ipa file ( unsigned ), and send it to his buyers. The buyer download the ipa, and buy a p12 cert ( Including an automatic signing program), with the automatic signing program, buyers do not need to know technology to complete the signature and installation. (The p12 certificate is generally valid for about one month and can be easily purchased on e-commerce platforms)

Because the hacked ipa used a different p12 signing certificate, I think we can validate the signing certificate to defense cracking. @ajwfrost

[ajwfrost]

Cracker can easily locate the in-app purchases functions code, for example: by searching some key words like "Buy" button text, and then change the program logic by simply modifying the "true / false" logic code.

I'm quite impressed someone would be able to find a bit of text and then spot a bit of code logic that needs to be updated based on that ..! Just wondering, we had been talking about code obfuscation so do you think it would make a difference if the variable names in the app had all been changed into garbage-looking values? And whether it would help for strings like "Buy" to be stored in an encrypted format?

Independent of that, we can certainly look at adding a check in the runtime to get at the application's signing certificate and ensuring it's the same one as is originally used..

thanks

[wmtj]

Code obfuscation plays a role in warding off copycats, prevents code-level replication, and making it harder to crack the ipa/apk(swf)... However, this only has a defensive effect on beginner experienced crackers, experienced crackers will find other clues, such as key function names, for example: "xxx.makePurchase()" methond in the InAppBilling ANE. Method names in ANE are hard to make code obfuscation...

My point is that code obfuscation is useful, but not effective enough, we need a combination of methods, such as the signature verification mentioned above, and other methods mentioned in the links above.

Later, I will send you the cracked ipa and genuine ipa to your email, I hope it would be helpful to your research and analysis. @ajwfrost

[ajwfrost]

I have send it to your harman eamil.

Nothing's arrived here .. likely blocked by our email servers :-(

[wmtj]

I have send it to your harman eamil.

Nothing's arrived here .. likely blocked by our email servers :-(

I have uploaded IPA to the link above about 3 days ago. @ajwfrost

[ajwfrost]

Thanks, received those ones, we'll take a look at what they had done and see if we can add this protection mechanism in. We're looking at a couple of things and trying to get them in to our 51.2 from the start so that any 51.2 runtime will have this kind of protection...

Separately we were looking at obfuscation options within the compiler, that's probably going to take a bit longer though.

thanks

[ajwfrost]

@wmtj just to check something here: looking at those IPA files, we would be able to detect the fact that one has been hacked (via a number of checks, I think!) - but in terms of the code-signing, are these hacked IPAs intended for deployment onto devices directly, or would they be uploaded to the App Store? My slight concern is that if we start checking how the IPA is put together, this is all going to be changed when an application actually gets installed from the App Store, which may mean that we can't rely on things like the code signing staying the same (i.e. Apple re-sign things). Unless you think that these hacked IPAs wouldn't make it through onto the App Store in the first place, and all we're trying to prevent is apps that are intended for side-loading?

thanks

[wmtj]

these hacked IPAs wouldn't make it through onto the App Store

Yes. The hacked IPAs wouldn't make it through onto the App Store. @ajwfrost

Cracker re-packaging the ipa file ( unsigned ), and send it to his buyers. The buyer download the ipa, and buy a p12 cert ( Including an automatic signing program), with the automatic signing program, buyers do not need to know technology to complete the signature and installation. (The p12 certificate is generally valid for about one month and can be easily purchased on e-commerce platforms)