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    How can I completely prevent reverse engineering of an Android APK  Is this possible  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  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

User · Answer

Tool  Using Proguard in your application it can be restricted to reverse engineering your application

User · Answer

The other upvoted answers here are correct  I just want to provide another option   For certain functionality that you deem important you can host the WebView control in your app  The functionality would then be implemented on your web server  It will look like it s running in your application

User · Answer

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

User · Answer

The main question here is that can the dex files be decompiled and the answer is they can be  sort of   There are disassemblers like dedexer and smali   ProGuard  properly configured  will obfuscate your code  DexGuard which is a commercial extended version of ProGuard  may help a bit more  However  your code can still be converted into smali and developers with reverse-engineering experience will be able to figure out what you are doing from the smali   Maybe choose a good license and enforce it by the law in best possible way

User · Answer

If your app is this sensitive then you should consider the payment processing part at server side  Try to change your payment processing algorithms  Use android app only for collecting and displaying user information  i e account balance  and rather than processing payments within java codes  send this task to your server using a secure SSL protocol with encrypted parameters  Create fully encrypted and secure API to communicate with your server   Of course  It can also be hacked too and it has nothing to do with source codes protection but consider it another security layer to make it harder for hackers to trick your app

User · Answer

If we want to make reverse engineering  almost  impossible  we can put the application on a highly tamper-resistant chip  which executes all sensitive stuff internally  and communicates with some protocol to make controlling GUI possible on the host  Even tamper-resistant chips are not 100  crack proof  they just set the bar a lot higher than software methods  Of course  this is inconvenient  the application requires some little USB wart which holds the chip to be inserted into the device   The question doesn t reveal the motivation for wanting to protect this application so jealously    If the aim is to improve the security of the payment method by concealing whatever security flaws the application may have  known or otherwise   it is completely wrongheaded   The security-sensitive bits should in fact be open-sourced  if that is feasible  You should make it as easy as possible for any security researcher who reviews your application to find those bits and scrutinize their operation  and to contact you  Payment applications should not contain any embedded certificates  That is to say  there should be no server appliaction which trusts a device simply because it has a fixed certificate from the factory  A payment transaction should be made on the user s credentials alone  using a correctly designed end-to-end authentication protocol which precludes trusting the application  or the platform  or the network  etc   If the aim is to prevent cloning  short of that tamper-proof chip  there isn t anything you can do to protect the program from being reverse-engineered and copied  so that someone incorporates a compatible payment method into their own application  giving rise to  unauthorized clients   There are ways to make it difficult to develop unauthorized clients  One would be to create checksums based on snapshots of the program s complete state  all state variables  for everything  GUI  logic  whatever  A clone program will not have exactly the same internal state  Sure  it is a state machine which has similar externally visible state transitions  as can be observed by inputs and outputs   but hardly the same internal state  A server application can interrogate the program  what is your detailed state   i e  give me a checksum over all of your internal state variables    This can be compared against dummy client code which executes on the server in parallel  going through the genuine state transitions  A third party clone will have to replicate all of the relevant state changes of the genuine program in order to give the correct responses  which will hamper its development

User · Answer

Its not possible to completely avoid RE but By making them more complex internally  you put make it more difficult for attackers to see the clear operation of the app  which may reduce the number of attack vectors   If the application handles highly sensitive data  Various techniques exist which can increase the complexity of reverse engineering your code  One technique is to use C C   to limit easy runtime manipulation by the attacker  There are ample C and C   libraries that are very mature and easy to integrate with  Android offers JNI   An attacker must first circumvent the debugging restrictions in order to attack the application on a low level  This adds further complexity to an attack  Android applications should have android debuggable    false    set in the application manifest to prevent easy run time manipulation by an attacker or malware    Trace Checking     An application can determine whether or not it is currently being traced by a debugger or other debugging tool  If being traced  the application can perform any number of possible attack response actions  such as discarding encryption keys to protect user data  notifying a server administrator  or other such type responses in an attempt to defend itself  This can be determined by checking the process status flags or using other techniques like comparing the return value of ptrace attach  checking parent process  blacklist debuggers in the process list or comparing timestamps on different places of the program   Optimizations - To hide advanced mathematical computations and other types of complex logic  utilizing compiler optimizations can help obfuscate the object code so that it cannot easily be disassembled by an attacker  making it more difficult for an attacker to gain an understanding of the particular code  In Android this can more easily be achieved by utilizing natively compiled libraries with the NDK  In addition  using an LLVM Obfuscator or any protector SDK will provide better machine code obfuscation   Stripping binaries     Stripping native binaries is an effective way to increase the amount of time and skill level required of an attacker in order to view the makeup of your application   s low level functions  By stripping a binary  the symbol table of the binary is stripped  so that an attacker cannot easily debug or reverse engineer an application You can refer techniques used on GNU Linux systems like sstriping or using UPX   And at last you must be aware about  obfuscation and tools like ProGuard

