How to avoid reverse engineering of an APK file

Question

I am developing a payment processing app for Android, and I want to prevent a hacker from accessing any resources, assets or source code from the APK file.

If someone changes the .apk extension to .zip then they can unzip it and easily access all the app's resources and assets, and using dex2jar and a Java decompiler, they can also access the source code. It's very easy to reverse engineer an Android APK file - for more details see Stack Overflow question Reverse engineering from an APK file to a project.

I have used the Proguard tool provided with the Android SDK. When I reverse engineer an APK file generated using a signed keystore and Proguard, I get obfuscated code.

However, the names of Android components remain unchanged and some code, like key-values used in the app, remains unchanged. As per Proguard documentation the tool can't obfuscate components mentioned in the Manifest file.

Now my questions are:

1. How can I completely prevent reverse engineering of an Android APK? Is this possible?
2. How can I protect all the app's resources, assets and source code so that hackers can't hack the APK file in any way?
3. Is there a way to make hacking more tough or even impossible? What more can I do to protect the source code in my APK file?

Solution 1

 1. How can I completely avoid reverse engineering of an Android APK? Is this possible?

AFAIK, there is not any trick for complete avoidance of reverse engineering.

And also very well said by @inazaruk: Whatever you do to your code, a potential attacker is able to change it in any way she or he finds it feasible. You basically can't protect your application from being modified. And any protection you put in there can be disabled/removed.

 2. How can I protect all the app's resources, assets and source code so that hackers can't hack the APK file in any way?

You can do different tricks to make hacking harder though. For example, use obfuscation (if it's Java code). This usually slows down reverse engineering significantly.

 3. Is there a way to make hacking more tough or even impossible? What more can I do to protect the source code in my APK file?

As everyone says, and as you probably know, there's no 100% security. But the place to start for Android, that Google has built in, is ProGuard. If you have the option of including shared libraries, you can include the needed code in C++ to verify file sizes, integration, etc. If you need to add an external native library to your APK's library folder on every build, then you can use it by the below suggestion.

Put the library in the native library path which defaults to "libs" in your project folder. If you built the native code for the 'armeabi' target then put it under libs/armeabi. If it was built with armeabi-v7a then put it under libs/armeabi-v7a.

<project>/libs/armeabi/libstuff.so

Solution 2

AFAIK, you cannot protect the files in the /res directory anymore than they are protected right now.

However, there are steps you can take to protect your source code, or at least what it does if not everything.

1. Use tools like ProGuard. These will obfuscate your code, and make it harder to read when decompiled, if not impossible.
2. Move the most critical parts of the service out of the app, and into a webservice, hidden behind a server side language like PHP. For example, if you have an algorithm that's taken you a million dollars to write. You obviously don't want people stealing it out of your app. Move the algorithm and have it process the data on a remote server, and use the app to simply provide it with the data. Or use the NDK to write them natively into .so files, which are much less likely to be decompiled than apks. I don't think a decompiler for .so files even exists as of now (and even if it did, it wouldn't be as good as the Java decompilers). Additionally, as @nikolay mentioned in the comments, you should use SSL when interacting between the server and device.
3. When storing values on the device, don't store them in a raw format. For example, if you have a game, and you're storing the amount of in game currency the user has in SharedPreferences. Let's assume it's 10000 coins. Instead of saving 10000 directly, save it using an algorithm like ((currency*2)+1)/13. So instead of 10000, you save 1538.53846154 into the SharedPreferences. However, the above example isn't perfect, and you'll have to work to come up with an equation that won't lose currency to rounding errors etc.
4. You can do a similar thing for server side tasks. Now for an example, let's actually take your payment processing app. Let's say the user has to make a payment of $200. Instead of sending a raw $200 value to the server, send a series of smaller, predefined, values that add up to $200. For example, have a file or table on your server that equates words with values. So let's say that Charlie corresponds to $47, and John to $3. So instead of sending $200, you can send Charlie four times and John four times. On the server, interpret what they mean and add it up. This prevents a hacker from sending arbitrary values to your server, as they do not know what word corresponds to what value. As an added measure of security, you could have an equation similar to point 3 for this as well, and change the keywords every n number of days.
5. Finally, you can insert random useless source code into your app, so that the hacker is looking for a needle in a haystack. Insert random classes containing snippets from the internet, or just functions for calculating random things like the Fibonacci sequence. Make sure these classes compile, but aren't used by the actual functionality of the app. Add enough of these false classes, and the hacker would have a tough time finding your real code.

