I am developing an android email client application and Calling webservices using ksoap2 library and also writing some encryption algorithm to encrypt data in my client.
In some websites I have read "It is possible to decompile the apk using some decompilers". (i.e.) get the source code from apk file.
But I want to secure my code. Don't show the encryption algorithm code after decompilation or don't want to decomplile my apk file. Is it possible to do that? please can you give some suggestions?
Edit the file (in the project root) project.propierties and add the line
proguard.config=proguard.cfg
And its done. When you try to generate the signed apk of your app it will take a little longer and it will be obfuscated.
If you receive the "Conversion to dalvik error" when generating the apk you need to update the proguard of your sdk. For doing it you need to go to the ProGuard page to the download section. Download the last stable version and put it content in
SDK_ROOT/tools/proguard
Deleting the existing content before of course.
You can check the Proguard manual at their page (link is above) and the Android's Proguard page for more info about ProGuard
This process is known as Obfuscating the code.
EDIT:
Steps to get obfusticated apk:
1) Download latest proguard from "http://sourceforge.net/projects/proguard/files/". Current latest version is proguard4.7
2) Replace "bin" and "lib" folder of "C:\Program Files (x86)\Android\android-sdk\tools\proguard" with latest downloaded proguard folders.
3) Check SDK location in eclipse for blank spaces in it and for that go to window > Preferences > Android. If there is blank space then replace it with:
c:\Progra~2\android\android-sdk (for windows 64-bit)
c:\Progra~1\android\android-sdk (for windows 32-bit)
4) Check that proguard.cfg file is in your project's root folder and add "proguard.config=proguard.cfg" in project.properties file of android project.
5) Now export your project to get obfusticated apk.
I hope that it will help.
You must not rely on security through obsurity.
If you feel that the encrypted data would be compromised by the knowledge of the encryption algorithm, then you're NOT doing security.
It will always be possible to decompile any file, if the "hacker" knows how to do so. That's why there are still cracks for paid applications, because people take their spare time to decompile/crack applications. All you can do is to make them have a hard time by using as many tools as you can. The first choice (and that comes disabled by default) is ProGuard
Related
as it is known, log4j vulnerability has emerged. How can we close this gap in our own projects? Do we have a chance to push a version on gradle?
My own solution to help
constraints{
implementation("org.apache.logging.log4j:log4j-core"){
version{
strictly("[2.15,3[")
prefer("2.15.0")
}
because("CVE-2021-44228 : Log4j is vulnerable to remote code execution")
}
}
This is the solution we used in our spring-boot project where we manage dependencies using the enforcedPlatform method:
dependencies {
api(enforcedPlatform("org.springframework.boot:spring-boot-dependencies:${springBootVersion}")) {
exclude(group: "org.apache.logging.log4j")
}
api(platform("org.apache.logging.log4j:log4j-bom:2.15.0")) {
because "https://nvd.nist.gov/vuln/detail/CVE-2021-44228"
}
}
This is designed to be in-place until such time as we're in a position to upgrade to a version of Spring Boot that pulls in the fixed version itself.
WARNING:
As of 2021-12-16 The other answers in this thread are out of date. DO NOT USE THE OTHER ANSWERS DIRECTLY.
log4j v2.15.0 is no longer considered a valid remediation for this vulnerability. See Apache's Log4J security bulletin for more information
cntl + f for 2.15
screen shot
UPDATE: 2021-12-18...
Remember to always check for the latest information from the resources listed below
CVE-2021-45105... 2.16.0 and 2.12.2 are no longer valid remediations! The current fixing versions are 2.17.0 (Java 8) and 2.12.3 (Java 7). All other Java versions have to take the stop gap approach (removing/deleting JndiLookup.class file from the log4j-core JAR.
I have updated my message below accordingly.
More resources
https://www.reddit.com/r/blueteamsec/comments/rd38z9/log4j_0day_being_exploited/
This one has TONS of useful info including detectors, even more resource links, very easy to understand remediation steps, and more
https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
https://github.com/cisagov/log4j-affected-db
https://logging.apache.org/log4j/2.x/security.html
Remediation:
CVE-2021-45046 ... CVE-2021-44228 ... CVE-2021-45105
While most people that need to know probably already know enough to do what they need to do, I thought I would still put this just in case...
Follow the guidance in those resources... it may change, but
As of 2021-12-18
It's basically
Remove log4j-core JAR files if possible
From both running machines for immediate fix AND
in your source code / source code management files to prevent future builds / releases / deployments from overwriting the change
If that is not possible (due to a dependency), upgrade them
If you are running Java8, then you can upgrade to log4j 2.17.0+
If you are running an earlier version of Java, then you can upgrade to log4j 2.12.3
If you are running an older version of Java, then you need to upgrade to the newest version of Java, and then use the newest version of Log4J
Again, these changes have to happen both on running machine and in code
If neither of those are possible for some reason... then there is the NON-remediation stop gap of removing the JndiLookup.class file from the log4j-core JARs.
There is a one-liner for the stop gap option on Linux using the zip command that comes packaged with most Linux distros by default.
zip -q -d "$LOG4J_JAR_PATH" org/apache/logging/log4j/core/lookup/JndiLookup.class
At time of writing, most of the guides online for the stop gap option on Windows say to do the following (again... assuming you can't do one of the remove JAR or upgrade options above):
Install something like 7-zip
Locate all of your log4j-core JAR files and for each one do the following...
Rename the JAR to change the extension to .zip
Use 7-zip to unzip the JAR (which now has a .zip extension)
Locate and remove the JndiLookup.class file from the unzipped folder
The path is \\path\\to\\unzippedFolder\\org\\apache\\logging\\log4j\\core\\lookup\\JndiLookup.class
Delete the old JAR file (which now has an extension of .zip)
Use 7-zip to RE-zip the folder
Rename the new .zip folder to change the extension to .jar
There are also some options to use Power Shell
Reddit thread: log4j_0day_being_exploited
ctrl+f for "PowerShell"
This is fine if you only have 1 or 2 JAR files to deal with and you don't mind installing 7-zip or you have PowerShell available to do it. However, if you have lots of JAR files, or if you don't want to install 7-zip and don't have access to Power Shell, I created an open-source VBS script that will do it for you without needing to install any additional software. https://github.com/CrazyKidJack/Windowslog4jClassRemover
Read the README and the Release Notes https://github.com/CrazyKidJack/Windowslog4jClassRemover/releases/latest
I just recently extracted source code of an apk from playstore. When I opened the source code all the function names, variable names were renamed with some random numbers and letters.
So does playstore does that automatically when we upload our apk?
If not then how can I do that in android studio?
thats Proguard feature, check this doc: Shrink, obfuscate, and optimize your app
when you use it then your code will be obfuscated for harder reverse engineering (besides some optimisation). you have to enable this feature in your gradle file (minifyEnabled), some same how to declare under link above
So does playstore does that automatically when we upload our apk?
-no it was done by some other application
the application you unpacked was previously obfuscated.
you can read more about this here:
https://en.wikipedia.org/wiki/Obfuscation_(software)
Java obfuscator
https://www.preemptive.com/products/jsdefender?gclid=EAIaIQobChMI4bXBqZn48AIVbxitBh1OyQnqEAAYASAAEgJ_XPD_BwE
Taking inspiration from The Twelve-Factor App: V. Build, release, run, I'm working on updating our CI/CD pipeline with these three distinct steps in mind for an app being built with react-native-web.
Specifically, I want to:
Build: generate an environment agnostic artifact of the code for each platform (web, android, ios)
Release: take an artifact and a config file (API URLs, API keys, debug settings, etc), and release to each platform
This is trivial for web, which is what The Twelve-Factor App had in mind. My question is how do I read a config file on mobile platforms and how can I incorporate this with react-native-web build artifacts? Does my artifact need to contain all of the source code and dependencies so I can pull in the config at release time and build then?
Ideally, each artifact would contain code compiled for each platform that somehow knows how to pull in a config file and do something with it. Next best would be to have the source code for each platform that I can compile with a config file at release time. Third best is have a way to give each distribution enough information at release time so it can request the config at runtime.
Full disclosure, I know nothing about building and deploying mobile apps so I apologize if there is an obvious solution for this!
It's similar for Android. Once the build binary is created it's immutable.
So unfortunately that negates option #1. We can't do anything else with the binary once we build it.
I think for react-native option two is the best approach.
Essentially you'll need to build the apps at release time once you have resolved what your configs need to be. That avoids any overhead of loading stuff at runtime in option #3 and still matches nicely to Twelve Factor. You'll still have a mobile binary that matches the same configuration as your release type.
For actually reading those values, you can just drop the config file into the project's root and we can help with the setup to pull them in.
I'll be glad to discuss those details if you'd like.
UPDATE:
Anything iOS does we can do (almost as well)
Current build tools compile all code into bytecode classes.dex and compress all resrouces into resrouces.arc but res/raw is left untouched.
This gives us a place to inject our files.
From there, the app will be able to read and parse at runtime.
For iOS, the build and (non-App Store) release process works like this at a high level:
Archive your project in Xcode, which results in an .xcarchive artifact.
Export your archive which signs and generates an .ipa file.
Either host this .ipa file yourself (with some additional metadata files) or upload it to a service like HockeyApp for distribution.
There are a few ways that you can manage config inside an Xcode project. One fairly common and straightforward way is to use the info.plist file to store custom keys and values. The app can then look up and use these values at runtime.
In the scenario you describe, it sounds like you want to be able to inject specific config values after step 2 but before step 3. Fortunately, the .ipa file generated during step 2 can be extracted, which will reveal a Payload folder containing an .app file. This file can be inspected, and inside you will see, amongst other things, the app's Info.plist. Modifying this file will allow for injection of whatever config values you want to set.
This will save needing to manage configs inside the Xcode project, and creating a separate archive for each configuration of the app. However what this doesn't solve is step 3. You are still going to need to distribute each configured .ipa file separately.
I searched around the net a simple example of how to use ProGuard to protect your Android app from "code thieves". And I ended doing like this and you tell me if this is all it takes:
I opened project.properties file of my project in Eclipse, and uncomment and left this line: proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt
Then I went to my project's Android Tools => Export Signed Application Package...
and export it with existing keystore which I made earlier when I was exporting app to test it in my phone.
In my project, above project.properties appeared to be created a new file proguard-project.txt, which I expected because the above line: ...proguard-android.txt:proguard-project.txt.
And that's it?
Or no? Do I have to add something else because I've seen that others are adding some classes to inculde in file, ... Is that not included?
Help me to learn how to protect my app. Thanks in advance!
Yeas, that's all if you want to protect your code only.
if you have resources that have copyrights, consider using the Android Copy protection.
When pubishing your app : go to section Publishing options subsection Copy Protection
Check Copy Protection : On
This prevent hackers to export the apk and by the way, prevent your resources from most of hackers.
For the most part, that is all you need to do. If you use any external libraries, you may have to modify your config file in order to export your app. You should test your protected app on your device to before publishing.
First of all, i'm new on ProGuard, but i read some tutorials and i know that the best way to use it on android is the one described on android.developer guide.
im trying to obfuscate the code of my new Android app with ProGuard. For that i enter this website: http://developer.android.com/tools/help/proguard.html#enabling
But it tells: "hen you create an Android project, a proguard.cfg file is automatically generated in the root directory of the project."
That file does not exist on my project root directory, so i dont know how to continue. My Android app is for api level 4, 1.6, so, is it possible that this is a problem for using ProGuard?
How can i use proguard with an app for api 4 (android 1.6)
Thanks a lot
You need a proguard.cfg File. You can either create it by hand or use the proguard-GUI (> java -jar proguardgui.jar). Using the GUI makes some things easier, but a basic understandig of proguard and obfuscating is still required. It isn't very comfortable to use the gui for obfuscating your release apk, so proviging the config-file and using the SDKs Build tools is still the best way to go.
The ACRA Documentation features an Example for a proguard.cfg http://code.google.com/p/acra/wiki/ACRAProGuardHowTo most of the stuff is ACRA related and can be ommited if you don't use ACRA in your project.
I Don't know if the SDK is supposed to create an proguard.cfg. If never seen one which was created automaticaly, so i suggest you go with the file as supplied by the acra-guys for a starting point.
Make sure that you are using the latest Android SDK. You can check this with the standard android application from the SDK.
Then make sure that your project directory is up-to-date too, by typing
adb update project -p MyProjectDirectory
(from the command-line, with the proper path to the directory of your project). This should create a ProGuard configuration file, which is called proguard-project.txt in recent releases of the SDK.
You can then enable ProGuard by uncommenting the proper line in project.properties.