User · Answer

Nothing is secure when you put it on end-users hand but some common practice may make this harder for attacker to steal data     Put your main logic  algorithms  into server side  Communicate with server and client  make sure communication b w server and client is secured via SSL or HTTPS  or use other techniques key-pair generation algorithms  ECC  RSA   Ensure that sensitive information is remain End-to-End encrypted  Use sessions and expire them after specific time interval  Encrypt resources and fetch them from server on demand  Or you can make Hybrid app which access system via webview protect resource   code on server   Multiple approaches  this is obvious you have to sacrifice among performance and security

User · Answer

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

User · Answer

when they have the app on their phone  they have full access to memory of it  so if u want to prevent it from being hacked  you could try to make it so that u cant just get the static memory address directly by using a debugger  they could do a stack buffer overflow if they have somewhere to write and they have a limit  so try to make it so when they write something  if u have to have a limit  if they send in more chars than limit  if  input   limit  then ignore  so they cant put assembly code there

User · Answer

Your client should hire someone that knows what they are doing  who can make the right decisions and can mentor you   Talk above about you having some ability to change the transaction processing system on the backend is absurd - you shouldn t be allowed to make such architectural changes  so don t expect to be able to   My rationale on this   Since your domain is payment processing  its safe to assume that PCI DSS and or PA DSS  and potential state federal law  will be significant to your business - to be compliant you must show you are secure  To be insecure then find out  via testing  that you aren t secure  then fixing  retesting  etcetera until security  can be verified at a suitable level   expensive  slow  high-risk way to success  To do the right thing  think hard up front  commit experienced talent to the job  develop in a secure manner  then test  fix  less   etcetera  less  until security can be verified at a suitable level   inexpensive  fast  low-risk way to success

User · Answer

nope  can t be done   your 3 questions circle around 100  protecting an app from being read  it just can t be done  by principle  and the more you invest in trying to do it  the worse experience it will be for you and  eventually  for whichever machine is trying to just read your app  think of how slower HTTPS intrinsically is from HTTP  because of the security layer and maths required to be processed  the more layers  the slower it ll be for someone to unpack it  but never impossible  given you actually want it to be read  thus why it s made into a package and delivered   a simple analogy is giving any given concealed object to someone  if that person can see what s inside  so can they take a picture and do something exactly like it  more so  in case of the code  someone dedicated enough can create an exact replica of that object  even if using a completely different process   fake security sense  as a processing app you shouldn t care for whatever security you think you can create in your binary code  for the integrity of the whole system  assume anything that comes from the client can quickly be unreliable  keep the app simple  smooth and fast  and  instead  worry about your server  make a strict communication protocol to easily monitor the server  for instance  that s the only thing we can rely on   now  stick with me with this other idea on how to improve the server-side     mouth on the money     I am developing a payment processing app   Google have been very successful in avoiding malicious hackers in general by using a simple financial method to  protect  Google Chrome  and i quote       We have a standing  50 000 reward for participants that can compromise a Chromebook or Chromebox with device persistence in guest mode   our best bet to actually get closer to 100   security  is picking the right fight for our money s worth  perhaps most people won t be able to offer a 50k reward  but even a 1k reward can go a long way  and it s also much cheaper than investing that money into engineering any kind of bug catcher   and investing in artificial intelligence to identify patterns in money flow to predict potential risks and find small leakages can also be much cheaper than trying to prevent both through whatever engineering   obvious exceptions  granted  that won t protect us from  lunatics  and  lucky pranksters     but nothing will  meanwhile  when properly set  the latter group will only enjoy little time inside  while the system readjusts  and a lunatic we d only need to worry in case it goes big enough to have a nemesis  and that would make a great story  anyway      too long  didn t read   in other words  perhaps a better question to ask to yourself  instead of  how to avoid reverse engineering in my app  could be  how to engineer a more secure payment processing system  and focus on what you re actually trying to achieve  a secure system   long ago  i ve tried writing more about all the above  to answer questions such as why i m putting  security  and  protect  in quotes  what do they even really mean

