Nurbanu Kahraman06/24/2022, 10:51 AM
Vivek06/24/2022, 5:26 PM
Daniel B Duval06/24/2022, 10:03 PM
Sam06/25/2022, 12:27 PM
Marcin Wisniowski06/26/2022, 1:57 PM
use a library like RootBeer to detect rooted devicesOr, alternatively, don't break your own app and annoy users, just like you don't break desktop and web apps just because someone has admin access on their PC (which is almost everyone).
Sam06/26/2022, 2:00 PM
Marcin Wisniowski06/26/2022, 2:04 PM
Sam06/26/2022, 2:11 PM
Marcin Wisniowski06/26/2022, 2:16 PM
There are legitimate reasons why wiping all customer data when root is detected could prevent certain attacksYep, totally agree! I just said it doesn't stop app piracy, that's all I'm saying.
compare root detection to a padlock image is disingenuousAgain, only in the context of stopping app piracy, should have been clearer, my bad. Padlock icons provide legitimate value (but not by making the process more secure), and root detection provides legitimate value (like the example you brought up, but not by stopping piracy). That's the parallel I was drawing.
DALDEI06/26/2022, 8:30 PM
Marcin Wisniowski06/26/2022, 8:37 PM
why, in the android community and toolchains, that the concept of obfuscating code is held to be 'presumed universally agreed as fact' a critical form of security ?It's not that obfuscation is perfect, it's just that it makes reverse engineering harder at almost no cost to the developer, so there is no reason not to use it. Plus, as is the case with ProGuard/R8, obfuscation is just one part of a minification process that increases performance and reduces app size, which you'd always want anyway. You are absolutely right that no one should rely on obfuscation for security, but it doesn't mean it doesn't help, and you can just consider it a side effect of minification if you want, where the actual goal is performance and app size.
DALDEI06/27/2022, 4:15 AM
Marcin Wisniowski06/27/2022, 11:12 AM
Everything works great at dev time, then buid/ship release all of a sudden a bunch of APIs fail with the equivalent of 'class not found' or 'field not found'Yeah, learned that the hard way too. Issues you bring up definitely happen in the real world, it's not perfect. Obviously everyone's experience is different, but in my experience these were never big issues, but occasional issues with a quick fix. I would assume that's the case for most devs. You say removing unused code breaks reflection / dynamic jar loading, and yet it's on by default, which is true, but at the same time it's considered a bad idea to use reflection on Android, and dynamic jar loading is completely forbidden on Google Play (where most apps end up). So I don't see an inconsistency in "universal beliefs" here: the defaults assume you don't do things that generally should't be done, and if you do them, that's fine, but then the defaults weren't made with you in mind.
devices are usually beefy enoughDevelopers going "eh, who cares about optimization, devices are powerful nowadays" is never a good thing and this shouldn't be a factor. If it makes sense for your use case, it's absolutely within your power to not use obfuscation, but I disagree it shouldn't be the default. Most apps don't use fancy reflection or dynamic code loading, nor should they (and if they do, it's through libraries that handle this correctly and have ProGuard rules built-in). And most devs don't want to make it easy to reverse engineer / copy their app. Ultimately it comes to how you weight the pros and cons. To me the issues you bring up, while absolutely real, are not a big deal and come up rarely (again, your experience may differ). For most companies it would be unthinkable to just publish your source code in the open , which you effectively do without obfuscation, and the occasional issues with it are insignificant compared to other everyday issues of development. I would be surprised if issues caused by obfuscation made a top 10 list of issues Android developers face in their work.
James Hamilton06/27/2022, 2:26 PM
Does anyone have any knowledge or opinion on why, in the android community and toolchains, that the concept of obfuscating code is held to be 'presumed universally agreed as fact' a critical form of security ?
...that its difficult to separate from other toolchain concepts such as minificationIn terms of ProGuard/R8, they've been in the toolchain for a long time now and so it's become standard for Android developers to use them but @Marcin Wisniowski's comment is important here w.r.t. ProGuard/R8: "you can just consider it a side effect of minification if you want, where the actual goal is performance and app size." It seems that there is a common misconception that the goal of ProGuard/R8 is obfuscation and with a cursory look at the final APK it may seem like that but the primary goal of these tools is minification, not security. ProGuard does 3 main things with the primary goal of shrinking/minification: * Renaming class, method, field names (name obfuscation) -> this makes the app smaller because the identifiers are shorter; it makes the app only slightly harder to reverse engineer. * Shrinking (tree-shaking) to remove unused classes, methods, fields -> this is especially useful to remove unused library code which can add a lot to an app. * Code optimization -> this is intended to shrink the code rather than obfuscate it; in some ways it's similar to code obfuscation since it does modify the code such that the result is not the same as the original, but that's not the primary goal. The primary goal of ProGuard optimizations is always to make smaller/faster code; not to make obfuscated code. ProGuard doesn't apply any code obfuscation specific techniques like control flow obfuscation, opaque predicates, virtualization etc.
louiscad07/04/2022, 7:37 PM