All in all, there's no way to protect your app 100%. You can make it harder, but not impossible. Your web server could be compromised, the hacker could figure out your keywords by monitoring multiple transaction amounts and the keywords you send for it, the hacker could painstakingly go through the source and figure out which code is a dummy.

You can only fight back, but never win.

Solution 3

At no point in the history of computing has it ever been possible to prevent reverse-engineering of software when you give a working copy of it to your attacker. Also, in most likelihood, it never will be possible.

With that understood, there is an obvious solution: don't give your secrets to your attacker. While you can't protect the contents of your APK, what you can protect is anything you don't distribute. Typically this is server-side software used for things like activation, payments, rule-enforcement, and other juicy bits of code. You can protect valuable assets by not distributing them in your APK. Instead, set up a server that responds to requests from your app, "uses" the assets (whatever that might mean) and then sends the result back to the app. If this model doesn't work for the assets you have in mind, then you may want to re-think your strategy.

Also, if your primary goal is to prevent app piracy: don't even bother. You've already burned more time and money on this problem than any anti-piracy measure could possibly ever hope to save you. The return on investment for solving this problem is so low that it doesn't make sense to even think about it.

Solution 4

First rule of app security: Any machine to which an attacker gains unrestricted physical or electronic access now belongs to your attacker, regardless of where it actually is or what you paid for it.

Second rule of app security: Any software that leaves the physical boundaries inside which an attacker cannot penetrate now belongs to your attacker, regardless of how much time you spent coding it.

Third rule: Any information that leaves those same physical boundaries that an attacker cannot penetrate now belongs to your attacker, no matter how valuable it is to you.

The foundations of information technology security are based on these three fundamental principles; the only truly secure computer is the one locked in a safe, inside a Farraday cage, inside a steel cage. There are computers that spend most of their service lives in just this state; once a year (or less), they generate the private keys for trusted root certification authorities (in front of a host of witnesses with cameras recording every inch of the room in which they are located).

Now, most computers are not used under these types of environments; they're physically out in the open, connected to the Internet over a wireless radio channel. In short, they're vulnerable, as is their software. They are therefore not to be trusted. There are certain things that computers and their software must know or do in order to be useful, but care must be taken to ensure that they can never know or do enough to cause damage (at least not permanent damage outside the bounds of that single machine).

You already knew all this; that's why you're trying to protect the code of your application. But, therein lies the first problem; obfuscation tools can make the code a mess for a human to try to dig through, but the program still has to run; that means the actual logic flow of the app and the data it uses are unaffected by obfuscation. Given a little tenacity, an attacker can simply un-obfuscate the code, and that's not even necessary in certain cases where what he's looking at can't be anything else but what he's looking for.

Instead, you should be trying to ensure that an attacker cannot do anything with your code, no matter how easy it is for him to obtain a clear copy of it. That means, no hard-coded secrets, because those secrets aren't secret as soon as the code leaves the building in which you developed it.