User · Answer

nbsp 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       nbsp 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       nbsp 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    lt project gt  libs armeabi libstuff so

User · Answer

I knew some banking apps are using DexGuard which provides obfuscation as well as encryption of classes  strings  assets  resource files and native libraries  https   www guardsquare com en products dexguard

User · Answer

There is no way to completely avoid reverse engineering of an APK  To protect application assets  resources  you can use encryption    Encryption will make harder to use it without decryption choosing some strong encryption algorithm will make cracking harder  Adding some spoof code into your main logic to make more harder for cracking  If you can write your critical logic in any native language and that surely make harder for decompile  Using any third party security frameworks like Quixxi

User · Answer

I can see that good answer in this thread   In addition to you can use facebook redex to optimize the code  Redex works on  dex level where proguard work as  class level

User · Answer

nbsp 1  How can I completely avoid reverse engineering of an Android APK  Is this possible    That is impossible      nbsp 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    Developers can take steps such as using tools like ProGuard to obfuscate their code  but up until now  it has been quite difficult to completely prevent someone from decompiling an app   It s a really great tool and can increase the difficulty of  reversing  your code whilst shrinking your code s footprint   Integrated ProGuard support  ProGuard is now packaged with the SDK Tools  Developers can now obfuscate their code as an integrated part of a release build       nbsp 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    While researching  I came to know about HoseDex2Jar  This tool will protect your code from decompiling  but it seems not to be possible to protect your code completely   Some of helpful links  you can refer to them     Proguard  Android  and the Licensing Server Securing Android LVL Applications Stack Overflow question Is it really impossible to protect Android apps from reverse engineering  Stack Overflow question How to prevent reverse engineering of an Android APK file to secure code

User · Answer

Basically  there are 5 methods to protect your APK  Isolate Java Program  Encrypt Class Files  Convert to Native Codes  Code Obfuscation and Online Encryption I suggest you use online encryption because it is safe and convenient  You needn t spend to much time to achieve this  Such as APK Protect  it is an online encryption website for APK  It provides Java codes and C   codes protection to achieve anti-debugging and decompile effects  The operation process is simple and easy

User · Answer

100  security of the source code and resources is not possible in Android  But  you can make little bit difficult for the reverse engineer  You can find more details on this in below links   Visit Saving constant values securely and https   www agicent com blog mobile-app-security-best-practices

User · Answer

nbsp 1  How can I completely avoid reverse engineering of an Android APK  Is this possible    This isn t possible      nbsp 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       nbsp 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

User · Answer

I suggest you to look at Protect Software Applications from Attacks  It s a commercial service  but my friend s company used this and they are glad to use it

User · Answer

100  avoidance of reverse engineering of the Android APK is not possible  but you can use these ways to avoid extracting more data  like source code  assets form your APK  and resources    Use ProGuard to obfuscate application code Use NDK using C and C   to put your application core and secure part of code in  so files To secure resources  don t include all important resources in the assets folder with APK  Download these resources at the time of application first start up

User · Answer

As someone who worked extensively on payment platforms  including one mobile payments application  MyCheck   I would say that you need to delegate this behaviour to the server  no user name or password for the payment processor  whichever it is  should be stored or hardcoded in the mobile application  that s the last thing you want  because the source can be understood even when if you obfuscate the code   Also  you shouldn t store credit cards or payment tokens on the application  everything should be  again  delegated to a service you built  it will also allow you later on  be PCI-compliant more easily  and the Credit Card companies won t breath down your neck  like they did for us

User · Answer

nbsp 1  How can I completely avoid reverse engineering of an Android APK  Is this possible    Impossible      nbsp 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    Impossible      nbsp 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    More tough - possible  but in fact it will be more tough mostly for the average user  who is just googling for hacking guides  If somebody really wants to hack your app - it will be hacked  sooner or later

User · Answer

APK signature scheme v2 in Android N  The PackageManager class now supports verifying apps using the APK signature scheme v2  The APK signature scheme v2 is a whole-file signature scheme that significantly improves verification speed and strengthens integrity guarantees by detecting any unauthorized changes to APK files   To maintain backward-compatibility  an APK must be signed with the v1 signature scheme  JAR signature scheme  before being signed with the v2 signature scheme  With the v2 signature scheme  verification fails if you sign the APK with an additional certificate after signing with the v2 scheme   APK signature scheme v2 support will be available later in the N Developer Preview   http   developer android com preview api-overview html apk signature v2

