Anybody have any experience with reverse engineering an API.
This is one thing I've always wanted to learn but never got around too and figure I have some time to give it a shot now.
As an example, I want to reverse the Wyze Camera API. As of right now I've been able to find information and get authentication working and I've been able to query and get a list of the devices and their settings. But I can't get updating of settings working.
Would be nice if I could view the traffic from my phone, I know it is possible, I just don't know how or where to start.
This is more of a learning exercise at this point so any advice would be appreciated.
I also dropped this in the developers forum as I guess its a dev type of question.
One of the most common approaches to reverse engineering a network based protocol is to use Ethernet packet sniffing, using a tool like WireShark.
The challenge is in how to sniff the traffic between your phone and the Wyze cloud servers. Obviously, you need to use your home WiFi as there is no simple way to sniff the LTE traffic. Ok, so we need to sniff a WiFi/Ethernet packets on your home network. To do this, you need a separate WiFi Access Point that your phone connects to. Then, a managed switch that supports port mirroring. The idea is As follows:
Phone - WiFi AP - Managed Switch - Router - ISP
|
WireShark PC
By mirroring the AP’s port on the managed switch to the port with the Wireshark PC attached, you’ll be able to monitor and analyze all of the network traffic between the Wyze App on your phone and the Wyze Cloud servers.
I expect much of this to be fully encrypted, though. In that case, you’re SOL.
This is just one approach. I am sure others may have different techniques to try and reverse engineer an API.
There could still be possible solutions to this, even with pinned certificates. It is in general easier to circumvent pinned certificates in Android than iOS. This is neither easy nor straightforward, but it can be a lot of fun.
Can you provide some info on circumventing pinned certs? I'd really like to reverse engineer the Kohler Konnect API but the pinned cert has made it a real challenge. Ideally it'd be great if you know how to do it for iOS, I don't have any android devices
One of the methods I was trying with no luck was using a tool called Charles Proxy.
It basically setup a proxy and I forced my phone through it. The one probably though was I think with the https as pointed out. The instructions had me download a profile to the phone and a cert on the computer and setup the proxy on the phone so everything went through it.
I could see the calls going through but no data that I could work with. So it must be because its encrypted or something.
This github issue briefly talks about how I reversed some of the Ring APIs.
In summary, if you are dealing with pinned certs you can:
Decompile the app and put in your own certificate
If they use OOB (Android SDK) pinning there are XPosed modules (and other projects) to be able to circumvent the certificate by hijacking parts of the OS. Root is required on a device to do this.
I've set up a couple of ways to handle unpinning but the setup that I am most happy with is:
Nexus 4 (running Pure Nexus ROM 7.1.2 because Nexus 4 is easy to root and had lots of users so lots of options)
XPosed framework (version 89 in my case)
"SSL Unpinning 2.0" module
WiFi proxy server in settings to a Fiddler 4 proxy server to decrypt HTTPS traffic
The fiddler 4 certificate installed as a "Trusted credentials" certificate at the OS level
So, if they don't pin a certificate I have the Fiddler 4 certificate trusted by the OS. If they do pin a certificate then I have the XPosed module to unpin.
All of these methods may fail if they decided to implement certificate pinning without using the provided framework. OR... if they sign the APK with a different certificate and check the security signing (this is actually built into new Android versions and that's why I use 7.1.2). Or they did something else proprietary to check tamper or security. I've had this happen and it happens more frequently lately.
If it DOES happen though... You can still decompile their code. I just read what's going on and piece it together. This takes a lot more time than sniffing traffic typically though.
Decompiling even fails if it's not in Java e.g. they include a C++ binary and invoke that. Then... well, you can still decompile but it's miles more difficult. I'm not good at decompiling C/C++ code but there are so many tools to do it. It's a job by itself though.
Does Wyze have a web app at all? Even if it doesn't have a lot of functionality? If so, you can go at that. It's easier. If you are just looking at the camera part of Wyze you can try a weaker app that has already figured it out. For example, I think there is an app in Android called tinyCam that has Wyze camera support.
Of course, all of this is done for educational purposes only. Security auditing.
That's too bad. Wyze is on my list of APIs I want to learn about but I haven't done anything with it yet because it's down on my list. The last API I did was the Green Mountain Grill API. I think next up on my list is the Meater Block API (between the app and cloud, not the app and the block. I found somebody who reversed the Bluetooth API already so I can fall back on that if I want to run an ESP32). I'm excited to hear about what you learn.
I'll do this for you at least. I'm installing the Wyze app to see if I can decrypt their traffic with my setup. Please stand by.
So far I have authentication and I can query the devices and their state. But setting features such as basic on/off I can't do yet. Which was one of my key things.
I saw you mentioned fiddler so I'm just playing with that now to see if it helps any.
@gavincampbell Great you got it all sorted! I stepped away for a few hours and @codahq gave much more of a detailed answer than I would have! Enjoy playing with this!
This is great info, unfortunately the APK I have is highly obfuscated and I can't even get it to successfully decompile. I'm going to go a different route, especially since I mentioned I don't have any Android devices. I'm going to jailbreak an iPhone and try to circumvent the SSL cert checks at the OS level. Gives me something to do today
Yup. The tip to try fiddler is what I did and was able to get it working.
Once I installed fiddler and the certcreator addon I then added a cert to the iphone, setup a proxy on the wifi and activated and setup fiddler to accept external connections.
After all that, I could see all of the Wyze API calls back and forth, their data and responses. It was pretty easy from there. Quickly threw together an app to turn the cameras on/off like a switch and thats all I was looking to do.
But now that I know how to do this, its just another tool in my toolbox.
Well doing what I said with jailbreaking got me a lot closer. I can now tell that the app actually communicates via a TLS encrypted MQTT socket. I'm not yet familiar enough with MQTT to figure out how to MITM it
Ok I figured it out! I wanted to share in case this info is useful for anyone else doing any reverse engineering.
After jailbreaking my iPhone all I learned is that the device was sending stuff using TLS encrypted MQTT. Well that's not super helpful since I can't see what topics it's publishing to! So next thing I did was setup a TLS encrypted Mosquitto MQTT server on a Linux PC. I also ran bind on this PC so I could spoof DNS. I set my iPhone to use that PC as its DNS server. I then used SSL Kill Switch 2 (a Cydia Tweak that disables SSL cert validation on an iPhone) so that I could redirect all the MQTT messages to my PC. I then used mosquitto_sub to subscribe to #. This way when my phone published something, I could see the payload.
So at that point I learned the MQTT messages being sent. That was nice and all but @chuck.schwer confirmed for me that Hubitat does NOT support TLS encrypted MQTT (currently... maybe some day!). Turns out the app I'm using uses the Azure IoT Hub which also allows you to send the MQTT messages as HTTPS messages to a REST api endpoint. So basically I could post the same MQTT message just using httpPost.
Between this and having to figure out how to reverse engineer the MS B2C AD OAuth protocol made this the most complicated integration I've ever written. But I learned some new stuff. If anyone else out there has a Kohler DTV+ with Konnect, we can now control the lights (and soon volume!). Anyone interested (in case there are other integrations that rely on Azure IoT Hub, the same basic principles should apply GitHub - dcmeglio/hubitat-kohlerdtv at konnect-control)
Great stuff. I could have mentioned this was what you needed because I hear about it when watching security related videos from time to time when the dev is an iPhoner.
A couple of more things came to mind as I was reading the last posts...
Most "security experts" use mitmproxy instead of fiddler. Fiddler is just so effing easy. As long as you aren't really trying to attack an API where you need to modify requests on the fly I think it's great. If you want to change requests then mitmproxy is supposedly better for that though I've never actually tried to use it. I'm always criticized by my security buddy because I have such an infatuation with Fiddler but I don't care. It has never not done what I needed it to do.
If you are trying to view non-HTTP/S traffic these methods sort of break down as dman2306 pointed out with the MQTT client. He outlined a great method for that. Fiddler does websocket traffic but I don't think it does UDP streams or broadcasts, SSDP, MDNS (or DNS really at all), etc. as far as I can tell. If it does I have never set it up for that. If I have to understand UDP broadcasts or streams I go back to wireshark for that.
If you have decompiled an Android app and it is heavily obfuscated try an older version of the app from apkpure or a similar site. For the most part the companies with just one app... amost none of them included obfuscation in their first versions. It often comes later as an afterthought. But by then it's too late because the protocol is the same in the apps before obfuscation and after.
You don't always have to have an Android device if the app was compiled for x86 and ARM. You can easily get an Android emulator running and rooted in a VM/emulator running on a PC.
Any luck with this? I am trying to get the Wyze vacuum API’s decoded and it doesn’t appear they are using pinned certain (meaning Charles proxy works just fine). Perhaps it’s related to me having a beta app?