These key-values you have hard-coded should be removed from the application's source code entirely. Instead, they should be in one of three places; volatile memory on the device, which is harder (but still not impossible) for an attacker to obtain an offline copy of; permanently on the server cluster, to which you control access with an iron fist; or in a second data store unrelated to your device or servers, such as a physical card or in your user's memories (meaning it will eventually be in volatile memory, but it doesn't have to be for long).

Consider the following scheme. The user enters their credentials for the app from memory into the device. You must, unfortunately, trust that the user's device is not already compromised by a keylogger or Trojan; the best you can do in this regard is to implement multi-factor security, by remembering hard-to-fake identifying information about the devices the user has used (MAC/IP, IMEI, etc), and providing at least one additional channel by which a login attempt on an unfamiliar device can be verified.

The credentials, once entered, are obfuscated by the client software (using a secure hash), and the plain-text credentials discarded; they have served their purpose. The obfuscated credentials are sent over a secure channel to the certificate-authenticated server, which hashes them again to produce the data used to verify the validity of the login. This way, the client never knows what is actually compared to the database value, the app server never knows the plaintext credentials behind what it receives for validation, the data server never knows how the data it stores for validation is produced, and a man in the middle sees only gibberish even if the secure channel were compromised.

Once verified, the server transmits back a token over the channel. The token is only useful within the secure session, is composed of either random noise or an encrypted (and thus verifiable) copy of the session identifiers, and the client application must send this token on the same channel to the server as part of any request to do something. The client application will do this many times, because it can't do anything involving money, sensitive data, or anything else that could be damaging by itself; it must instead ask the server to do this task. The client application will never write any sensitive information to persistent memory on the device itself, at least not in plain text; the client can ask the server over the secure channel for a symmetric key to encrypt any local data, which the server will remember; in a later session the client can ask the server for the same key to decrypt the data for use in volatile memory. That data won't be the only copy, either; anything the client stores should also be transmitted in some form to the server.

Obviously, this makes your application heavily dependent on Internet access; the client device cannot perform any of its basic functions without proper connection to and authentication by the server. No different than Facebook, really.

Now, the computer that the attacker wants is your server, because it and not the client app/device is the thing that can make him money or cause other people pain for his enjoyment. That's OK; you get much more bang for your buck spending money and effort to secure the server than in trying to secure all the clients. The server can be behind all kinds of firewalls and other electronic security, and additionally can be physically secured behind steel, concrete, keycard/pin access, and 24-hour video surveillance. Your attacker would need to be very sophisticated indeed to gain any kind of access to the server directly, and you would (should) know about it immediately.

The best an attacker can do is steal a user's phone and credentials and log in to the server with the limited rights of the client. Should this happen, just like losing a credit card, the legitimate user should be instructed to call an 800 number (preferably easy to remember, and not on the back of a card they'd carry in their purse, wallet or briefcase which could be stolen alongside the mobile device) from any phone they can access that connects them directly to your customer service. They state their phone was stolen, provide some basic unique identifier, and the account is locked, any transactions the attacker may have been able to process are rolled back, and the attacker is back to square one.

Solution 5

 1. How can I completely avoid reverse engineering of an Android APK? Is this possible?

This isn't possible

 2. How can I protect all the app's resources, assets and source code so that hackers can't hack the APK file in any way?

When somebody change a .apk extension to .zip, then after unzipping, someone can easily get all resources (except Manifest.xml), but with APKtool one can get the real content of the manifest file too. Again, a no.

 3. Is there a way to make hacking more tough or even impossible? What more can I do to protect the source code in my APK file?

Again, no, but you can prevent upto some level, that is,

• Download a resource from the Web and do some encryption process
• Use a pre-compiled native library (C, C++, JNI, NDK)
• Always perform some hashing (MD5/SHA keys or any other logic)

Even with Smali, people can play with your code. All in all, it's not POSSIBLE.

View more solutions

Comments

[Nikolay Elenkov]

HoseDex2Jar is next to useless. It only 'confuses' dex2jar and can easily be blocked. smali/apktool, etc. work just fine with 'hosed' APKs.

[Nikolay Elenkov]

Instead of doing tricks with values you send to your server, use SSL and properly validate the server certificate. Security by obscurity is generally a bad idea.

[Raghav Sood]

@NikolayElenkov That would only protect the values during the transfer from device to server. By obscuring it, you can protect it while it is in the RAM, and in device storage.

[Raghav Sood]

Well, true :P But there's no point just sitting back and letting the hacker have a free run.

[Nikolay Elenkov]

BTW, the same goes for storing things in files: use proper obfuscation or encryption, not easy tricks.

[sachin003]

For Payment transaction I've used ISO 8585 standard, right now schema for this standard is in key-value pair using HashMap collection of Java & when I do reverse engineering on apk I'll get all schema.Is it possible to avoid schema get exposed via reverse engineering.? Can your last suggestion of Share libraries useful in this case? Doy you have any links so that I can get exposure to the share libraries in android.

[sachin003]

@NikolayElenkov Do you know how HoseDex2Jar works? What they have used to avoid or to confuse dex2jar.Because I can't upload my apk file to web to use HoseDex2Jar. If I can do something like HoseDex2Jar to confuse dex2jar then It will make tough to hack using dex2jar tool.

[Anirudh Ramanathan]

you can insert random useless source code into your app. This can't really help either. This will only bloat your application up, while making it harder to maintain as well.

[Raghav Sood]

@Cthulhu these aren't meant to help with the server side or the mid transaction. These are meant to help with the case where someone decompiles your app and goes through the code to look at your implementation etc. with the intention to steal it. If you have random code, it's harder for them to find what they want.

