This reminds me of when I was an intern at an InfoSec company 6 years ago. At the time, they were doing some research into mPOS devices (though I wasn't involved).
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!
> 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!
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.)
You're totally right, and I didn't mean to knock it -- they are very different beasts, and the mPOS flappy bird is insanely impressive (it's hardly open hardware!).
I see your 11 byte implementation, and raise you my 6!
That was a good read! Would I be right in saying that given that the PoS is internet connected, you could create a payload that showed a fake pin screen in insecure mode, and just upload the card details and PIN every time someone used it? And deploy that payload simply by inserting the compromised card.
I'm not entirely sure that this would be the case for mPOS devices, as they aren't necessarily directly connected to the internet (many talk to a tablet or mobile phone via bluetooth), so you might need further vulnerabilities in the accompanying app to be able to exfiltrate that way.
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.
> I've always liked the idea of having a card that cause the device to behave as if the transaction had gone through successfully.
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.
I realise that, but perhaps wasn't clear in what I was trying to say.
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.
It really depends on the type of integration used between the terminal and the POS. Sometimes the terminal handles everything and just communicates the status to the POS, in which case your attack would be viable. But it's also possible for the terminal to just package up the info and pass it off to the POS to handle the communication.
Source: I've built a custom integration with Verifone terminals.
I like the data-url version! I found that on iOS safari, a data-URL page could be installed as a PWA (to some extent). I like the idea of shareable installable apps on iOS that don't even have a server to take down... because they're just a shareable URL.
I mean, Flappy Bird was popular in late 2013/early 2014, nearly 7 years ago. If you’re a HN reader and currently aged 16 or 17 years old, you would’ve only been 9 or 10 years old at the height of its popularity. Somewhat reasonable to not know about it at that age, so it is entirely possible that some people on HN might not know about it at all.
If you’re willing to put in effort and storage, flashpoint is a good way to play flash games of yore. It’s a pretty large archive, but there are still one or two games from my childhood I haven’t been able to find (or name, what a distraction that feeling is).
Ha, well, thank you for giving me the benefit of the doubt. But I am 32 and hopeless when it comes to following popular culture. I was probably just focusing my attention on something else. I have a solid track record of not noticing stuff. So the nuance added to xkcd 1053 by this story is that the average value of ten thousand per day is just an average :)
(And another nuance is that I am not in the US and so also not part of the ten thousand per day average.)
Using all the browser functionality feels like cheating. There is a good YouTube video, where a person made a snake game that fits inside a QR Code (albeit a larger version that we're used to, which can hold up to 2953 bytes). You can check it out here: https://www.youtube.com/watch?v=ExwqNreocpg
There are even smaller Flappy Bird implementations (with a maximum of 140 JavaScript characters): here: https://www.dwitter.net/h/FlappyBird
Some are compressed, with the decompressor code included.
Unfortunately they can't be easily compared against each other because Dwitter gives you a (albeit very light) shim for canvas and basic Math functions, which size matters at this scale.
Fun fact I actually got lower than that when I was implementing it in TI-Basic on my school calculator :) It's really amazing how compact code gets on such a simple and pragmatic language
I can't remember what the Twitter-for-tiny-Javascript-demos website is, but this would probably be really cool there if it can be made to work with their logic!
The real cheat is using oversimplified graphics. The game should give an impression of being a flappy bird clone, including resembling it graphically. A good demo is impressive visually.
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