Reverse-engineering the Starbucks ordering API

Re:Reverse-engineering the Starbucks ordering API by bluesign on Thursday July 13, 2017 @08:38AM (#14760738)

From my experience, for certificate pinning, fastest option is to search for existing certificate/fingerprint, and try to replace it with charles’/mitmproxie’s

Edit: oh another trick usually works is to change transport to HTTP from HTTPS, just changing endpoint to something you control and changing it to http (with little hex editing the endpoint), and reverse proxy with mitmproxy/charles to the target, you can speed up process.

[ Parent | on HN ]

Re:Reverse-engineering the Starbucks ordering API by merty on Friday July 14, 2017 @05:48AM (#14768654)

For the edit: If the endpoint works on HTTP that is. We no longer allow HTTP connections to our API servers for instance.

[ Parent | on HN ]

Re:Reverse-engineering the Starbucks ordering API by bluesign on Friday July 14, 2017 @04:39PM (#14772984)

Nope you should change endpoint to charles/mitmproxy, then reverse proxy to https endpoint.

So basically for app endpoint will be charles/mitmproxy machine, then from there, you will make https request to real API server

[ Parent | on HN ]

Re:Reverse-engineering the Starbucks ordering API by ikeboy on Thursday July 13, 2017 @08:43AM (#14760765)

I don't know certificate formats and I imagine it would require conversion between hex and something - maybe you can write a blog post with an example?

[ Parent | on HN ]

Re:Reverse-engineering the Starbucks ordering API by bluesign on Thursday July 13, 2017 @08:52AM (#14760813)

I am not blogging but in a free time I will try to write up a small gist.

[ Parent | on HN ]

Re:Reverse-engineering the Starbucks ordering API by ikeboy on Thursday July 13, 2017 @09:02AM (#14760873)

ooh I like the second idea - so since it's an HTTP the cert pinning code won't be triggered at all, and all you need is to grep https to find endpoints and change?

[ Parent | on HN ]