[Anirudh Ramanathan]

harder? Yes. But they don't give you anything but a false sense of security. It isn't that hard to weed out the code which is never executed, so why bother doing that.

[Raghav Sood]

I get that, and I fully agree. While it may not be amazingly secure or a major roadblock to the hacker, it does provide some protection, even if it is minor.

[Benoit Duffez]

You could also fake use the useless code and send the data to the server which will discard it. False security maybe, but a pain in the ass for the potential hacker, right?

[Maciej Piechotka]

As a side note (disclaimer: IANAL) - license will not protect application under all jurisdictions in all circumstances (for example in some countries in Europe it is allowed to disassembly in order to increase compatibility).

[kutschkem]

how about encrypting your strings in the code and decrypting them at runtime? If you do the decryption on a remote server, like other people suggested, you don't get the problem that the decryption key is in the sources.

[Bhavesh Patadiya]

yes, encryption is way, but it is not sure to be notHacked. If i am encrypting String in order to decrypt them, i need one unique id in the code. and if anyone able to decompile it then it will be very easy to get the Unique id.

[Phoshi]

If your algorithm is worth a million dollars, then just because there's no decompiler for .so files doesn't mean I can't read assembly :) Most of these fall into the same trap, just obfuscating instead of properly protecting yourself. Obfuscation only works if it's not worth an attacker's time to follow through, so if you build something on these techniques you'd better hope they don't get popular, otherwise you're screwed because all of a sudden your codebase is unmaintainable and it needs huge changes.

[Trevor Boyd Smith]

RE - "This isn't possible": Sounds like APK system needs some way of encryption somehow. Matlab has a similar problem of needing to protect IP in deployed applications. Matlab's solution was to use some encryption. Do you think maybe Android APK needs something similar?

[Nikolay Elenkov]

Maybe you misunderstood my point: what HoseDex2Jar does is repack your APK so that the popular dex2jar tool cannot (out of the box) reverse it. However other tools can, and it is very easy to defeat it generally. No point in using it. No one mentioned Dexguard I thing (by the author of ProGuard; not free), but it is work looking at. It does a few more thing than 'regular' obfuscation.

[Daniel Pryden]

The first paragraph is the best answer. If your attacker controls the hardware, they will always be able to defeat your software somehow. Anything that truly needs to be protected must stay on hardware you control, it's as simple as that. And the final paragraph, about ROI, is spot on as well.

[cHao]

@TrevorBoydSmith: Encryption doesn't help much when the OS is open source and rootable. The system needs a key in order to decrypt the APK and run stuff. And if the system has a key, and i have unfettered access to the system, then i know where to find the key and can get to it. Meaning i have the key now too.

[Mohammed Azharuddin Shaikh]

why you added Edited stuff? its all regular.

[Bhavesh Patadiya]

@hotveryspicy: yes i have now removed the "edited" mark from answer.i have edited my answer beacause he wanted to know more about how Share libraries useful in this case.

[Trevor Boyd Smith]

@cHao. I purposely did not specify how to do the encryption because encryption is outside of my domain of knowledge.

[cHao]

@TrevorBoydSmith: It's the "how to do" part, though, that kills the whole idea. There's simply no way to execute encrypted code directly; at some point, the decrypted code has to be available. Which means (1) there must be a key (that i, as root, probably have access to), and (2) I might even be able to find the clear copy in RAM and just not worry about encryption anyway.

[sachin003]

@Bhavesh yes your correct, I was looking for shared libaries, I'm still working on it, anyways thanks for reply.

[sachin003]

@Sarel Botha yes for IMP screens I already used webview & yes this is also one way to maintain security, I'm accepting your answer.

[Tauri]

C++ can never be reversed? it's difficult but possible. and there are tools to help you with that like hex-rays.com/products/decompiler/index.shtml (yes, they have ARM version. not it's not THAT easy to get).

[Sahil Mahajan Mj]

yes, @VikartiAnatra: I also mentioned Somehow, you could make it difficult

[Trevor Boyd Smith]

@cHao I think you are misunderstanding my idea a little. ¶ Everything in security is balanced against cost. The purpose of adding a new security feature to the APK system, just like the purpose of physical security, passwords, CAPTCHA, encryption, and the purpose of virtually every other security measure is to increase the cost of circumvention, not to make circumvention impossible. Also see here or here.

