At some point, it is stated that the expectedPackageName should be hardcoded. What happens if we are using the same codebase for multiple clients with different Package Names and hashes ?
Talsec has a premium SDK (RASP+) which is recommended solution for White Label apps vendors and for SDK vendors, where there could be many packages/hashes for the same codebase
As of freeRASP version 6.8.0 and earlier, watcher mail is *technically* required, but you can provide empty string. However, I do not recommend doing this, because you'll lost option to receive security reports which are vital part of freeRASP.
hi @Majid, if someone tempered or reverse engineer my flutter app, then how this free_rasp plugin will detect it? as attacker will pack a new apk using my same code and that will be a entire new apk. so how my actual apk detects like someone tempered or reverse-engineered my app?
Every APK is signed with a unique key that is known only to you (and Google, in case of apps distributed via the Play Store). If an attacker reverse-engineers your Flutter app and repackages it (creating a new APK using your code), they would need your original signing key to sign the new APK. If the attacker signs the APK with a different key (which they likely will), the freeRASP plugin will detect that the app was signed with a different key than the original.
@@TalsecJaroslav Yes I understood. but question is, attacker will sign the APK after removing such conditions like freeRASP and then they will market it, so if someone installed the fake version, there is no checking. this is what attacker do with most of the well-known games apk.
@@AUP-eg9xw +1 for me i watched the hole video for 1 hour, to find how freeRASP prevents attackers from change some dart code, like sign hash i also know after repackage, sign hash will change, but attacker will change it also!
@@AUP-eg9xw First and foremost, it’s important to note that removing protection is a complex process. freeRASP is designed with multiple layers of countermeasures to deter any attempts to disable it. Additionally, our BusinessRASP offering includes an advanced feature called AppiCrypt. This technology safeguards your APIs by requiring a cryptographic secret from the Talsec SDK. Even if an attacker manages to bypass certain protections, the app will be unable to communicate with your secure backend, effectively rendering it non-functional in most cases.
@@AUP-eg9xw First and foremost, bypassing or disabling protection is a challenging endeavor. freeRASP includes advanced mechanisms to detect and respond to any attempts to disable its safeguards. In addition, BusinessRASP provides feature called AppiCrypt, which secures the application’s API calls by requiring a unique cryptographic secret (cryptogram). Even if an attacker manages to bypass or remove RASP, the application will often remain unusable, as it won’t be able to perform network calls protected by AppiCrypt.
Majid trying his best to hide his sleep during the introduction round :). Really great video btw. Thank you
It is really cool. Congratulation guys
I did not get it how to get the Hashes, please.
I mean converting to Android is not working.
how to get the Hashesfrom Flutter.
Dear @Majid this may be irrelevant but which software are you using for these split screen recordings, editing, etc?
Many thanks Majid
thank you very much
Love this !!!!
At some point, it is stated that the expectedPackageName should be hardcoded. What happens if we are using the same codebase for multiple clients with different Package Names and hashes ?
Talsec has a premium SDK (RASP+) which is recommended solution for White Label apps vendors and for SDK vendors, where there could be many packages/hashes for the same codebase
Is Watcher Email Required here or can be left blank?
As of freeRASP version 6.8.0 and earlier, watcher mail is *technically* required, but you can provide empty string.
However, I do not recommend doing this, because you'll lost option to receive security reports which are vital part of freeRASP.
hi @Majid, if someone tempered or reverse engineer my flutter app, then how this free_rasp plugin will detect it? as attacker will pack a new apk using my same code and that will be a entire new apk. so how my actual apk detects like someone tempered or reverse-engineered my app?
Every APK is signed with a unique key that is known only to you (and Google, in case of apps distributed via the Play Store). If an attacker reverse-engineers your Flutter app and repackages it (creating a new APK using your code), they would need your original signing key to sign the new APK.
If the attacker signs the APK with a different key (which they likely will), the freeRASP plugin will detect that the app was signed with a different key than the original.
@@TalsecJaroslav Yes I understood. but question is, attacker will sign the APK after removing such conditions like freeRASP and then they will market it, so if someone installed the fake version, there is no checking. this is what attacker do with most of the well-known games apk.
@@AUP-eg9xw
+1
for me i watched the hole video for 1 hour, to find how freeRASP prevents attackers from change some dart code, like sign hash
i also know after repackage, sign hash will change, but attacker will change it also!
@@AUP-eg9xw
First and foremost, it’s important to note that removing protection is a complex process. freeRASP is designed with multiple layers of countermeasures to deter any attempts to disable it.
Additionally, our BusinessRASP offering includes an advanced feature called AppiCrypt. This technology safeguards your APIs by requiring a cryptographic secret from the Talsec SDK. Even if an attacker manages to bypass certain protections, the app will be unable to communicate with your secure backend, effectively rendering it non-functional in most cases.
@@AUP-eg9xw
First and foremost, bypassing or disabling protection is a challenging endeavor. freeRASP includes advanced mechanisms to detect and respond to any attempts to disable its safeguards.
In addition, BusinessRASP provides feature called AppiCrypt, which secures the application’s API calls by requiring a unique cryptographic secret (cryptogram). Even if an attacker manages to bypass or remove RASP, the application will often remain unusable, as it won’t be able to perform network calls protected by AppiCrypt.