We have a challenge that reverse engineer modding our App and change some behavior of it and repack it.
We added a App signature checking to code but the reverse engineer can found that part and disabled it.
the another challenge is the third-party API we use must done on client and we can't perform it on server.
Anyone have idea to increase security of App ?
I have 3 things in mind for security.
use proguard for code deobfuscation
write native code for your secured part. It can't be reverse engineered
or process your secured part in server side & use the result.
Related
I know this question is very similar to this one: Using Charles proxy to decrypt googleapis.com,
but it is very old and I think google changed some stuff about their APIs.
I'm using Charles to inspect HTTP requests from an android app (which is not mine).
This app uses SSL pinning, so I bypassed it with this tutorial:
https://lucy-janewalsh.com/blog/2019/10/29/unpinning-an-app
This works perfectly for every domain, except firestore.googleapis.com.
Charles gives me this error:
No request was made. Possibly the SSL certificate was rejected.
Do you know if this is possible to inspect requests made to this address?
Thanks
That tutorial only disables SSLPinning by the conscrypt library and only if the app that uses this library has not been obfuscated. If the app is obfuscated the class can not be found and the pinning will remain active. Also keep in mind that conscrypt is based on my experience not very often used by Android apps. Other libraries that provide SSLPinning like OKHttp are way more often used (e.g. covered by this Frida snippet.
In your case everything depends on the app you try to intercept the traffic of. Decompile it e.g. using Jadx or your favorite app decompiler and try to identify the used library/method for SSL pinning. If the app is obfuscated (class names changed) then most likly you have to write your own frida code to disable pinning (or at least adapt the class names form an existing frida code snippet that performs unpinning for the SSL-library used in your app).
I am looking for a way to encrypt the data sent with the crash from the app to the Fabric servers.
Checking the official documentation I didn't find a method or a property to enable a sort of encryption.
What are you worried about?
A hacker hijacking your network data? Well - all Crashlytics communication is done via SSL. If hackers perform a MITM attak on your app, then crash reports are the least of your problems.
Someone reverse-engineering your app? Well - they won't do it through your crash reports - that's for sure. Not when "decompiling" the Java bitcode straight from the APK is so much easier.
Your best approach here would be to obfuscate your code using Proguard.
Someone identifying a key component of your app through the crash log? Again - easier via the APK itself.
Someone you don't trust, from your organization, learning stuff about your app from the crash results? You shouldn't give untrusted people access to your Crashlytics data. And if you do - obfuscatre first.
So, IMHO, this is a non-issue.
You are asking "from the app to the fabric servers".
If you mean exactly that then you are already covered, already encrypted and safe over the networks:
From their docs and probably easy to verify:
"All server communication is completed over SSL using packed-binary file format"
I'm assuming they actually mean TSL.
If you however mean that the Fabric servers shouldn't be able to understand the data sent (sounds strange), I don't know.
If it shouldn't understand your proguard/dexguard obfuscation (stack traces etc) then don't allow it to get your obfuscation mapping files.
I'm writing a ringtone gallery app which ringtones reside on a server and they can be downloaded by user.
What I want is to check and verify if the connection is really from my app not other apps or a HTTP request generator. for example I don't like someone write an app that uses my back end and show his ads in the app. It's like image leaching in web site which is prevented by checking the referrer.
It's not possible to insert a key in the app as android apps can be decompiled so easily. I thought of gaining the app signature and send it's hash as a key, but it's like any app can access other apps signature hash.
what about writing part of app which do the communication in native code? is it decompilable as easy as java code?
I really can't think of any other way and I don't like others use my resources for their benefit.
There are a couple of things you can do.
Create your own Certificate Authority, ship a certificate with your app and use two-way TLS authentication. This does not protect against decompilation and reverse-engineering but protects traffic en route.
Use the advice in this slide deck to detect modifications and debuggers.
Use Jelly Bean's hardware-backed secure storage.
At the end of the day, though, DRM is a lost battle. If the user has root access, all bets are off, with or without obfuscation (which native libraries are). The only question is how important is your data. For 90% of applications, running it through ProGuard makes it nearly impossible to untangle (especially if you use data flow obfuscation). Along with the certificate approach, that should suffice for most things.
Alternatively, try to change your model, so that you're authenticating the user and not the app - that's far simpler!
We have an android and ios app which sends data and commands to a server with http webservice. How can i prevent the possibility, that fake-clients also can send something to the server? How can I determine serversidely if the data/command really comes from our apps.
You cant really prevent it. There are several techniques to make it harder for people abusing your services.
A simple check can be to check the user agent calling your webservice. Another pretty common one is to use a simple authentication via user/password authentication on your webserver. The username and password will be embedded into your app.
If you have enough time you should think about using a combination of this two methods plus authentication with a embedded ssl certificate. You simply could add this to your project and if someone really want to abuse your service, he have to extract this certificate atleast form your application.
There are some other useful techniques but you cant prevent reverse engineering or network sniffing.
Sincerely,
fuxx
The most robust solution is not to try. Techniques like DasFuxx's answer suggests can make it faintly harder, but someone can always decompile your application and get whatever secrets you have embedded in it.
Instead, follow the rule of multiplayer game development:
Don't trust the client.
Don't think about your application as the user interface. Think about your network protocol/API as being the user interface; then design that interface so that it cannot be abused.
It may not be possible to do so completely, but insofar as you succeed, you have true security (rather than fighting the same losing battle as DRM systems).
I would implement oAuth. See the following link for more information on how to implement such a solution.
You can't. It's that simple...
I want to develop an android app for my website. One way of doing it is to have an API for the site, and let the app use that API. However i want this API to be used ONLY by my android app, I don't want any other client to be using this API.
Is there a way to ensure this?
I can think of one way of doing it: put a secret in the app and let the app pass this secret always to the API. But i am not sure how secure this approach would be because any packet sniffer can easily sniff the parameters and hence the secret. Any other suggestions?
I think this is something similar to a question I answered a few days ago.
Securing a REST API from Android
Namely, find a way to authenticate all of your requests using a shared secret.
If you sign both the path and params with a secret, then there should be no way for someone to forge requests.
Finally got hold of the answer from the android developer's blog article.
The short answer is no, sorry. If someone really wants to exploit your site/api/device/program/insert anything here and they have the time and resources then they will.
To directly answer your question, putting a key in your app isn't secure as anyone can decompile the app and try to reconstruct the key from the source files, they don't need to sniff traffic.
Correct me if I'm wrong! Packet sniffers can only be used with unencrypted WiFi and in (now) rare network configurations (a router or a switch prevent them).
For serious matters, you should consider secured connections (https).
That said, for standard content, I feel that a passphrase is secure enough. Many popular web apps don't use more than a cookie over http to let you log in, which is exactly what you're proposing.
I struggled with this issue and I actually ended up implementing a version of OAuth for securing my API. It can be difficult if you don't to launch a browser to do the "login" part of OAuth. I baked the login right into my my app and actually implemented the token exchanges under the covers. Too much involved to post the code here, but it works great. Obviously HTTPS is desired for an additional level of security.
If you could get some kind of signature back from package manager of your own app, you could use obfuscation to hopefully make it much more difficult, and have the signature/hash of signature from package manager be the key for your HMAC-SHA1.
Might have to try this ( How to get APK signing signature? )
If you did that, it would make it more difficult to use. Obviously, it could still be decompiled, but if they re-compiled it w/ debugging etc, it would have the wrong key. They would then have to actually make their own package manager on a rooted device to get the signature.