Scribd
Upload
120 views22 pages

MOBISEC 2020 - 05 - Real-World Android Apps

The document discusses various advanced concepts related to real-world Android applications including app signing, shared user IDs, resources, runtime execution, reflection, dynamic code loading, and serialization. It explains how app signing authenticates developers but not necessarily the legitimacy of an app. Shared user IDs allow two apps to share private data and components if they have identical certificates. Reflection and dynamic code loading are commonly used for both benign and malicious purposes in apps.

Uploaded by

aaaaaa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
120 views22 pages

MOBISEC 2020 - 05 - Real-World Android Apps

The document discusses various advanced concepts related to real-world Android applications including app signing, shared user IDs, resources, runtime execution, reflection, dynamic code loading, and serialization. It explains how app signing authenticates developers but not necessarily the legitimacy of an app. Shared user IDs allow two apps to share private data and components if they have identical certificates. Reflection and dynamic code loading are commonly used for both benign and malicious purposes in apps.

Uploaded by

aaaaaa
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 22

Real-World Android Apps

Mobile Systems and Smartphone Security


(MOBISEC 2020)
Prof: Yanick Fratantonio
EURECOM 1
Pro-ing up

- Last time: basic things about Android apps

- Today: "complicated" things about real-world apps

- Many of these things are used by malware or have


security repercussions

2
App Signing

- Each app is signed with a certificate

- A certificate is
- the public key of a public/private key pair
- some other metadata identifying the owner of the key

- The owner of the certificate holds the corresponding


private key
3
Primer on cryptographic signatures

- Developer generates a public/private key pair:


- private key: PRIV
- public key: PUB

- The developer keeps PRIV secret

- PUB, as the name suggests, is public

4
Primer on cryptographic signatures

- Two primitives: sign & verify

- sign(MESSAGE, PRIV) ~> SIGN


- Only the developer can create a valid signature

- verify(MESSAGE, SIGN, PUB) ~> VALID / NOT VALID


- Everybody can check whether the signature is valid or not

5
App Signing

- Certificate doesn't need to be signed by cert. authority


- Apps' certificates can be self-signed
- Major difference with SSL certificates

- Purpose: distinguish app authors, NOT identify them

- You can distinguish "system" vs "normal" apps


- System apps are those that are signed with a "system" certificate
- That's how the system deals with "signature" permissions
6
App Signing

- You can determine that a given Facebook app has the


same developer as a given Messenger app

- But by only checking an app's certificate...

- ...you CANNOT determine whether the Facebook app you


have is the legitimate/official one!

7
App's certificate vs. SSL certificate

- Your browser knows that the "facebook.com" website you


are talking to IS the real, legitimate one

- That certificate is signed by another certificate, which is


signed by another certificate, which is signed by ....

- ... which is signed by a certificate that your browser trusts


8
android:sharedUserId (doc)

- Apps can request to be assigned the same Linux User ID


- Only if their certificates are identical

- All security barriers discussed so far are gone


- Two apps with the same Linux User ID share everything
- Both can access each other (private) internal storage
- Both can access each other components, regardless of configuration
<manifest xmlns:android="..." <manifest xmlns:android="..."
package="com.mobisec.app.ONE" package="com.mobisec.app.TWO"
android:sharedUserId="com.mobisec.shareduser"> android:sharedUserId="com.mobisec.shareduser">

9
Resources (doc)

- Resources are the additional files and static content that


your code uses

- drawable, layout, raw


- values
- arrays
- colors
- strings

10
Resources example: strings.xml

- In strings.xml
<resources>
<string name="secret_string">Juicy Secret</string>
</resources>

- In the Java code


String secret = getResources().getString(R.string.secret_string);

- From the docs

11
Resources under the hood

invoke-virtual {p0},
Lcom/example/MyActivity;->getResources()Landroid/content/res/Resources;
move-result-object v3
const v4, 0x7f07002b
invoke-virtual {v3, v4},
Landroid/content/res/Resources;->getString(I)Ljava/lang/String;
move-result-object v1

From res/values/strings.xml
<string name="secret_string">Juicy Secret</string>

From res/values/public.xml (it specifies the mapping)


<public type="string" name="secret_string" id="0x7f07002b" />
12
RunTime.exec() (doc)

- Analogous of C's system() or Python's os.system()

- Runtime.exec("cp ../flag /sdcard/leaked-flag.txt")

13
Reflection (doc)

- Java interface to programmatically "play" with Java


objects beyond what's normally possible

- Bypass access modifiers (e.g., private, protected, final)


- You can invoke private methods or get/set private fields

- Enumerate / iterate over methods/fields of a class

14
Example of Reflection

peppa.pig();

try {
Method m = peppa.getClass().getMethod("pig");
m.invoke(peppa);
} catch (...) {
...
}

15
Reflection Benign Use Cases

- Google gson's library: github

- "Gson is a Java library that can be used to convert Java


Objects into their JSON representation. It can also be
used to convert a JSON string to an equivalent Java
object."

16
Reflection Malicious Use Cases

- Malware authors are big fans of reflection

- peppa.pig();
It's a string!
invoke-virtual {v3, v4},
Lcom/example/Peppa;->pig()V

- peppa.getClass().getMethod("pig").invoke(peppa)
???????

Obfuscation made easy!


17
Dynamic Code Loading

- Apps can "load" additional code at run-time


- This code can be loaded from the file-system
- It could be embedded in the app itself
- It could be a "just-downloaded" piece of code

- Benign apps do this to


- A/B testing
- Sharing common framework
- Download additional parts (e.g., "levels" of a game)

18
Dynamic Code Loading

- Malicious apps do this for... obfuscation!

DexClassLoader classloader = new DexClassLoader(


peppaApkFile.getAbsolutePath(), tmpDir.getAbsolutePath(),
"data/local/tmp/natives/",
ClassLoader.getSystemClassLoader());
Class<?> cls = (Class<?>) classloader.loadClass("com.mobisec.Peppa");
Method m = cls.getMethod("pig");

Execute This! Analyzing Unsafe and Malicious


Dynamic Code Loading in Android Applications, Strings!
Poeplau et al., NDSS 2013
19
Serialization

class Peppa():
def __init__(self, n, s):
p = Peppa(42, "ciao")
self.n = n # int
self.s = s # string

pickle.dumps(p)
def pig(self):
return n*s

"(i__main__\nPeppa\np0\n(d
p1\nS's'\np2\nS'ciao'\np3\ns
S'n'\np4\nI42\nsb."
20
Serialization

- The serialized version ...


- ... encodes details about a specific instance of Peppa
- ... does NOT encode the actual definition of Peppa

- To load the instance of Peppa from the raw bytes


- You code needs to have Peppa's definition within the visible classes

- How is this relevant for Android apps?

21
Serialization

- Objects need to be serialized before are sent via Binder


- Example: Intents!
- Two main interfaces
- Parcelable (doc)
- Implemented by objects whose instance can be written to / restored from a Parcel
- Parcel: a container for an object to be sent via Binder (doc)
- Serializable (doc)
- More generic serializable interface

- Nice tutorial: link


22

You might also like