[cHao]

@TrevorBoydSmith: Problem is, in this case you simply can't raise the cost enough to make it not worthwhile. We're not talking about brute-forcing keys here; we're talking about already having them -- the OS has to have keys, and we have the OS. The only way to fix that would be to make the OS unrootable. Good luck with that; even Apple can't manage it. :)

[Trevor Boyd Smith]

@cHao The way you said "you simply can't raise the cost enough" seems to imply you think raising the cost is impossible. I admit raising the cost is more difficult but definitely not impossible ever.

[cHao]

@TrevorBoydSmith: I don't think raising the cost in general is impossible. I think (and say), in particular, that your suggestion is impossible -- because it is. MATLAB is not Android, and has certain freedoms that Android doesn't. In particular, it has obfuscation on its side; it's a lot harder to hide an encryption key. Android can't do that. Anyone who has the source code would know where the keys are hiding, and would have a tool to retrieve them within 10 minutes of the feature being announced. It's not just possible to do that; it's downright trivial.

[Trevor Boyd Smith]

@cHao you keep insisting on some form of encryption involving a static key that never changes and is in the same place. That sounds like a terrible idea and I am not sure why you keep on insisting on it. ¶ This entire conversation is not constructive so I am not going to respond anymore.

[cHao]

@TrevorBoydSmith: I've insisted nothing of the sort. What i'm insisting is that static, changing, moving, etc do not matter. In an open source OS, encryption alone can not protect the code from anyone who could reverse engineer it. Because i can read the code that would do the decryption, regardless of how the key is acquired, used, and/or stored, i can see how you did it and replicate it -- even more easily than i could reverse some super-secret app code.

[Raghav Sood]

They will be visible, just under a different package.

[stuckedoverflow]

Strangely, not in my case. I have 4 libs. Google Licensing + Pretty Time + android.support.v4.ViewPagerIndicator + My Internal Lib comes from Android Project set as Library. This Android Project as Lib is not visible. While the other 3 are visible.

[Raghav Sood]

it will be visible if you decompile the classes.dex file and open it up

[stuckedoverflow]

@Raghav, yup I used dex2jar and jd to simulate it. But I cannot find it. Have you tried?

[David Given]

This is true; but it's trivial to resign the APK (with a different certificate) and everything will work again. It's possible to check which signature has been used to sign the APK from within the application itself, and error out if the certificate changes, but it's only slightly less trivial to edit this code out of the application.

[Bogdan Alexandru]

If you try things like replacing numbers with predefined words or saving values after passing them through functions, then you are on the wrong path already. These are the most basic cryptographic techniques that have been used and broken long time ago through the simplest cryptanalitic attacks and they won't last long in your system.

[dharmendra]

perfect answer !! i just loved your way to get data from server with some encrypted token , i think this is next to impossible to decode after that .

[Matti Virkkunen]

I don't get why this answer has such a high score. 3. and 4. for one are just plain silly and will amount to no security at all.

[Admin]

He's asking if it's possible. You're saying yes, it's easy. You're wrong. It's impossible.

[Sarel Botha]

This may prevent the android device from running modified code, but you can still easily extract the relevant code and write new code on a PC which does what you want.

[Admin]

@RaghavSood :Need your help .Take a look please stackoverflow.com/questions/22602559/…

[totten]

Third one is really easing the attackers' work. Sniffing network communication is easier than reverse engineering.

[user3453281]

number 3, 4 and 5 just seem like such a pain. what if I work in a team? I'd be purposely making the code unreadable and unmaintainable for my present (and future) colleagues. what if I leave the team at any point in time after adding a bunch of cryptic stuff to the code?

[edwinj]

