@@avonzo that's news to me, I been working on a project which is specific to vehicles and not a public access application from past 5 years and never had a chance to work on this kind of implementations after 2018. Thanks for letting us know.
Its not possible to stop reverse engineer of java, kotlin or web (html, css, javascript) code because they are jit compiled from source code to virtual machine code on the users hardware at app launch. Only server side rpc code is 100% safe from reverse engineer. C and c++ is also hard to reverse engineer because its compiled ahead of time so the source code doesn't need to be on the users device, but its not impossible.
That's not right, you can do reverse engineering in a server side application, it's called indirect reverse engineering, spacebar (formely fosscord) did that
C and c++ its easy reverse, more easy C#, Java, etc... it becomes more difficult to reverse custom cryptographic algorithms or advanced mathematical algorithms, but reverse engineering is easy if you like it, it's patience.
Because you don't want to obfuscate column's names (which are defined as properties in your data class) So either use the ColumnInfo annotation or completely prevent obfuscation of those data classes (I prefer doing it with the Keep annotation)
There is a method that works and you don't have to obfuscate the code, I saw it in an application, you modify any piece of code, you compile and when you install the application you open it you get a sign that says, application modified and it closes 😂😂, it is great but I don't know what the method is called
but a disassembler can read your opcode. It is impossible to deny reverse engineering, obfuscated coding only works in static analysis. You can apply a package, it would be a program that reassembles your code in memory at runtime, but finding the entry point, applying dynamic analyses, destroys your package.
what's funny is that if you obfuscate your app too hard and all classes names obfuscated, google wont allow it to be published 😂 if anyone wondering why, it is because the google play need to review the app and if it's too hard for them to see your source code, they will reject your app 😅
Best solution - If a lot of people are trying to implement or use your apps api maybe you should just make a public api that requires payment over a certain amount of requests per day. That way you can take advantage of it.
like enviromentes variables for For Api Rest in Web? in devloper mode and also put in in server like heroku idk if exists for mobile.. or es complete different stuff
Good effort to advertise on shorts platform which is quite popular among youths. Not only it gives good information but also directs youth towards utilizing their crucial time in right direction.thanks Thanks
Oh, hello Amrchair expert! Yes, you are totally correct. You can encrypt the binary such that no person can derive anything from it, not the source code, not even the functionality. But tell me one thing, whats the point of encrypting your app if you cannot use it? You need to decrypt it so it can...actually be executed
@@ggsap Yes, but you need to decrypt it. I mean, you can store encrypted base on your phone, and when you want to decrypt it, you can call server, and to be sure it's not a bot, you have some authorization (not by entering the password). And you can protect blocks of ram to not access it fully, but that requires sudo (rooting), so that is not an option. I hope it will become function in Android.
@@Willie-vr6gk So you are saying the entire unencrypted application would be stored in RAM? That is unfeasible for big applications, and not sure what you mean by "protecting blocks of ram". Also, you do know the user would need two applications, one that contacts the server & decrypts the app, and the app itself. By observing the network traffic you could easily just replicate the traffic to the server with another app, since the traffic will always be the same. Plus if it does use some obscure tactics to "prove" itself to the authorization, you could just reverse engineer the app itself to imitate it. Sorry, but this wild goose chase is not possible.
Dinamic Analysis. When the cpu needs to execute instructions, it needs the data, registers, ect.... not encrypted, so with dynamic analysis you can see all the data even if you encrypt it, obfuscate it. You can't stop reverse engineering.
@@Willie-vr6gk You can use anti-debug techniques so that they cannot debug your binary or attach it, but with PE backdooring, code cave, you can bypass it with simplicity. The operating system uses RAM virtualization to protect programs, but the same operating system APIs let you inject code into another process, or make a page of memory executable, etc. Once your binary is in other hands, they can reverse it.
when doing obfuscation, all of your variables change name, as a result, if you have a data class that is being mapped from an API, it won't know how to map if you're relying on the variable name. always add your annotation with the desired name.
Fun fact: If you obfuscate the code, It'll be hard for you to read the crash logs unless you have a mapping file to deobfuscate and adb GUI to see so.
i definitely need a video detailing this!
Didn't know this. Thanks 👍
is only hard to read thats good
what about key like maps and others
Not if you had a unique ID for each exception. That used to be a thing in the past, the error code, error message and the stack trace.
@@avonzo that's news to me, I been working on a project which is specific to vehicles and not a public access application from past 5 years and never had a chance to work on this kind of implementations after 2018. Thanks for letting us know.
reverse engineering = good.
good tip; would also add overlapping integrity checking code, and finite state cryptography to encrypt the code at rest and decrypt at runtime
I always wondered this question. Thanks for this short
Its not possible to stop reverse engineer of java, kotlin or web (html, css, javascript) code because they are jit compiled from source code to virtual machine code on the users hardware at app launch.
Only server side rpc code is 100% safe from reverse engineer.
C and c++ is also hard to reverse engineer because its compiled ahead of time so the source code doesn't need to be on the users device, but its not impossible.
That's not right, you can do reverse engineering in a server side application, it's called indirect reverse engineering, spacebar (formely fosscord) did that
C and c++ its easy reverse, more easy C#, Java, etc... it becomes more difficult to reverse custom cryptographic algorithms or advanced mathematical algorithms, but reverse engineering is easy if you like it, it's patience.
Fun fact there are apps which can unobsufcate the app and make it easier to understand.
hahahahah
Can you please specify why not to obfuscate database entities? Does this apply to ROOM dataclass entities?
Because you don't want to obfuscate column's names (which are defined as properties in your data class) So either use the ColumnInfo annotation or completely prevent obfuscation of those data classes (I prefer doing it with the Keep annotation)
There is a method that works and you don't have to obfuscate the code, I saw it in an application, you modify any piece of code, you compile and when you install the application you open it you get a sign that says, application modified and it closes 😂😂, it is great but I don't know what the method is called
Everything is open source if you can read assembly and binary
Thankyou so much interesting information.
I only want it because my code is so badly written. hahaha
Better: just program in assembly or write directly the opcode in a bin file
but a disassembler can read your opcode. It is impossible to deny reverse engineering, obfuscated coding only works in static analysis. You can apply a package, it would be a program that reassembles your code in memory at runtime, but finding the entry point, applying dynamic analyses, destroys your package.
@@cristiannunez372 i was kiding, poiting out to the most hard option. Because i think trying to prevent people from reverse engeneereing is bullshit.
@@mynameusedtobelong sorry
@@cristiannunez372 nah, sorry for to being clear
Obfuscation is not the issue
Storing keys in the APK is the issue
Anything critical must be stored on a server and use authentication to gain access
AI tools will make all your hard work useless
@@tily5939 what?
what's funny is that if you obfuscate your app too hard and all classes names obfuscated, google wont allow it to be published 😂 if anyone wondering why, it is because the google play need to review the app and if it's too hard for them to see your source code, they will reject your app 😅
They surely run some tools on it to check its behavior, but I'm pretty sure they don't have employees reading your code 😂
this would be recent
Can you put more lights on how to decide which classes/code to put in exceptions from obfuscating?
Best solution - If a lot of people are trying to implement or use your apps api maybe you should just make a public api that requires payment over a certain amount of requests per day. That way you can take advantage of it.
Obfuscation is not the issue
Storing keys in the APK is the issue
Anything critical must be stored on a server and use authentication to gain access
What about android's keystore?
@@AlexGreece45 that only after the credentials have been gathered from elsewhere
You cannot store that data in the apk securely
@@ChrisAthanas whitebox crypto solves this problem
like enviromentes variables for For Api Rest in Web? in devloper mode and also put in in server like heroku
idk if exists for mobile..
or es complete different stuff
@@waynepambrun9871 can you recommend a library for Android?
100% guranteed this does not stop me :-)
It would stop you, don’t hype your self
You can simply write all your app code in one Activity class, and say good luck to reverse engineers)
Good idea 😂, but the next developer needed a lot of luck for sure.
Good luck to anyone trying to read and interpret my code
Good effort to advertise on shorts platform which is quite popular among youths. Not only it gives good information but also directs youth towards utilizing their crucial time in right direction.thanks Thanks
Now we want the practical use and how to publish it
we are gonna do it anyway
Haha love me some trapdoor functions 🌚 obfuscating is win
Huge thanks to you for using this type of content for tips such this one
You're wrong. You can totaly secure it with encryption.
Oh, hello Amrchair expert! Yes, you are totally correct. You can encrypt the binary such that no person can derive anything from it, not the source code, not even the functionality. But tell me one thing, whats the point of encrypting your app if you cannot use it? You need to decrypt it so it can...actually be executed
@@ggsap Yes, but you need to decrypt it. I mean, you can store encrypted base on your phone, and when you want to decrypt it, you can call server, and to be sure it's not a bot, you have some authorization (not by entering the password). And you can protect blocks of ram to not access it fully, but that requires sudo (rooting), so that is not an option. I hope it will become function in Android.
@@Willie-vr6gk So you are saying the entire unencrypted application would be stored in RAM? That is unfeasible for big applications, and not sure what you mean by "protecting blocks of ram". Also, you do know the user would need two applications, one that contacts the server & decrypts the app, and the app itself. By observing the network traffic you could easily just replicate the traffic to the server with another app, since the traffic will always be the same. Plus if it does use some obscure tactics to "prove" itself to the authorization, you could just reverse engineer the app itself to imitate it. Sorry, but this wild goose chase is not possible.
Dinamic Analysis. When the cpu needs to execute instructions, it needs the data, registers, ect.... not encrypted, so with dynamic analysis you can see all the data even if you encrypt it, obfuscate it. You can't stop reverse engineering.
@@Willie-vr6gk You can use anti-debug techniques so that they cannot debug your binary or attach it, but with PE backdooring, code cave, you can bypass it with simplicity. The operating system uses RAM virtualization to protect programs, but the same operating system APIs let you inject code into another process, or make a page of memory executable, etc. Once your binary is in other hands, they can reverse it.
when doing obfuscation, all of your variables change name, as a result, if you have a data class that is being mapped from an API, it won't know how to map if you're relying on the variable name.
always add your annotation with the desired name.