Can somebody explain what the use/fun of this is, if Starbucks can push an update that invalidates the approach anytime they want?
Reverse-engineering the Starbucks ordering API
111–120 of 157 posts
Re: Reverse-engineering the Starbucks ordering API
#112Solid 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…
One can easily reverse inner classes. They have a unique naming pattern that tells you exactly where they live: OuterClass$InnerClass. Anonymous inner classes just get numbers instead of names after the $, so you can even tell normal inner classes from anonymous ones and decompile them appropriately.
As for nested try-catch... I don't see how that would be an issue unless the compiler somehow merges them into a single block. Which, as long as it's semantically equivalent, doesn't matter at all.
Re: Reverse-engineering the Starbucks ordering API
#113If 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 data mine users as much.
You can't easily advertise specials or high margin items.
Not that i think those are legitimate, but if a 3rd party app became popular and easily accessible, the company would lose the control over their perception.
Re: Reverse-engineering the Starbucks ordering API
#114Solid 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 am also doing a lot of reverse enginering work for fun and profit. I agree with most parts, except android.
While reversing Android apps, usually they are obfuscated ( I think it is included in the standard build process ), but when you are start to be familier with objective C (or swift) binaries there are really straight forward, with a nice disassembler and script, in my experience much faster.
Request signing, certificate pinning etc are not actually target at reverse engineers, more like to snoopers, replay attackers etc.
Also I agree with 4 totally, there is no point there, you should do your security on server side, instead of client side. (Except games I guess, which they can ban players etc, making it a cat and mouse game there can work pretty good actually)
Much harder targets, like obfuscated c++, or VMs (bytecode interpreters etc) usually helps with #4, but still then, it just slows down. (This slow down combined with regular changes in protection is basically targeted to make reverse engineers to give up)
Re: Reverse-engineering the Starbucks ordering API
#115Solid 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 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 speed up process.
Re: Reverse-engineering the Starbucks ordering API
#116Earlier 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…
I don't know certificate formats and I imagine it would require conversion between hex and something - maybe you can write a blog post with an example?
Re: Reverse-engineering the Starbucks ordering API
#117Solid 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.
Actually it is opposite, mobile platform is more secure.
But...
Security depends on ‘sense of security’, when people think platform is more secure, they tend to ignore/skip a lot of parts on security. Developer tend to skip edge cases (such as pizza API in this thread). When they are developing on secure platforms, they tend to skip more.
For example if you are developing for not jailbroken platform, you trust platform DRM (mostly consoles), and skip a lot of parts, you put the certificate pinning, and call it a day. When platform is broken, you are totally exposed.
But when you are developing for web, you are exposed from the beginning, you dont have that sense of security anymore, so you try to fix all edge cases.
Re: Reverse-engineering the Starbucks ordering API
#118Excellent 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 have also had issues, except on Android. Admittedly, I am using a rather old smartphone now, a Note II, which my carrier has only allowed to update to Android 4.4.2.
Whenever I try to order something through the starbucks app, I have to try multiple times because at some point in the ordering process the message, "unfortunately starbucks has stopped," or something like that will pop up and the app will close. Usually no progress is saved. Often it will crash right as it is processing the payment, and when I open it back up I have to go to the order history to check to see if it went through. Usually if I make it that far before it crashes then my order will have been submitted successfully.
I would love to be able to skip the UI and just submit my order an alternate way, but maybe the answer is to just stop being so cheap and to get a new phone.
Re: Reverse-engineering the Starbucks ordering API
#119Solid 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 am also doing a lot of reverse enginering work for fun and profit. I agree with most parts, except android. While reversing Android apps, usually they are obfuscated ( I think it is included in the standard build process ), but when you are start to be familier with objective C (or swift) binaries there are really straight forward, with a nice disassembler and script, in my experience much faster. Request signing,…
On iOS you have to go through the extra step of getting the binary onto a jail broken phone to strip the drm in order to re-sign it. Once you've got a way tamper with the binary and run it, most platforms are pretty straightforward to work with - it's really just down to which byte code or assembler variants you're most comfortable working with. Obfuscated code isn't a barrier. Obfuscated control flow is more irritating, but I don't think the standard Android tools offer that?
Re: Reverse-engineering the Starbucks ordering API
#120Earlier quoted context omitted.
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…
I don't know certificate formats and I imagine it would require conversion between hex and something - maybe you can write a blog post with an example?
I am not blogging but in a free time I will try to write up a small gist.