Some bad guys may try to reverse engineer your app, change the package name and publish the app with their own package name so I wrote this function which may help to stop that … your feedback is very welcomed.
I see zero value here. Anybody motivated to do what you are suggesting would certainly be capable of NOPing out this function and any calls to it.
we are trying to make his job harder AFAIK no perfect solution to prevent Reverse Engineering but with my technique and some uglifying methods so he can’t remove it from code easily … will that do the trick?
I still think this is a fool’s errand. If somebody infringes on your copyright, there are legal remedies. Attempts at technical methods are pointless.
1 Like
Apart from being rather easy to circumvent, this looks like a solution to a problem that doesn’t exist. I’ve never heard about this being a serious real-world problem.
It reminds me of those startups that go all apeshit about secrecy and patents and non-disclosure agreements and whatnot, because they’re afraid that “somebody’s going to steal my idea”. It’s a theoretical problem, it doesn’t happen.
And if it does it is a legal problem, not a technological one as @rapropos already mentioned.
I support this topic. I work inside the Finance world and in order to comply in terms of PCI DSS and lot of other certifications we need to make this kind of strategies
This is considered over engineering. chances someone will steal your app are very slim, no one will want to go through the headache of reverse engineering an app.
Popularity doesn’t change the laws of information theory. When you release a computer program for other people to run on devices outside your control, anything that is included in that release bundle must be considered public.
If your on-device app needs secrets to function, they must be generated and distributed out-of-band. That means something like a KDF to turn a user-generated passphrase into an encryption key, or storing all sensitive data on network servers that are under your control. Never burn secrets into your app binary. If the app can get at it to function properly, somebody with an emulator or a rooted phone can get at it similarly.
People can try to argue that hybrid apps like Ionic are inherently less secure than something that compiles down to bytecode, but having spent a good deal of my teenage years busting copy protection on 6502 machine language, I don’t think it’s a very compelling argument.
Store stuff that needs to be stored securely on servers that you don’t allow arbitrary physical access to.
Sorry @rapropos thanks for your comments. Do you understand that in order to be compliant with different regulations, like PCI DSS V1.3, Banks and Fintechs need to prevent apps to be reverse engineered? I just got a rejection from our security department because an ionic hybrid app was able to be reverse-engineered. I know is very difficult nowadays to grab an apk from the market and perform this activity, but there are some regulations that make the developers look for some security techniques. I’m also worried that the Ionic team hasn’t implemented this as default. Please see: https://owasp.org/www-project-mobile-top-10/2016-risks/m9-reverse-engineering
Then I think those regulations are misguided. Reverse engineering should be considered a given. I always assume that any hypothetical blackhat I am dealing with has the complete source code to any app I write, and I design so that that is not a problem.
If there are no secrets within the app binary, there is nothing to steal.
I see three hypothetical attack scenarios that are not the fault of reverse engineering, they’re the fault of lazy design that embeds secrets in app binaries:
As a result of the string table analysis, the attacker discovers a hardcoded connectivity string that contains authentication credentials to a backend database
Madness. Authentication credentials to a backend database have no business being included in distributed apps. They belong in middleware that is hosted on servers under your control.
the attacker discovers Jailbreak detection code
The attacker can discover jailbreak detection code by stepping through the app with a debugger, and there is absolutely nothing any obfuscator can do to obfuscate that. If the computer can run it, I can read it. The best you can do is to try to collude with OS and hardware makers to disable running of modified and unsigned apps, but you can’t stop me with hardware and an OS that I control.
I’m not sure what to do with scenario #3, because it just seems like a tautological boogeyman of “ZOMG they’re in ur base killin ur doodz”. Again, if you design your systems so that they’re secure even if all the source code is publicly available, you have nothing to fear from anybody decompiling your binaries.
1 Like
@rapropos
I agree with you in every point! Also think about something in real life like lets say money:
Lets say you earned a 100k cash after a project you spend a of time and effort on it and finally gave returns. Let say the client gave you the money in their office in cash for some reason.
You want to store the money in a safe spot. You could take it home but wont put it in front door(ram memory). Someone my steal it. Of course you can store inside your home and storage it i.e. down your bed(local memory) but someone with some dedication or someone who has been watching you can and probably will try to break in your home to steal your money. So where can we take it now? You could hide it somewhere but many things could go wrong.(usb,dongles…). So probably you will end up storing it in a bank so it can be safe in there and you can use it later( your servers, your control).
So in resume:
1- app non-sensitive logic can go public ( how buttons are displayed, page styles, local cookies for user current preferences…)
2- app sensitive data go in servers ALWAYS (secret keys, user profiles, credit cards, bank accounts…)
3-Connect your app with your server through an api or similar. This way you can ensure a good user experience and at the same time a safe and trusted service.
PS: it is your backend responsibility to validate every data that come into it just like the bank. Fake money can arrive so they gotta check it before it entering the system
1 Like
i just want to protect my code because the code contains the decrytion keys and salt and encryption code. there is no server used in application
tl;dr: don’t do that.
Regardless of what code “protection” you attempt to employ here, in order for the program to function properly,
- there must be some code that is valid JavaScript that unravels every single last layer of “protection” eventually and gets to the point where the decryption key is readable in plain text, and
- every single piece of information required to get there has to be included in the app binary
Perhaps it’s a good idea to note at this point that this isn’t a limitation of Ionic, or Angular, or hybrid web apps, or web apps in general, or JavaScript, or interpreted languages. It’s true of any program that runs on hardware you don’t control, and why I reserve such vitriol for the snake-oil salesmen that peddle “protection” schemes. It’s not just that they don’t work. They can’t work.
Part of the contract that allows your app to run on my phone is that you have to write it in a way my phone can decode, completely. If my phone can decode it, so can I.
Apologies if you’ve explained this already, but I don’t believe I know what kind of information your app is attempting to encrypt or decrypt, or where it’s intended to be distributed, so I can’t speak to whether adding a server would make sense. One option that might would be to rely on the user to generate secrets.
Example workflow:
- prompt user to enter passphrase
- use KDF like scrypt, PBKDF2, bcrypt, or Argon (all have JavaScript implementations freely available) to mogrify the passphrase into something suitable for use as an AES key
- use that to encrypt and decrypt
Or, if you don’t need broad web browser support, and are therefore OK with this part of the app only working on-device, you could use Ionic Native NativeStorage. The underlying cordova plugin relies on OS-specific ways to store data protected by the phone’s lockscreen.
If you are distributing data, the conversation changes a bit, but I would think that unlikely, considering the fact that you’ve said there is no server involved at all.
how to use this app-scripts in latest ionic framework or any alternative. because it have code mangle, minifying config.