Xposed is the reason I am never getting anything but an unlockable Android phone.
Reverse-engineering the Starbucks ordering API
11–20 of 157 posts
Re: Reverse-engineering the Starbucks ordering API
#12Opening 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 =(
"2,147,483,647 large coffees? I'd better get to work." - some poor Starbucks employee
Re: Reverse-engineering the Starbucks ordering API
#13If there was a IoT button in my kitchen that could order my usual morning order, well I'm not sure. I may or not shout out in joy.
Looks like someone already did: https://www.ryanpickren.com/starbucks-button
Awesome read. Just enough info given to attempt yourself, without giving it away.
Re: Reverse-engineering the Starbucks ordering API
#14Is there a good guide out there on reverse engineering mobile apps for iOS & Android?
https://www.nccgroup.trust/us/about-us/newsroom-and-events/b... is a good start. You can do some fun stuff once you can see/proxy/modify requests.
If you want to get started, start by poking at something simple (e.g. your own app). Then google as you run into specific issues.
Re: Reverse-engineering the Starbucks ordering API
#15Solid 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…
True say, did a similar thing here that might messily fill in some of those blanks on at least one set of tool options:
https://gist.github.com/patcon/ee96b9bb0f3141b37146#notes
(but it was definitely easier than in the blog post!)
Re: Reverse-engineering the Starbucks ordering API
#16Opening 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 =(
"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!
Re: Reverse-engineering the Starbucks ordering API
#17If 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 seems to me that you can make an API that is trivially reverse-engineerable and both have your pie and eat it.
But then your users start using the Starbucks ordering Slack channel, cool! But their credit card is hacked. Or the slack channel breaks. Or a stalking ex-boyfriend intercepts the order and delivers the latte himself. Starbucks would likely be blamed for these problems.
Remember the Snapchat leak from a few years ago?[1] I'd bet almost everyone who heard about the leak thought that Snapchat got hacked, and many then thought that their personal photos are not safe on Snapchat. But the reality is different. Users logged into a site called "Snapsave", many probably thinking it was part of Snapchat. It was Snapsave that used the private Snapchat API and got hacked... not Snapchat.
[1] http://www.huffingtonpost.com/2014/10/10/snapchat-leak_n_596...
Re: Reverse-engineering the Starbucks ordering API
#18Solid 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…
Any chances you would be willing to share some of the online resources you use for this? I have recently been getting into mobile security development professionally.
Re: Reverse-engineering the Starbucks ordering API
#19Re: Reverse-engineering the Starbucks ordering API
#20Solid 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…
Could you pontificate a bit on four? Because of the identity problem, or is there something about a mobile app that is fundamentally less secure than say, a web browser? I'm genuinely ignorant, seems like it would be good to know.