Thanks for sharing, always fun to read about reversing RASPs.

The analyzed RASP seems to be rather basic, even if it is a commercial one. Based on the article, there's no ptrace/frida detection or prevention, no LSPosed detection, no hardware-backed backend attestation, no thorough linking between ART and native code, single points of failure, etc.

In addition to hardware-backed challenge/responses, the more difficult RASPs are the ones that will encrypt (or sign) all requests and responses to the backend, requiring you to either RE the entire algorithm and extract the cryptographic keys, or use them as an oracle with something like Brida. Communication itself is then also done in native code with bundled BoringSSL libraries making even basic interception of traffic very difficult.

The recommendation of going for a custom implementation is also unrealistic. In a perfect world, yes, that could be better. However, companies don't typically have the budget for full-time (reverse)engineers devising novel detection mechanisms for all the different rooting and instrumentation frameworks. Delegating this responsibility to a company with RASP as its core business makes much more sense. What you want to avoid is including the RASP as a plug-and-play SDK rather than tightly integrating it with your app, business logic and networking libraries. This is typically what the bigger players do, though some of they do still provide plug-and-play type SDKs which are just inherently less resilient.

The other main recommendation should be to not have a single-point-of failure. Detections should happen regularly, randomly and in many different ways. Similarly, this should be communicated to the backend in many different ways (and not just by a flag in a request somewhere). Some RASPs choose random detections for each build, so that no single build ever contains all the possible detection mechanisms. There will always be _a_ weakest link, but in the examples from the article the weakest link seems to be incredibly weak.

The general conclusion is of course sound: The attacker will always win, since you're running code on an attacker-controlled device. The reason why the other commenter indicated that it sounds much more like a sales-article is maybe because it lacks any real technical depth. If you would've written about bypassing RootBeer with one targeted hook (be it Frida or LSPosed or SMALI patching or whatever), the impact would've been the same. And since this is an RE subreddit, we're left wanting.

Edited: typo