The crypographic flow that allows payments to work is straight up pub/priv key encryption with one time use tokens. It's not something you can hack. As soon you see the token it's already been used and thrown away. So whatever nonsense about decompiling literally doesn't matter.

▲

jfyi 4 hours ago | parent | next [-]

So your professional opinion is that the attack surface of mobile banking apps is limited to tokenized payments? Honestly, I'd be appalled if tokens were routed through my banking app. There is no reason the local client needs that data.

▲

hparadiz 3 hours ago | parent [-]

My professional opinion is that APKs can be de-compiled regardless and that has nothing to do with tokenized payments themselves which are like you said handled through server-server communications at the payment processor level. Your phone simply sends a one time use token to authorize the transaction.

▲

jfyi 3 hours ago | parent [-]

You were the one that brought up payments though. Nobody else specified. They just said it could be hacked, which you seem to agree with.

▲

hparadiz 3 hours ago | parent [-]

I don't agree that your example makes sense. Don't feel like writing a wall of text. Zero justification for a locked down system.

	▲	jfyi 2 hours ago \| parent [-]
		What exactly was my example? You agreed with me already. Kind of odd to flip around now. > which are like you said handled Also, I corrected your misstatement about payments. They have absolutely nothing to do with decomp, and certainly can't be used to dismiss the entire attack surface of a mobile banking app. Your example is complete nonsense. You are really digging a hole here.

▲

pixard 4 hours ago | parent | prev | next [-]

He said his app is a one time payment. Presumably there isn’t a backend and he relies on App Store purchases. I know, it’s shocking an app could just be an actual application rather than a web view.

▲

skinfaxi 4 hours ago | parent | prev [-]

You can patch out the payment checks if you can decompile it

▲

hparadiz 4 hours ago | parent [-]

The payment doesn't happen on the device. It happens at the VISA/Mastercard/AMEX level. So "the app" should be doing the validation upstream on the server side and simply reporting yes/no to the app. If you hack the yes/no okay but most payments are for physical things IRL so the payment gateway that is not on your phone is gonna be like ??? - in other words it's on the app not to trust a raw true/false signal and instead rely on server side checks. This is all irrelevant. I make regular massive purchases on my linux box where I can read the memory. It doesn't change anything.

	▲	skinfaxi 5 minutes ago \| parent [-]
		Ah I see you are focusing on apps that have some web component that would enable ongoing authorization. I was thinking about apps that offer a trial but you can upgrade with an in-app purchase and there is no ongoing service component.