[lelanthran]

> Yeah, I did think of that. I've never played with one of those so I don't really have much of an imagination about what they could do with a cracked one.

I've got a couple on my desk right now; there's nothing I can do with them to steal money, even though they're in dev-mode.

[literalAardvark]

Someone in a parent post mentioned that you could change the merchant entirely, thus syphoning off the money to a potentially more accessible account.

[lelanthran]

> Someone in a parent post mentioned that you could change the merchant entirely, thus syphoning off the money to a potentially more accessible account.

That would be something I'd like to see. The terminals I have worked on do not store merchant details. A merchant ID is stored on the terminal, with the ID mapping to an actual merchant account on the backend.

In order to have the merchant account on the backend, you need to be a customer of that terminal supplier. If you are a customer, they know:

a) Where your terminals are deployed

b) Your real details

c) The terminal's ID and the terminal's serial that maps to that specific merchant ID.

So, let's say we do change the merchant ID from `12` to `24` on the terminal. The request goes up with `transaction(<amt>, 24, 'sr-12345')`, and then the backend rejects because terminal sr-12345 is not mapped to merchant 24.

Lets say we also manage to fake the serial number. Then the transaction is approved, but can be easily reversed because merchant 24 is a customer and we have:

1. Their bank account number 2. Their physical address 3. The company registration number 4. Verified ID copies of the owner, directors, managers, etc. 5. Their money (from their transactions).

So, yeah, I'd love to know more about how they execute this hack; it would require complicity on the backend to a large degree.

3.

[literalAardvark]

Yeah, ideally you'd need a valid merchant id, pos id and a way to siphon from the other merchant.

Probably not worth the small amounts you could make before caught