eyyyyy tendigi. hi Jeff! looks like you're doing some cool stuff.
- your old downstairs guy
Reverse-engineering the Starbucks ordering API
31–40 of 157 posts
Re: Reverse-engineering the Starbucks ordering API
#32Solid 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…
It is the same with app keys, you have to gate it behind an intermediary/signing server and implement any impersonation/abuse detection there.
https://casper.io/ is an example of doing this (for SnapChat) - they used to take registrations for their own API. Not sure how it's working out for them these days.
Re: Reverse-engineering the Starbucks ordering API
#33eyyyyy tendigi. hi Jeff! looks like you're doing some cool stuff. - your old downstairs guy
Yo dude!
Re: Reverse-engineering the Starbucks ordering API
#34[deleted]
Re: Reverse-engineering the Starbucks ordering API
#35Solid 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 become standard practice for developers who don't want their app reverse-engineered to just put every class inside a wrapper class? I can imagine there could even be tools for doing this at compile time so that you wouldn't need to manually deal with the indirection when writing the code.
Re: Reverse-engineering the Starbucks ordering API
#36Solid 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…
I mean, Java compiles down to a byte-code, which can be decompiled. If that were a limitation of decompilers at a time, it's likely not now. There's no way to "hide" instructions.
Re: Reverse-engineering the Starbucks ordering API
#37Solid 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.
Re: Reverse-engineering the Starbucks ordering API
#38Earlier quoted context omitted.
"2,147,483,647 large coffees? I'd better get to work." - some poor Starbucks employee
lol. Reminds me of high school. Constructing a green roof garden. We have the genius (see stupid) idea to go order 20 large waters from McDonalds. They just tell us to drive forward and park. Sure enough, not long later, they bring us 20 large waters!
An interaction that cost McDonald's under $2 and is something you won't forget and will actually tell others about. Sounds like they got their money's worth.
Re: Reverse-engineering the Starbucks ordering API
#39If 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.
Re: Reverse-engineering the Starbucks ordering API
#40Solid 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…
[deleted]