undefined | Better HN

0 pointsSomeone123411y ago0 comments

I've decompiled Android APKs before, it wasn't a big technical barrier. Just extract the APK using any zip utility, use Dex2Jar, and then run this: http://jd.benow.ca

I certainly wouldn't patch class files. I'd just extract the private key, then write a new Java application, utilise the same libraries, and point it at the XML. Boom, decrypted.

Is changing a text file a little easier? Perhaps. But extracting the private key is only slightly more work, and the benefits of being able to debug are worth it since the security arguments are pretty weak borderline non-existent.

If you're really paranoid about this just hash log4j.properties and check it on startup. Then crash out with "corrupted log4j.properties, please reinstall" if it has been modified.

0 comments

chrismoos11y ago

I've reverse engineered plenty of Android apps before and yeah, unpacking it and seeing .class files is pretty straightforward. More sophisticated than modifying a text file, but still pretty easy.

Extracting the private key though is not that easy if it is obfuscated well. The key isn't just stored as a static variable and used as-is. I think the overall thing I'm trying to explain is:

* There are different classes of attackers * Everything can be broken, but we want to stop as much people as we can * Layering security is a good thing * Is it really necessary to have the library log the information, as opposed to letting applications decide?

Someone1234OP11y ago

Fair enough. Did you see my point about just hashing log4j.properties's contents? Since I assume you won't be modifying it after you publish as you don't want debugging. As long as you check the hash before you decrypt any XML this should solve your concerns.

In order for someone to then abuse the debugging functionality on Santuario they would need to modify your APK which is frankly just as big of a barrier as finding and pulling the private key(s).

chrismoos11y ago

It would be possible but not that straightforward, you can change how log4j loads/finds properties file, for example, so it would be hard to enforce that.

Its pretty easy to unpack an APK, change log4j stuff to DEBUG, repack, and run vs. unpacking APK, disassemble class files, go through files, find how key is stored, routine for deobfuscation, etc,.

j / k navigate · click thread line to collapse

0 pointsSomeone123411y ago0 comments

I've decompiled Android APKs before, it wasn't a big technical barrier. Just extract the APK using any zip utility, use Dex2Jar, and then run this: http://jd.benow.ca

I certainly wouldn't patch class files. I'd just extract the private key, then write a new Java application, utilise the same libraries, and point it at the XML. Boom, decrypted.

If you're really paranoid about this just hash log4j.properties and check it on startup. Then crash out with "corrupted log4j.properties, please reinstall" if it has been modified.

0 comments

chrismoos11y ago

I've reverse engineered plenty of Android apps before and yeah, unpacking it and seeing .class files is pretty straightforward. More sophisticated than modifying a text file, but still pretty easy.

Extracting the private key though is not that easy if it is obfuscated well. The key isn't just stored as a static variable and used as-is. I think the overall thing I'm trying to explain is:

Someone1234OP11y ago

In order for someone to then abuse the debugging functionality on Santuario they would need to modify your APK which is frankly just as big of a barrier as finding and pulling the private key(s).

chrismoos11y ago

It would be possible but not that straightforward, you can change how log4j loads/finds properties file, for example, so it would be hard to enforce that.

Its pretty easy to unpack an APK, change log4j stuff to DEBUG, repack, and run vs. unpacking APK, disassemble class files, go through files, find how key is stored, routine for deobfuscation, etc,.

j / k navigate · click thread line to collapse