Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse-engineering the Starbucks ordering API

blog.tendigi.com

Post reply on HN
Print view View original

51–60 of 157 posts

Re: Reverse-engineering the Starbucks ordering API

#51

Post by userbinator »

1690v wrote: post #39
zitterbewegung wrote: post #2

If an open API existed yes there would be more integrations. Of course you would have to hire engineers to perform upkeep. Eventually if the ordering API isn't profitable you get a bunch of sunk costs and have to reassign people. Its not just "make this open" and POOF. Also your access could be revoked by unofficially using the API and or they could just change it at any time.

It also expands the total attack surface of a system, which can lead to security problems. If you read some of the public disclosures from various bug bounty programs, neglected APIs have led to some serious vulnerabilities. "Underprotected APIs" is actually number 10 on the OWASP Top 10 for 2017.

The attack surface is the same whether the API is officially open/documented or not --- if you think that data received through a web API is somehow more trustworthy/less demanding of validation just because you haven't documented it and only release an app which uses it, you are doing it wrong.

Conceptually, it's just a listening server on the public Internet, and will be subject to arbitrary data anyone willing to connect to it can send.

Re: Reverse-engineering the Starbucks ordering API

#53

Post by mintplant »

saghm wrote: post #35
dsacco wrote: post #10

Solid writeup. From someone who does/did a lot of this professionally: 1. Android typically is easier for this kind of work (you don't even need a rooted/jailbroken device, and it's all Java/smali), 2. That said, instead of installing an entire framework like Xposed that hooks the process to bypass certificate pinning, you can usually just decompile the APK and nop out all the function calls in the smali related to c…

> That said, instead of installing an entire framework like Xposed that hooks the process to bypass certificate pinning, you can usually just decompile the APK I remember reading something years back about Java decompiling, and I believe it said that all Java code is decompileable except for inner classes and nested try-catch. Assuming my memory and the source are correct (which might not be the case), why hasn't it…

Modern Java decompilers (fernflower, cfr, procyon) are very flexible in what they can handle. They're best used in combination, though, as they all tend to choke on different things.

Re: Reverse-engineering the Starbucks ordering API

#54

Post by dsacco »

nickplee wrote: post #37
dsacco wrote: post #10

Solid writeup. From someone who does/did a lot of this professionally: 1. Android typically is easier for this kind of work (you don't even need a rooted/jailbroken device, and it's all Java/smali), 2. That said, instead of installing an entire framework like Xposed that hooks the process to bypass certificate pinning, you can usually just decompile the APK and nop out all the function calls in the smali related to c…

Good call on #2. Might have been more difficult in this case though because the Starbucks Android app is obfuscated to hell and back.

Yeah, no worries I understand what you mean. I reversed the Starbucks app myself a few months ago to see if I could find interesting data. There's less low hanging fruit to use for reversing large companies' mobile apps these days.

Re: Reverse-engineering the Starbucks ordering API

#55

Post by nickplee »

joombaga wrote: post #45

I 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…

You are my spirit animal.

Re: Reverse-engineering the Starbucks ordering API

#56

Post by ryandrake »

sigjuice wrote: post #52
Lxr wrote: post #49

What's the motivation for Starbucks to make it this difficult to reverse?

Limit the potential of fraud and abuse?

I'd argue that time spent actually securing it against abuse would yield more actual value than time spent obfuscating, but this is almost a religious argument that has been carrying on since before I was born.

Re: Reverse-engineering the Starbucks ordering API

#58

Post by iakh »

dsacco wrote: post #10

Solid writeup. From someone who does/did a lot of this professionally: 1. Android typically is easier for this kind of work (you don't even need a rooted/jailbroken device, and it's all Java/smali), 2. That said, instead of installing an entire framework like Xposed that hooks the process to bypass certificate pinning, you can usually just decompile the APK and nop out all the function calls in the smali related to c…

I do this occasionally, and recently found our local real estate app that typically hides sales prices in the form of a range actually returns the actual value through their mobile API. For #2, you don't even need to recompile it, by the time you decompile the APK, you can usually just read the endpoints and parameters/data and reimplement in your language of choice.

Re: Reverse-engineering the Starbucks ordering API

#60

Post by BHSPitMonkey »

shortstuffsushi wrote: post #48
zitterbewegung wrote: post #2

If an open API existed yes there would be more integrations. Of course you would have to hire engineers to perform upkeep. Eventually if the ordering API isn't profitable you get a bunch of sunk costs and have to reassign people. Its not just "make this open" and POOF. Also your access could be revoked by unofficially using the API and or they could just change it at any time.

Why would their API need to be anything more than what they offer to their app? Why not something like "hey, you can use our stuff, but you've only got access to the same set of APIs we use in our app, and we may change it as we please. Oh btw, here are the auto-gen'd docs, hope those are enough" That seems like it'd be both developer friendly and no more maintenance than they're already putting into it. The alternat…

You can't make breaking changes to a public API, for starters. Needing to maintain/version APIs you want to deprecate has a nonzero cost.
Post reply on HN