The security measures are not there to secure you from seeing the requests, they are there to stop people using the app getting hacked with man in the middle attacks, no? I think they know they need to also make sure their API is secure as well.

I understand what you mean, but an attacker wouldn't be able to decrypt during a MiTM attack since SSL is being used -- regardless of cert pinning. An effect of pinning is losing the ability to perform a self MiTM to decrypt traffic; this post simply demonstrates bypassing that.

> but I’m not quite sure of the reasoning behind the root checking process

I'm surprised the author didn't pick up on the class/package names: a quick Googling of "Paydiant" shows that this is likely all a result of a third-party loyalty/payment integration they've used: http://www.paydiant.com/

I was pretty sure of the 3rd party integration, but still am not sure why they're checking if the user's device is rooted. I suppose for payment processing, they consider it a security risk?

In the reddit thread the article links to it mentions people spoofing gps to fake checking in at places to get loyalty points. So even if Subway doesn't have something like that it might be that the 3rd party does and they are trying to prevent people from faking checkins?

That doesn't require root though, just enable fake locations in dev settings and use an app for it

Would proguard be able to prevent (or at least make much more difficult) this kind of reverse engineering?

what is a good dalvic decompiler at the moment? are you using smali/baksmali for re-compilation?

The endpoints look a lot nicer than what the UK app uses (which is just some Java enterprise thing)