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

141–150 of 157 posts

Re: Reverse-engineering the Starbucks ordering API

#141

Post by shinolajla1 »

coworkerblues wrote: post #135
cwsx wrote: post #72

Earlier quoted context omitted.

Just formally ask the company, if they don't want you to they will tell you. Could be worth including a pitch of sorts ('Hey, Ive noticed a few problems using your site...') but MAKE SURE you don't incriminate yourself. Do NOT show evidence of you 'reverse engineering' anything. Do not do anything without gaining permission, as there's a very good chance you're going to run into their legal team.

I don't want to contact them in a way that they can trace me, since I'm pretty sure that they will try to covert up / threat me (I would hope that someone there already knows this is an issue....).

Starbucks has a bug bounty program, and they do actually pay out. https://www.starbucks.com/whitehat

Re: Reverse-engineering the Starbucks ordering API

#142

Post by mplewis »

coworkerblues wrote: post #136
Rjevski wrote: post #100

Earlier quoted context omitted.

Disclose everything over Tor. The kind of scum that sends credit card data over insecure homebrew crypto deserves no mercy.

I would rather contact them anonymously first, also I don't understand exactly how Tor would help me with this.

Rjevski suggests you publicly disclose the vulnerability in an anonymous way that can't be traced back to you.

Re: Reverse-engineering the Starbucks ordering API

#143

Post by iakh »

Sleeep wrote: post #101
iakh wrote: post #58

Earlier quoted context omitted.

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.

Why would they hide sale prices like that? since it's public information.

It's not public in my state

Re: Reverse-engineering the Starbucks ordering API

#144

Post by lsaferite »

prawks wrote: post #137
IshKebab wrote: post #98

Earlier quoted context omitted.

What abuse would it be ripe for exactly? I assume the only thing they were trying to prevent is third party apps.

One funny (ab)use case that may not be immediately obvious: any public API that accepts payment for goods via credit card will sooner or later attempt to be used by carders to test purchased/stolen card lists for validity.

So? You mitigate this on the server since you can never trust the client.

Re: Reverse-engineering the Starbucks ordering API

#145

Post by Rjevski »

coworkerblues wrote: post #136
Rjevski wrote: post #100

Earlier quoted context omitted.

Disclose everything over Tor. The kind of scum that sends credit card data over insecure homebrew crypto deserves no mercy.

I would rather contact them anonymously first, also I don't understand exactly how Tor would help me with this.

Tor will help you by hiding your identity so they will be in a dead end when they sue and try to find you.

And yes of course you can also use Tor to contact them anonymously before disclosing.

Re: Reverse-engineering the Starbucks ordering API

#146

Post by CodeWriter23 »

sluggg wrote: post #132
CodeWriter23 wrote: post #85

Earlier quoted context omitted.

I'd call that an app fail, taking more time to use the app than writing a list then walking there and back with your complete order.

I would not. Ordering a large group of people drinks from Starbucks is not in any way the primary use case for the application. For it's primary use cases (paying at the store, rewards redemption/collection, ordering yourself drinks ahead) it works perfectly. Additionally, if you think about the feature set that would be required to facilitate bulk orders then you will quickly find that it would be quite large featur…

Of course it's not the primary use case and the app guarantees it never will be. I can say from my experience that sending a gopher to get everyone coffee was a twice daily occurrence at our family business in NYC. Shave 5 minutes off that time and we would go to Starbucks instead of the deli.

Re: Reverse-engineering the Starbucks ordering API

#148

Post by semi-extrinsic »

zilian wrote: post #138
semi-extrinsic wrote: post #90

Earlier quoted context omitted.

I was looking at statistics for prices of sold houses in a European country a few years back, and started digging around in the javascript of a local newspaper that every month listed the local sold properties. Turned out in the API they were using from the central statistics provider, they just had "days=30" and "municipalities=[list]". They weren't even caching it, every user visiting the page was another (identica…

I am really curious which country you're referring to.

Norway.

Re: Reverse-engineering the Starbucks ordering API

#149

Post by merty »

bluesign wrote: post #115
ikeboy wrote: post #108

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

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

Re: Reverse-engineering the Starbucks ordering API

#150

Post by djmips »

micaksica wrote: post #42
saghm wrote: post #35

Earlier quoted context omitted.

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

One reason is they have to test and potentially debug the obsfucated build which is a lot of extra work!
Post reply on HN