User · Answer

Just an addition to already good answers above   Another trick I know is to store valuable codes as Java Library  Then set that Library to be your Android Project  Would be good as C  so file but Android Lib would do   This way these valuable codes stored on Android Library won t be visible after decompiling

User · Answer

Aren t TPM chips  Trusted Platform Module  supposed to manage protected code for you   They are becoming common on PCs  especially Apple ones  and they may already exist in today s smartphone chips  Unfortunately there is no OS API to make use of it yet  Hopefully Android will add support for this one day  That s also the key to clean content DRM  which Google is working on for WebM

User · Answer

Basically it s not possible  It will never be possible  However  there is hope  You can use an obfuscator to make it so some common attacks are a lot harder to carry out including things like    Renaming methods classes  so in the decompiler you get types like a a  Obfuscating control flow  so in the decompiler the code is very hard to read  Encrypting strings and possibly resources   I m sure there are others  but that s the main ones  I work for a company called PreEmptive Solutions on a  NET obfuscator  They also have a Java obfuscator that works for Android as well one called DashO   Obfuscation always comes with a price  though  Notably  performance is usually worse  and it requires some extra time around releases usually  However  if your intellectual property is extremely important to you  then it s usually worth it   Otherwise  your only choice is to make it so that your Android application just passes through to a server that hosts all of the real logic of your application  This has its own share of problems  because it means users must be connected to the Internet to use your app   Also  it s not just Android that has this problem  It s a problem on every app store  It s just a matter of how difficult it is to get to the package file  for example  I don t believe it s very easy on iPhones  but it s still possible

User · Answer

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    An APK file is protected with the SHA-1 algorithm  You can see some files in the META-INF folder of APK  If you extract any APK file and change any of its content and zip it again and when you run that new APK file on an Android machine  it will not work  because the SHA-1 hashes will never match

User · Answer

Agreed with  Muhammad Saqib here  https   stackoverflow com a 46183706 2496464  And  Mumair give a good starting steps  https   stackoverflow com a 35411378 474330  It is always safe to assume that everything you distribute to your user s device  belong to the user  Plain and simple  You may be able to use the latest tools and procedure to encrypt your intellectual properties but there is no way to prevent a determined person from  studying  your system  And even if the current technology may make it difficult for them to gain unwanted access  there might be some easy way tomorrow  or even just the next hour   Thus  here comes the equation   When it comes to money  we always assume that client is untrusted    Even in as simple as an in-game economy   Especially in games  There are more  sophisticated  users there and loopholes spread in seconds    How do we stay safe   Most  if not all  of our key processing systems  and database of course  located on the server side  And between the client and server  lies encrypted communications  validations  etc  That is the idea of thin client

User · Answer

Here are few methods you can try    Use obfuscation and tools like ProGuard  Encrypt some part of source and data  Use a proprietary inbuilt checksum in the app to detect tampering  Introduce code to avoid loading in a debugger  that is  let the app have the ability to detect the debugger and exit   kill the debugger  Separate the authentication as an online service  Use application diversity  Use the finger printing technique for e g   hardware signatures of the devices from different subsystem before authenticating the device

User · Answer

Developers can take following steps to prevent an APK from theft somehow    the most basic way is to use tools like ProGuard to obfuscate their code  but up until now  it has been quite difficult to completely prevent someone from decompiling an app  Also I have heard about a tool HoseDex2Jar   It stops Dex2Jar by inserting harmless code in an Android APK that confuses and disables Dex2Jar and protects the code from decompilation  It could somehow prevent hackers from decompiling an APK into readable java code   Use some server side application to communicate with the application only when it is needed  It could help prevent the important data    At all  you can not completely protect your code from the potential hackers  Somehow  you could make it difficult and a bit frustrating task for them to decompile your code  One of the most efficient way is to write in native code C C    and store it as compiled libraries

User · Answer

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    Use tools like ProGuard  These will obfuscate your code  and make it harder to read when decompiled  if not impossible  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  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  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  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

[android] How to avoid reverse engineering of an APK file?

Examples related to android

Examples related to security

Examples related to proguard

Examples related to reverse-engineering