[deleted]
Reverse-engineering the Starbucks ordering API
121–130 of 157 posts
Re: Reverse-engineering the Starbucks ordering API
#122Earlier quoted context omitted.
I am also doing a lot of reverse enginering work for fun and profit. I agree with most parts, except android. While reversing Android apps, usually they are obfuscated ( I think it is included in the standard build process ), but when you are start to be familier with objective C (or swift) binaries there are really straight forward, with a nice disassembler and script, in my experience much faster. Request signing,…
On iOS you have to go through the extra step of getting the binary onto a jail broken phone to strip the drm in order to re-sign it. Once you've got a way tamper with the binary and run it, most platforms are pretty straightforward to work with - it's really just down to which byte code or assembler variants you're most comfortable working with. Obfuscated code isn't a barrier. Obfuscated control flow is more irritat…
yeah but this step is usually done for you, you can always google ‘appname’ ipa and reach latest version’s IPA.
Obfuscated control flow is like hell especially in c++ (ex: pokemon etc) but as I said I am comparing average android vs IOS. Once you have rooted platform you have much wider tool set of course.
Re: Reverse-engineering the Starbucks ordering API
#123Earlier quoted context omitted.
I tried doing 2 recently, found the file with CertificatePinning in the name, found the part returning 1 and 0 based on whether the check passed and patched it to return 1 in both cases. It still didn't work and after a few hours, I gave up, grepped through the decompiled files for the website name, got an endpoint which turned out to work perfectly in a web browser and which led me to the ultimate endpoint I needed.…
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 spee…
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?
Re: Reverse-engineering the Starbucks ordering API
#124I did this with the Papa John's webapp a while back (which was waaaay simpler btw). They limited duplicate toppings to (I think) 3 of the same, but "duplicate_item" was just a numerical property on the (e.g.) "bacon" object. Turns out you could just add multiple "bacon" members to the toppings array to exceed the limit, and they didn't charge for duplicates, so I ordered a pizza with like 50 bacons. It definitely did…
Whenever you do this sort of thing, you should check whether they do negative number checking on the client side or in the API itself. You might be able to get 1 pizza with bacon and (1) pizza without, all for the price of the bacon.
No pizza, half -1 bacon?
Re: Reverse-engineering the Starbucks ordering API
#125The way to solve this is just for companies to give out their API in a public manner. You'll almost never be able to secure it from scrapers.
We experienced this at Honeywell, when I first started here we were blocking users that scraped the app instead of giving them public access and teach them how to use it correctly.
Re: Reverse-engineering the Starbucks ordering API
#126Opening up an API like this is ripe for abuse, so taking care makes sense. Bad actors translate directly to lost money. A real method of securing APIs would be a godsend, but in current tech it's just not possible. This is the one place where mediocre security-by-obscurity is your only choice =(
You can get pretty far with a secure element. Server challenges with signed payload of nonce + current timestamp, and client verifies it and then re-signs the payload. For something like a third-party coffee-ordering app, the economics of the usual attacks don't scale (either physically tearing apart the chip or exploiting a vulnerability in the first-party app).
Re: Reverse-engineering the Starbucks ordering API
#127I've always wondered the legality of doing things like this. Have there been cases where someone was taken to court (in the US) for reversing an API from a mobile app or website? Assuming no malicious action or intent of course. Could the CFAA be used in this case, even if the intent was just to understand the API for personal use?
With so many IoT devices out there relying on 3rd party web services that may or may not be around a year from now, I expect that the right to inspect and understand these APIs will become more and more important. Not to mention wanting the ability to build interactions between devices where the manufacturer may not have interest (IFTTT, etc).
Re: Reverse-engineering the Starbucks ordering API
#128Earlier quoted context omitted.
Yeah that's what I figured. The wording of the post made it sound like it had something to do with the bacon though. You could just do this for any arbitrary pizza.
The bacon is there so you pay something , a free pizza would be weird even to a minimal wage employee (not that they're dumb, but they probably don't care).
Though that's assuming the people making online orders even bother looking at the amount paid. I don't necessarily see why they would (or why they wouldn't assume you had merely cashed in some sort of promo or balance).
Re: Reverse-engineering the Starbucks ordering API
#129Opening up an API like this is ripe for abuse, so taking care makes sense. Bad actors translate directly to lost money. A real method of securing APIs would be a godsend, but in current tech it's just not possible. This is the one place where mediocre security-by-obscurity is your only choice =(
What abuse would it be ripe for exactly? I assume the only thing they were trying to prevent is third party apps.
Say a third party app orders the wrong coffee, or orders too much stuff, etc. There's a real business risk because they have to shell out physical capital to make coffee.
I might be slightly off because thinking about it the app probably requires up-front payment. But either way, fully open APIs can cause problems if they're more meant for internal processes
Re: Reverse-engineering the Starbucks ordering API
#130Earlier quoted context omitted.
Whenever you do this sort of thing, you should check whether they do negative number checking on the client side or in the API itself. You might be able to get 1 pizza with bacon and (1) pizza without, all for the price of the bacon.
I work for a company with a similar sort of online ordering API, and a while back some enterprising person discovered that: 1. Our API had a hidden "tip" feature; we hadn't exposed it in the storefront yet, mostly because the developer in charge of it had left with it halfway finished, and nobody had picked it back up yet 2. But the API itself was perfectly functional. If you manually submitted an order to the API wi…
I wonder what would happen if you order $40 worth of pizza and stated a -$41 tip! paid to eat pizza, hurray!