Google I/O 2011: Evading Pirates and Stopping Vampires

What people said

Strong rec Giuseppe Cardone · 2012-02 · Stack Overflow · on “How much effort do I put in my security for Android In App Billing?”

You got it right: you don't need to implement very complex protection features, you need to implement protection features that take too much time to be found and removed Here's a video from Google I/O 2011 about techniques to reduce "leechers": [this video] , I thoroughly recommend it. Some techniques you may want to try are: use LVL; obfuscate code; call LVL at random times from a background thread; insert license checks mixed with normal code;; CRC code files; be industrious: use reflection in JNI to check signatures; encrypt core libraries/resources and load them on the fly. Some of these techniques are very simple, other require a non negligible effort. The best recommendation is to be creati

Strong rec DjLisT · 2014-02 · Stack Overflow · on “How to secure a web service called from Android”

I highly recommend you to watch this great video. Google I/O 2011: Evading Pirates and Stopping Vampires [this video] It was very useful for me, and may be for you.

Recommends Michell Bak · 2011-10 · Stack Overflow · on “Allow or deny copying my app to SD card?”

It is extremely easy to both pirate and reverse-engineer apps regardless of what you do. Java is unfortunately extremely easy to decompile, and if you've got root access on your device, you can make backups of installed application packages. So it's basically up to you, but I wouldn't bother trying to copy protect them. Google has an excellent video on the subject, though, which can be found here: [this video] They've got some good ideas, if you want to go ahead and do it.

Recommends TryTryAgain · 2011-12 · Stack Overflow · on “Avoid apk cracked”

I agree with @Tom van der Woerdt Implement your own licensing library I'd also refer you to check out this from Google I/O 2011: Evading Pirates and Stopping Vampires [this video] EDIT: The Presentation Notes [LINK] from Evading Pirates and Stopping Vampires Some basic keypoints Modify the LVL [LINK] Implement LVL Tamper Resistance [LINK] Use obfuscation [LINK] Add reflection [LINK]

Recommends Roman Minenok · 2012-01 · Stack Overflow · on “How to retrieve customer's email in In-App Billing transaction?”

What I meant is you could prior to sending the data to In-App Billing server you could "remember" that this particular fresh node that you are going to send to In-App Purchase server is "connected" to particular customer's email. It is really difficult to explain in further details. BTW consider watching [this video] video, it's extremely useful and explains some techiques of protection of your in-app purchase processes.

Recommends TryTryAgain · 2012-01 · Stack Overflow · on “How to prevent my android apps from being cracked? (AntiLVL)”

I'd also refer you to check out this from Google I/O 2011: Taken from: Avoid apk cracked [LINK] Thought it may be very useful to you! Evading Pirates and Stopping Vampires [this video] EDIT The Presentation Notes: [LINK] Some basic keypoints Modify the LVL Implement LVL Tamper Resistance Use obfuscation Use reflection

Recommends TryTryAgain · 2012-03 · Stack Overflow · on “Android Game Keeps Getting Hacked”

Taken from my solution from this post Avoid apk cracked [LINK] Implement your own licensing library I'd also refer you to check out this from Google I/O 2011 YouTube recording: Evading Pirates and Stopping Vampires [this video] EDIT: The Presentation Notes [LINK] from Evading Pirates and Stopping Vampires Some basic keypoints Modify the LVL [LINK] Implement LVL Tamper Resistance [LINK] Use obfuscation [LINK] Add reflection [LINK]

Recommends smith324 · 2012-03 · Stack Overflow · on “android app piracy prevention”

Use the LVL (License Verification Library) provided via Google, its a server side verification that the user actually bought your app. [LINK] Use other techniques to detect if you application has been tampered with, there are a few and they are covered in this blog post and the I/O video. Assume it was pirated if tampered with. (Double extra check to make sure you don't mess this up and annoy real users) [LINK] [this video] Use AntiLVL against your own application, attack it like a cracker! This is actually really fun and educational, see how much work it takes to crack your app. The blog/tool go over the known weaknesses and you can make some educated decisions about how to stop the automated to

Recommends TryTryAgain · 2012-04 · Stack Overflow · on “Android piracy prevention with server requests”

Taken from my solution from this post Android Game Keeps Getting Hacked [LINK] Implement your own licensing library I'd also refer you to check out this from Google I/O 2011 YouTube recording: Evading Pirates and Stopping Vampires [this video] EDIT: The Presentation Notes [LINK] from Evading Pirates and Stopping Vampires Some basic keypoints Modify the LVL [LINK] Implement LVL Tamper Resistance [LINK] Use obfuscation [LINK] Add reflection [LINK] The presentation notes contain basic examples and direction for modification. In the youtube video though, there is discussion of server side authentication and how it relates to piracy and asset downloads etc. Specifically using a License Server, In App

Recommends Eric Lafortune · 2012-06 · Stack Overflow · on “How to obsfuscate resource string names in Android?”

If you define a resource string, you will probably define or use it in: the string resource file res/values/strings.xml , layout files res/layout/*.xml , the generated resource file R.java , your java code src/**.java . After compilation, the resource string, its name, and its integer code end up in: the resource file resources.arsc (string, name, and code), the resource class R$string.class (name, code), your compiled code **.class (inlined code). ProGuard will remove R$string.class entirely, but Android decompilers can reconstruct all information from resources.arsc . It still takes a bit of work, but the strings may indeed hint at the purpose of the code (along with certain API calls). Yo