Another day, another MITM attempt

Dear Lazyweb,

Can anyone explain to me how to install "Xposed Framework" into an Android emulator on macOS? None of the instructions I've found work.

Rumor has it that this "JustTrustMe" plugin will make mitmproxy work with pinned apps. I got Xposed from here and the installer from here (why isn't it bundled?) and tried it with a "Google API 26" x86_64 emulator. The installer keeps telling me my device isn't rooted, but I've done "adb root".

Or should I be using Frida instead, which looks almost-incomprehensibly more complicated?

Previously, previously.

Tags: , , , , , , ,

19 Responses:

  1. MrMeh says:

    Reading through this article: https://www.eff.org/deeplinks/2020/01/ring-doorbell-app-packed-third-party-trackers

    they ran into the same issues, and used https://frida.re/

    It was only through the powerful dynamic analysis framework Frida that we were able to inject code into Ring at runtime, which ensured that the certificate provided by our mitmproxy instance would be accepted as valid. This allowed us to inspect all HTTPS traffic sent through the app.

    • jwz says:

      Yes, you are right that people claim that Frida can do the thing that I need. People also claim that Xposed can do the thing that I need. I can't figure out how to install either of them. But Xposed looks a lot simpler.

      • MrMeh says:

        That part of the article was really missing. Google has this as a step by step, but not easy or simple by any means

        https://medium.com/@ved_wayal/hail-frida-the-universal-ssl-pinning-bypass-for-android-e9e1d733d29

      • March says:

        Xposed and Frida will definitely both work. What emulator are you using? I've just successfully installed Xposed on an emulated Samsung S3, Android 6.0/API 23 using Genymotion.

        • jwz says:

          Whatever the thing is that comes with Android Studio. I have the latest, 3.5.3.

          • March says:

            Yeah, I'd definitely switch to Genymotion. Installing Xposed on mine took me all of a few minutes. I can guarantee it'll work better than the weird emulated Android in Studio. It's free and it's very easy to use, although the ARM emulation relies on VBox as a backend and can be slow as a dog without very good hardware virtualisation support as a result. If you need the versions I'm using of anything related, just let me know.

            • jwz says:

              ....

              .... I'm supposed to pay someone to run an emulator of a phone in the Clown?

              Is this a joke?

              "Get 60 minutes of free usage. No Credit Card Required!"

              You know you could buy a physical phone for less than these grifters charge, right?

              • march says:

                lol, don't pay anything. there's a free version that's essentially a wrapper around VirtualBox that makes life easy for you.
                https://www.genymotion.com/fun-zone/
                i know, the URL is ridiculous, but being able to emulate any android version quickly is a godsend

              • the hatter says:

                Not the perfect solution, but ATV boxes (possibly with lineage if that suits better than stock) are remarkably cheap, and come with a lot less baggage then hosting a phone, and only a tiny number of disadvantages compared to doing stuff on an actual phone Depends how you value another wall wart/ethernetport/device to care about vs your current level of sanity.

  2. thielges says:

    There’s no reason why these Internet of Things devices need to communicate with vendor servers in order to do their job. The core functionality can be implemented locally in the device itself and the phone ap controlling the device could simply connect over the customer’s LAN.

    Yeah, the requirement to be on the same WiFi LAN is limiting. But do you really need the ability to adjust your Nest thermostat from hundreds of miles away? Even if you did need really remote control, the IoT device could act directly as a server.

    Relaying all control and communication through the vendor’s server not only makes it easy for them to divert data to 3rd parties. It also creates one massive single point of failure. There’s nothing stopping a vendor from deciding to terminate a product and shut down their servers. Of course you want to upgrade to the newest model, don’t you?

    • Wout says:

      Capitalism will prevail, which means that whichever vendor creates the cheapest golden cage that isn't onerous will set the standard for everyone else.

      We readers of this blog care about this, but everyone else wants things to just work with the least hassle for the lowest price.

      End result is some device much like the Ring, methinks.

      • thielges says:

        Right. I keep thinking that it will take some major calamity to wake up the general population to the risks of handing over personal information. The 2016 Cambridge Analytica Bragbook election debacle apparently wasn’t enough. Looking back through history isn’t very encouraging when there are massive crimes committed while the population passively allows the government to round up their innocent neighbors on a weak xenophobic premise. The freedoms we forfeit for a little comfort and convenience.

  3. moof says:

    For Xposed, you probably need to have SuperSU or Magisk installed before Xposed will install itself.

    • jwz says:

      I started going down the SuperSU rathole, which I also couldn't get to install, and then I thought: "Wait, how does this make any sense that I'm trying to 'jailbreak' an emulated device where I already have root access through adb?"

      • Ham Monger says:

        You're right that thisis completely insane.

        adb root isn't the same as rooting the device, though it could be enough to let you install the framework into the boot image.

        SuperSU lets you authorize attempts at post-boot privilege escalation via system() calls, which maybe the Xposed installer needs to do in order to write into /?

        Every time I've installed Xposed, it needed me to root the device, installing SuperSU in the process, installing the framework (classic, into system), rebooting, noticing that the framework isn't active, installing the framework again (classic, into system), rebooting again, noticing that now, the installer identifies the framework as active, and then installing modules, rebooting to make each of them active.

        It felt very like Windows, so I attempt to forget as much of the mechanical process as possible (click here, poke that, change this setting, etc.) immediately thereafter.

      • Commandhat says:

        Did you give that mac client for Bluestacks a shot? It emulates a nexus 4 by default and aside from the fact it isn't even trying to simulate accurate hardware to the software inside it, you should be able to do anything you want to the network stack inside bluestacks since it runs as adb root by default.

  4. jwz says:

    Ok, getting closer... following these instructions I was able to get mitmproxy working with Twitter in the Android emulator. My steps, for the record:

    emulator -avd Nexus_5_26 -writable-system
    (API 28 didn't work but API 26 did)
    Log in to Twitter and Instagram before setting up the proxy stuff, then quit the emulator.

    sudo pip3 install Frida
    sudo pip3 install frida-tools
    sudo pip3 install objection
    unxz frida-server-12.8.10-android-x86_64.xz
    mv frida-server-12.8.10-android-x86_64 frida-server

    emulator -avd Nexus_5_26 -writable-system -http-proxy http://0.0.0.0:8080
    adb root
    adb push frida-server /data/local/tmp
    adb shell chmod 777 /data/local/tmp/frida-server
    adb push ~/.mitmproxy/mitmproxy-ca-cert.cer /data/local/tmp/cert-der.crt

    Launch Twitter in the emulator.

    adb shell /data/local/tmp/frida-server &

    In another shell:
    frida -U -f com.twitter.android -l fridascript.js --no-paus

    It works! I see Twitter protocol in mitmproxy. Then I tried Instagram with the same steps except for:

    frida -U -f com.instagram.android -l fridascript.js --no-paus

    But Instagram doesn't talk to the proxy and receives no data. Frida prints "Waiting for the app to invoke SSLContext.init()..." as with Twitter, but nothing after that, while Twitter printed "App invoked javax.net.ssl.SSLContext.init...".

    So I guess Instagram is doing the certificate dance differently than Twitter. HOORAY.

  5. Aleksejs says:

    Have you tried using the binaries from github.com/itsMoji/Instagram_SSL_Pinning?

    • jwz says:

      Yes, with no luck. I did it like this:

      Launch emulator without proxy (API 28 from Android Studio).
      Install the linked copy of Instagram 126 x86.
      Open Instagram. Refresh feed. Force stop Instagram.
      Quit emulator and re-launch with proxy.
      Install the linked libliger.so.
      Open Instagram. It says "cannot refresh feed" and doesn't proxy.

  • Previously