I think Android is vulnerable, the apk could be re...

# android

[Breaker ACT]

I think Android is vulnerable, the apk could be reversed and read the logic (not too easy but not too hard). Any idea to prevent the app logic/data ?
There is few common way I see:
1. Wrap the logic in native code like C, Go and call from Java/Kotlin.
But the hacker can use the .so file as the blackbox, they doesn't need care about the logic inside. They just put the input and get output.
2. Encrypt data. But the app have to decrypt to read the data. So attacker can read the reverse code from apk to re-procedure the decrypt logic
3. Put the data in remote source like firebase remote config... The attacker can use runtime tools like frida to read the pure data.

So what you's solution to make the apk much possible much to be stolen data/logic ?

[CLOVIS]

C/GO/etc can be reversed too. If you don't want an attacker to know your secrets, don't put them in the app. An attacker cannot reverse something that is only server-side.

[Breaker ACT]

Okay. If we do not put the logic in the app, we gonna put it into server side.

But attacker can use our API to get the data. What solution ?

[CLOVIS]

If your API is well written, they cannot know anything more using it than they would know by using the app normally.

[Breaker ACT]

What is the criterial to know API is well written or not ?

[wbertan]

☝️ yeap, and you can pin your certificates to avoid man-in-the-middle situation.

[Breaker ACT]

For me, I used to get data from many apps. It not too harrd

[CLOVIS]

If you want to display information to a user, you can't stop that user from using it any way they want.

[Breaker ACT]

SSL Pinning can be by passed easily by Frida

[CLOVIS]

SSL pinning protects the user from an attacker server pretending to be the real one. It doesn't protect the real server from attackers pretending to be real users.

[Breaker ACT]

If you want to display information to a user, you can't stop that user from using it any way they want.

Agree, we can not prevent user use it.

[wbertan]

A year ago we had an introductory call with https://www.guardsquare.com/
They have some solutions for you to check and know if the app was tampered with, etc.

[Breaker ACT]

@wbertan Thanks. I'm gonna learn it

[CLOVIS]

Reading the main page, that's a bunch a marketing-speak. What does it do, exactly?

[CLOVIS]

Point is, though, you cannot trust a client app. You can use tools to make it harder to tamper with, but someone will figure out a way. Attend any cyber-security convention and at least one talk will be about bypassing Google Play fingerprinting, etc.

[wbertan]

They mention like injecting some random code in compilation time, so can check later for changes (not sure if they check the hash of the compiled code too)
We were looking for the DexGuard.

[CLOVIS]

Also, OP was asking about stopping users from knowing how it works, not stopping users from changing it (which is what GuardSquare attempts to do, if my understanding is correct)

[ephemient]

this isn't even an Android-specific issue. anything on the client, whether it's an Android app, iOS app, desktop app, web app, is running in an environment outside of your control (unless you can control the hardware it runs on)

[Breaker ACT]

I was see the way an app avoiding stolen data and logic.
They put the logic behind C code with very complexity handle. (Maybe C can be reverse but with the huge of logic and cross function call inside).

They take the input from app and return the bitmap to android to display 🙂

[CLOVIS]

(even if you can control the hardware, there have been multiple attacks on ATMs where attackers know where to drill a whole to insert a USB stick)

[ephemient]

all the logic in C code: that sounds just like a traditional desktop or iOS app, and those are definitely crackable with motivation

[CLOVIS]

@Breaker ACT actually, it's the opposite. Reverse engineers tend to be more familiar with C/C++ than Java. Many popular reverse engineering frameworks don't even support Java (e.g. https://github.com/cea-sec/miasm)

[Breaker ACT]

Reverse engineers will familiar with specific language they focus on. Just like our, we are Kotlin dev, but we still writing JS code. But the others will be expert on it.

[Breaker ACT]

It not the point

[CLOVIS]

I mean, reverse engineers are often people who love understanding the low-level workings of computers. It's rare that they like high-level languages. Even Rust is too high-level for most of the ones I met, because the generics pollute the binaries.

[CLOVIS]

But you're right, you shouldn't bet on it being rarer. I'm just saying writing something in C doesn't make it harder to reverse-engineering, and indeed I believe it makes it easier.

[Breaker ACT]

Do you think Java is too easy to reverse, so the valuable reverse engineer will focus on C 😄 😄

[CLOVIS]

maybe 😆

[itnoles]

If they can read java bytecode, it is a piece of cake. As for String, it will be exposed no matter what.

[srb9181]

@wbertan GuardSquure is costly solution as it charges 2$ per app install. For Java code obfuscation proguard with Minify enable can be used. For Kotlin code R8 (proguard rules are fully compatible with R8) can be used. For Resources obfuscation Resguard https://github.com/shwenzhang/AndResGuard can be used as its well maintained and open source project by we chat team.
For root device protection Rootbeer can be used https://github.com/scottyab/rootbeer as its in recommendation of OWASP MAS.
For mobile App security follow the OWASP security guidelines and testing https://mas.owasp.org/

[Michael Vandendriessche]

Not sure how this space progressed over the years but in 2015 we put some secret code in C or C++. It is not 100% secure, like mentioned above, and nothing is. But it is definitely an extra hurdle to overcome.
Anyone who is not scared of code with a few hours time can decompile a java app and find some useful things in it.
Another advantage of putting it in the backend is that you can monitor who accesses this data. If it is purely client side you won't necessarily get those statistics.
Interesting discussion, thank you everyone!

[James Hamilton]

I'm a software engineer at Guardsquare, working mainly on DexGuard & ProGuard: happy to answer any technical questions about these.

Regarding the pricing model: it's different than as described above; our pricing has fixed prices based on wide tiers of downloads, not a per app install pricing model. For more details about pricing, it's best to connect with sales though as I don't know any further details (https://www.guardsquare.com/request-pricing).

Regarding ProGuard and R8: it should be noted that these only provide name obfuscation, shrinking & optimization and their primary purpose is shrinking & optimization; they don't provide any code obfuscation/string encryption/RASP checks etc.