Reverse engineering Java et contournement du mécanisme de paiement inapp Android
1 like583 views
The document discusses the exploitation of Android's in-app billing feature through Java reverse engineering and the Xposed framework, detailed with a case study on the game 'Pandapop'. It outlines a process for manipulating application code to obtain free in-game credits, highlighting security flaws in the in-app billing system. The author concludes with lessons learned and recommendations for improving security measures in Android applications.
Reverse engineering Java et contournement du mécanisme de paiement inapp Android
- 1. Abusing Android In-app Billing feature thanks to a misunderstood integration JUGL 28/09/2017 – Jérémy MATOS
- 2. whois securingapps Developer background Worked last 10 years in Switzerland on security products and solutions Focus on mobile since 2010 OWASP Geneva member Now freelance application security consultant Consulting to build security in software Mobile Web Cloud Internet Of Things Bitcoin/Blockchain @Securingapps
- 3. Agenda 1. Android In-app billing in a nutshell 2. Real-life exploitation in a rather popular game: getting free credits Java reverse engineering Writing a Java hook with Xposed framework Bytecode patching of application and redistribution 3. Lessons learned 4. Recommendations
- 4. 1. Android In-app billing in a nutshell Goal: show that Java reverse engineering can cause a loss of value in real-life Target: Android In-app billing feature Allow developers to sell content in their app, e.g. subscribtions to magazines premium features extra content in games Payment is handled by Google Requires Google Play services No credit card data exposed to developers Documentation available at https://developer.android.com/google/play/billing/index.html
- 5. 1. Android In-app billing in a nutshell
- 6. 2. Real-life exploitation 1/n (Used to be) rather popular game: PandaPop In-app purchases to buy credits New weapons Extra lifes Step 1: Download the APK archive: e.g. from apk-dl.com Avoid executing this binary, or in an emulator
- 7. 2. Real-life exploitation 2/n Step 2: Prepare emulator 1. We will use Genymotion emulator Fast (thanks to x86 image) Rooting possible in 1 click Free version available 2. Install Google Play Services in Genymotion device Drag/drop ARM translation zip + restart Drag/drop gapps-lp-<verions>.zip Google Play errors are normal Wait for the various updates to take place At one point, provide a valid gmail account
- 8. 2. Real-life exploitation 3/n Step 3: use jadx free tool to convert automatically an APK in readable Java source code 1. converts Dalvik bytecode to Java bytecode 2. decompiles Java bytecode in Java source code 3. displays the results in an IDE for analysis Step 4: Look for instances of IInAppBillingService This interface cannot be renamed Nothing is obfuscated!
- 9. 2. Real-life exploitation 4/n Step 5: Easily review related implementation classes Fascinating code in method purchaseProduct of class com.prime31.GoogleIABPlugin Step 6: Find out what android.test.purchased means Google is our friend https://developer.android.com/google/play/billing/billing_testing.html
- 10. 2. Real-life exploitation 5/n Step 7: force value to android.test.purchased and see what happens Let’s write a hook that forces sku of purchaseProduct to this value Using Xposed framework Overload the behavior of an application by intercepting calls in the Dalvik virtual machine No change to the original apk file Implement a hook with Android Studio in an independent apk
- 11. 2. Real-life exploitation 6/n Prerequisites Rooted device to installed the Xposed libraries Emulator (to avoid smartphone bricking…) Install hooking framework in Genymotion device Install terminal application Drag/drop terminal.apk Start it and type su Check that root access is prompted and validate you are really root on the device Drag/drop XposedInstaller_3.1.apk Start it and choose install Reboot the Genymotion device
- 12. 2. Real-life exploitation 7/n
- 13. 2. Real-life exploitation 8/n Step 8: Deploy hook Build hook apk with Android Studio Copy it to Genymotion device Activate hook in Xposed configuration panel Reboot Genymotion device Enjoy free credits Step 9: Bytecode patching Hook requires a rooted smartphone We want to update the original apk to be able to deploy it on any device
- 14. 2. Real-life exploitation 9/n Android doesn’t use Java bytecode but Smali classes.dex contains the Java classes converted to Smali bytecode Smali bytecode can be transformed back and forth to human readble instructions Principle Get readable smali of original class Get readable smali of hook Manual merge hook in original class Rebuild the APK with the new smali code (including signature)
- 15. 2. Real-life exploitation 10/n Convert APK to readable smali with command java -jar apktool.jar d your.apk Edit manually smali code in your/smali Recompiling with apktool loses native library, instead cp your.apk yourPatched.apk java -jar smali_2.1.1.jar your/smali -o classes.dex (to compile smali code) zip yourPatched.apk classes.dex zip --delete yourPatched.apk "META-INF/*" (to delete the existing signature)
- 16. 2. Real-life exploitation 11/n
- 17. 2. Real-life exploitation 12/n Sign the APK with the key of your choice ! Generate a new signing key with keytool -genkey -v -keystore patch.keystore -alias patch -keyalg RSA - keysize 2048 -validity 10000 Enter whatever your want in password and certificate info Sign APK with jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 - keystore patch.keystore yourPatched.apk patch Ensure signature is OK jarsigner -verify -verbose -certs yourPatched.apk Deploy to a non rooted device and play ;) We could even publish in the Play Store under a new name !
- 18. 3. Lessons learned 1/2 Never let debug code in production app An access control decision client side is insecure by design Google documentation is misleading: cf https://developer.android.com/google/play/billing/billing_best_ practices.html
- 19. 3. Lessons learned 2/2 in-app billing can’t be used to buy credits Designed to purchase original content that is not guessable Otherwise always possible to modify the counter via hooking or bytecode patching Responsible disclosure PandaPop team: /dev/null Prime31: quick feedback « the vulnerability doesn't make any sense »
- 20. 4. Recommendations 0. Use Proguard obfuscation to slow down a reverser 1. Use NDK to embed sensitive logic in C code With JNI possible to call C librairies via the native keyword Much more effort to reverse and patch binary code (e.g ARM) 2. Use a backend for validating purchases Still possible to hook/patch the response of the server 3. Only sell « real » content and not something easy to guess like a counter e.g Angry Birds sell extra levels and they also use NDK for calls to validation server
- 22. Conclusion Android Java reverse engineering is really easy with jadx You cannot trust the Java code running in your Android app Modifying and resigning an APK is not difficult Only server side code can be considered secure Google recommendations for in-app purchases are incomplete and misleading By design most in-app uses cases are not possible to secure Only secure use case: download impredictable content from server
- 23. Bonus Possible to debug in Android Studio a reversed app Jadx can export to an Android Studio project Add android:debuggable=’’true’’ in AndroidManifest.xml Resign app Deploy and start debugging from Android Studio
- 24. Any question ? contact@securingapps.com