The same results can be achieved using only socat and the openssl binary.
While I understand the terminology is popular, I would not call this "reverse-engineering"; to me this is simply viewing your own traffic.
I believe users have a right to see the traffic they (or the apps they use) are sending, and for security reasons alone they should monitor what is being sent. https plus third party CA usage complicates such transparency, making proxying techniques necessary.
I wish more users would view their own traffic.
Keep up the good work.
It would be great if a proxy could be run directly on the mobile device, as then it could be used anywhere along with the apps its monitoring.
As you said HTTPS is a bit of a pain since it's actively designed to resist such "attacks", but as long as there's the option to specify your own CAs it will work. Certificate "unpinning" is still a manual process, however...
People have done this in ways by hacking the built-in VPN system I believe.
Charles Proxy has some easy-to-use pointers .
I haven't tried it but I expect the developer edition does too:
It has a really nice UI for looking at JSON responses such as the Kayak. Sometimes a collapsible tree is invaluable in looking through a response.
The easy filtering and formatting is primarily why I like it so much. Here is how it handles SSL for various ways http://www.charlesproxy.com/documentation/using-charles/ssl-...
Here is a screen shot of my iPhone Kayak app request for comparison http://imgur.com/gvKB6fr
You could easily cost a travel search company thousands of dollars very very quickly using an API they don't want you to use. I don't know if it's illegal or not, but it's certainly immoral.
Take the github approach and let open source devs write innovative apps based on your open API!
How will the API consumer make money? I don't think Ads will generate enough revenue -- especially not on mobile.
Kayak will get some revenue from the bookings resulting from the searches, and would need to circle back some of this revenue back to the API consumer. This is technically complicated because it requires a lot of tracking infrastructure.
In the end, a service that would make sense is a lot more complicated than simply having an endpoint and saying it's X dollars per Y calls.
You can just go to http://mitm.it on the device. It's a 'magic domain' for the proxied host. See http://mitm.it/doc/certinstall/webapp.html
So we don't really need to reach point #2, which raises some 1A issues the first doesn't. (Note I'm excluding DMCA and CFAA issues because Kayak isn't our sue-happy friends at the MPAA or RIAA.)
As a practical matter, though, the author of the linked post, Shubhro Saha, appears to be an undergrad, so is probably judgment-proof and not the most likely target of litigation.
However, I wouldn't consider this any real "reverse-engineering", but just inspecting network traffic --- and it should be absolutely legal to do so when the traffic is generated from an app you legally obtained, running on a device you own.
But likewise, IANAL.
root@kayak:~/kayak-mobile-client# python client.py
Departure airport code: LBG
Destination airport code: HAM
Departure date (MM/DD/YY): 12/26/14
Traceback (most recent call last):
File "client.py", line 56, in <module>
searchid = json.loads(r.text)["searchid"]
Have you set up your UUID and HASH according to the post? You'll actually need to run the app through mitmproxy yourself to get your unique credentials. Then, just drop those into the variables at the top of the script.
I just added some error handling to the script to make this a bit more obvious!
I'm curious, in your case did you consider preventing using your API by third-party clients?
How are UUID and HASH are generated? Are they unique to every installation?