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

41–50 of 157 posts

Re: Reverse-engineering the Starbucks ordering API

#41

Post by rconti »

Excellent writeup.

I have to take issue with the "Starbucks app is great" line, though. I think I've had more problems with it (on iOS) than any other app. It's the only app that (for a period of many months if not a year) was regularly unable to find my location. Even if I opened up Maps or some other location enabled app and found my location before launching Starbucks, it would just bomb out.

Overall the app seems to have tons of 'issues'. It's been better the past few months though. And it beats the hell out of standing in a 10 minute line. I honestly wouldn't stop at Starbucks anymore if it wasn't for the app.

Re: Reverse-engineering the Starbucks ordering API

#42

Post by micaksica »

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…

The standard way of frustrating decompilers for Android applications is with heavy obfuscation using ProGuard [1] or DexGuard. [2] IMO, DexGuard is a real pain in the ass to reverse around. If you aren't dealing with heavy obfuscation, decompiling APKs is trivial using jadx. [3]

In general I have found that most smaller app developers don't obfuscate at all, and often you can find hardcoded keys/secrets in these smaller applications.

[1] https://developer.android.com/studio/build/shrink-code.html

[2] https://www.guardsquare.com/en/dexguard

[3] https://github.com/skylot/jadx

Re: Reverse-engineering the Starbucks ordering API

#43

Post by jfolkins »

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…

Here is an old series of mine that steps you through reversing Java.

https://www.acloudtree.com/hacking-java-bytecode-for-program...

Re: Reverse-engineering the Starbucks ordering API

#44

Post by nickplee »

rconti wrote: post #41

Excellent writeup. I have to take issue with the "Starbucks app is great" line, though. I think I've had more problems with it (on iOS) than any other app. It's the only app that (for a period of many months if not a year) was regularly unable to find my location. Even if I opened up Maps or some other location enabled app and found my location before launching Starbucks, it would just bomb out. Overall the app seems…

Strange. I've never had a problem with it.

And yes, it makes the coffee taste better.

Re: Reverse-engineering the Starbucks ordering API

#45

Post by joombaga »

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 didn't have 50x worth of bacon, but it did have more than 3x, maybe 5x-6x. The receipt was hilariously long though.

Re: Reverse-engineering the Starbucks ordering API

#46

Post by shortstuffsushi »

This is super interesting, especially the part about trying to reverse engineer their "security" measure. I did something like this a few months back for Paylocity, a time logging system that has a terrible web interface. After trying to talk with their sales people about them potentially offering an API, I was told "no API, just this mobile app." Turns out the mobile app is just an Ionic app with all of the resources (all, including tests and even test environment logins and stuff) baked in. Super easy to grab their API out of that (literally called /mobileapi/), but then the trouble was figuring out how they generated their security token header, which was also a little dance of timestamps and faked device info.

The best part was when I contacted them afterwards and warned them about the extra pieces of info they had baked in, their response was basically "yeah, we're aware that there's more in there than there should be, but it's not a priority." Oh well, they just have all of my personal information.

Re: Reverse-engineering the Starbucks ordering API

#47

Post by veritas3241 »

rconti wrote: post #41

Excellent writeup. I have to take issue with the "Starbucks app is great" line, though. I think I've had more problems with it (on iOS) than any other app. It's the only app that (for a period of many months if not a year) was regularly unable to find my location. Even if I opened up Maps or some other location enabled app and found my location before launching Starbucks, it would just bomb out. Overall the app seems…

I just wish I could customize the requests on breakfast items. I want no cheese on my sandwich. I can request it in person. Can't on the app.

Re: Reverse-engineering the Starbucks ordering API

#48

Post by shortstuffsushi »

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 alternative is basically things like this, where someone figures it out anyway, and we have to wait and see if they play it cool, or take it badly and make the author take it down.

Re: Reverse-engineering the Starbucks ordering API

#50

Post by _ea1k »

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…

Neither of those limitations apply to modern Java decompilers (eg, Fernfl0wer).
Post reply on HN