Reverse Engineering the Yik Yak Android App

Every once in awhile, I’ll  come across an app that implements some hardening techniques that make reversing a little more interesting. This was the case when I recently tried proxying the API requests for Yik Yak, a popular social media application exclusively available for mobile platforms that allows semi-anonymous user communication across a 5-mile radius (typically college areas).

Opening the app while performing a self-MitM attack effectively kills all API communication — typically, an indicator of SSL pinning.

After decompiling the APK and reviewing the Java source code, it was clear that the developers had also used an obfuscation tool to optimize/protect their build. Here’s an example method:

    public int hashCode() {
        if (e == null) {
            i1 = 0;
        } else {
            i1 = e.hashCode();
        l2 = f;
        i3 = g;
        if (h) {
            c1 = '\u04CF';
        } else {
            c1 = '\u04D5';
        j3 = fs.a(i);
        if (j == null) {
            j1 = 0;
        } else {
            j1 = j.hashCode();
        k3 = Arrays.hashCode(k);
        l3 = Arrays.hashCode(l);
        i4 = Arrays.hashCode(m);
        if (n == null) {
            k1 = 0;
        } else {
            k1 = n.hashCode();
        if (o == null) {
            l1 = 0;
        } else {
            l1 = o.hashCode();
        j4 = (int) (p ^ p >>> 32);
        if (q != null) {
            i2 = q.hashCode();
        return ((((((l1 + (k1 + ((((j1 + ((c1 + (((i1 + ((j2 + 527) * 31 + k2) * 31) * 31 + l2) * 31 + i3) * 31) * 31 + j3) * 31) * 31 + k3) * 31 + l3) * 31 + i4) * 31) * 31) * 31 + j4) * 31 + i2) * 31 + Arrays.hashCode(r)) * 31 + s) * 31 + fs.a(t)) * 31 + b();

Note that the variables, classes, and methods have been renamed from their original, human-friendly forms. As I looked over more of the code, it also seemed like string constants were obfuscated — a feature found in third party tools like DexGuard. While obfuscators are generally a good practice for several reasons, they only marginally delay the reversing process by making the code harder to follow. In my experience, obfuscators also make Java decompilation less reliable, so I’ll mostly be working with smali (examples are in Java when available).

Next, I began grepping the smali source files for strings relating to common SSL pinning implementations. I quickly found what I thought would be the pinning check:

.method public checkServerTrusted([Ljava/security/cert/X509Certificate;Ljava/lang/String;)V
    .locals 3

    const/4 v2, 0x0

    .line 153
    iget-object v0, p0, LCG;->e:Ljava/util/Set;

    aget-object v1, p1, v2

    invoke-interface {v0, v1}, Ljava/util/Set;->contains(Ljava/lang/Object;)Z

    move-result v0

    if-eqz v0, :cond_0

    .line 163

    .line 160
    invoke-direct {p0, p1, p2}, LCG;->a([Ljava/security/cert/X509Certificate;Ljava/lang/String;)V

    .line 161
    invoke-direct {p0, p1}, LCG;->a([Ljava/security/cert/X509Certificate;)V

    .line 162
    iget-object v0, p0, LCG;->e:Ljava/util/Set;

    aget-object v1, p1, v2

    invoke-interface {v0, v1}, Ljava/util/Set;->add(Ljava/lang/Object;)Z

    goto :goto_0
.end method

I bypassed the above method by editing it to immediately return void, but after building, signing, and installing the new APK, I had the same “Internet Connection” error as above. After trying a few different edits/builds with the same result, I began to suspect that Yik Yak was using some tamper detection logic (a package signature check) in an effort to prevent reverse engineering. I confirmed this by installing an unmodified, though resigned, APK that resulted in the same error.

In order to bypass the tamper detection, I changed focus and started searching for its decision point. In Android, developers can access the package’s signatures using the PackageManager class like this:

PackageManager pm = context.getPackageManager();
String packageName = context.getPackageName();

Signature[] sigs = pm.getPackageInfo(packageName, PackageManager.GET_SIGNATURES).signatures;

Since signatures are returned as instances of , I searched the source and found the following method:

    public static Signature[] a(Context context)
        if (context != null) goto _L2; else goto _L1
        PackageManager packagemanager;
        return null;
        if ((packagemanager = context.getPackageManager()) == null) goto _L1; else goto _L3
            context = packagemanager.getPackageInfo(context.getPackageName(), 64);
        // Misplaced declaration of an exception variable
        catch (Context context)
            return null;
        if (context == null) goto _L1; else goto _L4
        context = ((PackageInfo) (context)).signatures;
        return context;

It was pretty clear that this method was used as a wrapper to fetch the signatures of the current build. Note that on line 12, the value 64  correctly matches the constant value for PackageInfo.GET_SIGNATURES. Searching for usages of this class produced a few results:

Rather than attempt to workaround multiple decision points, I decided to spoof the package signature by altering the above method to return the signature of the official Yik Yak build. In order to do that, I needed to know the signature that the app was looking for. I briefly hunted through the code in the results above, but didn’t find the hard-coded signature (probably due to obfuscation). Instead of further searching (or debugging) the code, I ran a script that extracts the signature from a given APK:

After I had the expected signature, I patched the above smali method to return it:

.method public static a(Landroid/content/Context;)[Landroid/content/pm/Signature;
    .locals 4

    const/4 v0, 0x0
    const-string v0, "3082019d30820106a003020102020452ab687f300d06092a864886f70d010105050030123110300e0603550403130777696c6c69616d3020170d3133313231333230303531395a180f32313133313131393230303531395a30123110300e0603550403130777696c6c69616d30819f300d06092a864886f70d010101050003818d00308189028181008fdfd8a1c6319b8d45445dc9c28a89600062dd00ad14c5ee3fac8d4812d5dfa3a5c6e534f242d5e91d6acb1807d618d44731973c4f69c328b6b755962810ed2cf8ff19fa5c6de40a34be5e92c6686e772fa864784e74144465272c260f877395df37b897e8147bbcdce15b8f11ee125c82bf9d2de9beb92056edea6f301d15f70203010001300d06092a864886f70d0101050500038181000a2f44f1a8d78b4d1965f0e60f9ef10826827ae131e6c4a3f976fc85f36f94578a698f904fd0a37a690f3dd338c16c3e408d77670543bb5b022d7c1bc86a0574e3e593092f1e06de141f04f6a68d78dbc5aa36f0a82062ecb03c1e7285a55b5ccfea58c193572d8d7542ca7a31748aabc7edff7990048a11ae5ef090074c9b25"

    .line 11
    .local v0, "fake":Ljava/lang/String;
    const/4 v2, 0x1

    new-array v1, v2, [Landroid/content/pm/Signature;

    const/4 v2, 0x0

    new-instance v3, Landroid/content/pm/Signature;

    invoke-direct {v3, v0}, Landroid/content/pm/Signature;-><init>(Ljava/lang/String;)V

    aput-object v3, v1, v2

    .line 13
    .local v1, "sig":[Landroid/content/pm/Signature;
    return-object v1  
.end method

Here’s that same code in Java:

public static Signature[] a(Context context)
    String fake = "3082019d30820106a003020102020452ab687f300d06092a864886f70d010105050030123110300e0603550403130777696c6c69616d3020170d3133313231333230303531395a180f32313133313131393230303531395a30123110300e0603550403130777696c6c69616d30819f300d06092a864886f70d010101050003818d00308189028181008fdfd8a1c6319b8d45445dc9c28a89600062dd00ad14c5ee3fac8d4812d5dfa3a5c6e534f242d5e91d6acb1807d618d44731973c4f69c328b6b755962810ed2cf8ff19fa5c6de40a34be5e92c6686e772fa864784e74144465272c260f877395df37b897e8147bbcdce15b8f11ee125c82bf9d2de9beb92056edea6f301d15f70203010001300d06092a864886f70d0101050500038181000a2f44f1a8d78b4d1965f0e60f9ef10826827ae131e6c4a3f976fc85f36f94578a698f904fd0a37a690f3dd338c16c3e408d77670543bb5b022d7c1bc86a0574e3e593092f1e06de141f04f6a68d78dbc5aa36f0a82062ecb03c1e7285a55b5ccfea58c193572d8d7542ca7a31748aabc7edff7990048a11ae5ef090074c9b25";

    Signature[] sig = new Signature[]{new Signature(fake)};

    return sig;

Now that the package signature check had been bypassed, I installed the new build to test — unfortunately, I had the same error. Since this was likely due to some additional pinning code that I missed, I searched through the sources again and found this method:

    public void a(String s, List list)
        List list1;
        boolean flag;
        flag = false;
        list1 = (List)b.get(s);
        if (list1 != null) goto _L2; else goto _L1
        int l = list.size();
        int i = 0;
                if (i >= l)
                    break label1;
                if (list1.contains(a((X509Certificate)list.get(i))))
                    break label0;
        } while (true);
        if (true) goto _L1; else goto _L3
        StringBuilder stringbuilder = (new StringBuilder()).append("Certificate pinning failure!").append("\n  Peer certificate chain:");
        int i1 = list.size();
        for (int j = 0; j < i1; j++)
            X509Certificate x509certificate = (X509Certificate)list.get(j);
            stringbuilder.append("\n    ").append(a(((Certificate) (x509certificate)))).append(": ").append(x509certificate.getSubjectDN().getName());

        stringbuilder.append("\n  Pinned certificates for ").append(s).append(":");
        i1 = list1.size();
        for (int k = ((flag) ? 1 : 0); k < i1; k++)
            s = (Dx)list1.get(k);
            stringbuilder.append("\n    sha1/").append(s.b());

        throw new SSLPeerUnverifiedException(stringbuilder.toString());

Bypassing this method with return-void  finally disabled the pinning implementation, allowing me to successfully proxy the app’s API requests.

Connection: Keep-Alive
Accept-Encoding: gzip
Cookie: __cfduid=***REMOVED***
User-Agent: Dalvik/2.1.0 (Linux; U; Android 5.1.1; Nexus 6 Build/LMY48M) 3.0

The infosec world is full of examples of companies poorly handling software security, but it’s certainly progress to see more efforts to improve such security by organizations like Yik Yak (at least as far as Android is concerned).

Share this: Facebooktwitterlinkedin