Flappy Bird in 228 bytes
gist.github.com
gist.github.com
They found and exploited a stack-based buffer overflow in the EMV parsing of a particular device, which allowed them to deliver a payload from the smart-card itself. To demo this attack, they wrote a flappy bird clone which was played using the number pad of the mPOS device. It weighed in at ~4k though, so positively heavyweight compared to this!
There's more info here: https://labs.f-secure.com/assets/BlogFiles/MWRI-Labs-BHUS14-..., with a video demo here: https://vimeo.com/89924160
MWR have done other work on standard EMV devices which probably ARE connected "directly" to the internet, so the situation you describe may be more likely.
I've always liked the idea of having a card that cause the device to behave as if the transaction had gone through successfully. Sort of like an AMEX Black card, but without the repayments.
Again, I wasn't involved with any of this, so take my comments with a pinch of salt.
Fortunately it's not that easy. Almost all chip card transactions are online only these days, i.e. the issuing bank's host system has the final say on whether a payment goes through or not.
In the UK many businesses manually enter in the amount into the POS device. The customer will then insert their card and enter their pin, the transaction will take place (as you say, ultimately down to the issuing bank), and the device will indicate whether the transaction was successfully or not (printing a receipt as well as an indication on the screen). Some places have tighter integration with tills etc, but to my knowledge it's down to the POS device (which is assumed secure) to communicate the status of the transaction to the till.
My suggestion is that given full control over the POS device (i.e. your card triggers buffer overflow in the POS and you get code execution), you could make it behave as if the transaction had been successfully processed (by showing the same message and issuing the same receipt) without actually debiting any accounts or making any actual transaction.
Source: I've built a custom integration with Verifone terminals.
I wouldn't knock that achievement: this implementation is 228 byte of Javascript and I'm guessing that was 4k bytes of binary that only had access to a less-featureful standard library. You really should add the size of the JS runtime this implementation needs to make the comparison fair. Otherwise, I could blow you all out of the water with my 11 byte implementation:
runFlappy()
(...which runs in FlappyLang, which includes a Flappy Bird implementation in the standard library.)I see your 11 byte implementation, and raise you my 6!
flpy()You control the "bird" (the dot). Click to ascend and fly through the approaching openings.
(And another nuance is that I am not in the US and so also not part of the ten thousand per day average.)
I wouldn’t go this far.
Quite an interesting watch.