I know this is a bit late but what about accessing the accessing the server part. Services like Microsoft azure provides you something like this to access their server: MobileServiceClient mClient = new MobileServiceClient( "MobileServiceUrl", // Replace with the above Site URL "AppKey", // replace with the Application Key this) and pretty much anyone who has access to that can access their server end edit it

[Admin]

To solve the problem of the third one, one could encrypt the downloaded content and/or use an encrypted connection (e.g. SSL/TLS)

[Kevin Lee]

Encrypting the connection protects against people who sniff or modify traffic. In the case where the user himself is malicious (i.e. he has your apk and he has trying to hack it), he will still get the content by using your app, extracting resources as a root user; but yes it does help against simple sniffing attacks.

[Seng Cheong]

@TrevorBoydSmith Since you clearly aren't getting this, let's make it simple: The CPU is in my complete control. The CPU must be able to see decrypted code to run it. Therefore, I can see decrypted code. Q.E.D.

[Bora M. Alper]

So let's say that Charlie corresponds to $47, and John to $3. It's a joke, right?

[Bhavin Patel]

how to hide string inside " " i use proguard but it's not hide or convert value inside " " is there anyway to hide that?

[Dreaded semicolon]

this is old. but for someone looking for extra information. you don't have to use one unique key. see this: androidauthority.com/how-to-hide-your-api-key-in-android-600‌​583

[Louis CAD]

Apk signature v2 only prevents resources from being tampered with, but doesn't make reverse engineering any harder…

[Hi-Angel]

FTR, a decompiler for .so files does exist, it's HexRays of IdaPro. It's far from perfect obviously, but still makes stuff easier to reverse-engineer, because 3-4 lines of assembly may equal to one of C.

[Jocky Doe]

Unfortunately if one hack the client(the app) they would be able to see communication format and create their own server :(

[KeithS]

@edwinj - No problem in computer science that cannot be solved with another layer of indirection. Your snippet gives the basic idea for accessing an Azure mobile client service; it provides a basic level of security against "drive-bys" of Microsoft's front door. You can in turn add additional layers, such as requiring a session key (basically what the encrypted token is) on any service call, and to get that key, they must first authenticate with a combination of knowledge of the credentials and the encryption scheme.

[Robert]

Furthermore you can just remove the signature and re-sign it. The v2 signature is just a block of data in the APK file.

[Ben]

Changing extension to be able to unzip file... really? I guess renaming files magically alter the file's structure or something

[debo.stackoverflow]

One of the best answers.

[Ashok Kumar]

Adding to that : 4)use dexguard for higher obfuscation but it's paid 5) use OBB file for assets download at time of downloading app ,it will help for reducing app size aswell

[Sebi]

"In other words, instead of asking "how to avoid reverse engineering" try asking "how to engineer a bullet proof payment processing app"." - I don't think that's good advice, especially if you are suggesting to ask on StackOverflow.

[cregox]

@Sebi perhaps "system" there would fit better than "app". but, yeah, i can see now how confusing that sentence can sound in any case. what i still can't see is why people downvoted this answer so much, without any comment.

[Sebi]

Just for the record, I didn't downvote this answer. I think people may have downvoted because the answer advises to spend money to get the answers - in my opinion it may be good complementary help if you are willing to invest. I definitely agree with your last paragraph, and I think security.stackexchange.com may be a good place to ask about overall setup.

[cregox]

ah, ok... now i get it, lol. yeah, i wasn't even considering that interpretation! i'll try and edit it out to see what happens... thanks man. :D

[cregox]

it's now -3, I think it was -5 before. don't remember or really care... my attention was drawn here, this time, due to some approved editing into common case rather than my current favourite lower case style #locaws (more about it at cregox.net), which I just rejected to keep my identity on the post (and led me to an annoying spin off quest chat.stackoverflow.com/transcript/message/48255477#48255477)‌​. like in that case, i'm commenting here for no good reason other than reporting. cheers! 🥴😘

[Hannes Hertach]

This is a terrible answer and I have no idea why it is so upvoted. Please do not follow this advice, except for number 1, and the web service part of number 2 (but not the .so part - they can be decompiled too!)

[Example person]

I just thought of WebView LMAO.

[user]

Most of given items are silly and shows while author knows programming from a developper point of view, he hasn't got the reverse engineering point of view. For 3 I'd just say most people edit value at run time anyway. Nothing you can do about it. If you hide real value behind display value they'll still get it through debugging. For coins and such datas your one and only solution is to store it server side. Period.

[Subham Naik]

i always use Proguard and it is helpful to restrict reverse engineering.

[Peter Mortensen]

Re "write your critical logic in any native language": Wouldn't it be easier to obfuscate the code prior to compilation?

[Peter Mortensen]

Where did you plagiarise this from? From blog post Increase Code Complexity and Use Obfuscation?

[Peter Mortensen]

The second link is half broken.

[cregox]

lol @peter for "active reading". i'm out.

[Abdul]

If you you want to check the apk code is visible or not please try this online apk decompiler tool unboxapk.com