fail0verflow is a console hacking group that writes up exploits and reverse engineering of the PS4, Nintendo Switch, and Chromecast.
HN commenters link its Chromecast root writeup and DCPU-16 review, and note the team's earlier Wii hacking and the death of Ben Byer.
Assuming that the web service is doing proper client side authentication most of the time (which, with enough effort, can be verified), and then gets coerced into sending compromised JS at some point in the future - we still have better security than the alternative of no client side security at all. Sure the increased chance of a malicious update is a real threat, but it is better than that attack not needing to be performed at all.
A further incremental improvement could be made using a Mega-style root of trust (ironically, an article explaining how they messed up the implementation explains it best: http://fail0verflow.com/blog/2013/megafail.html). Only the initial loader page (with embedded hashes and MACs) needs to be checked for whether or not it has changed on each page load. If you want to be immune from a later malicious update, you just have to manually save the loader page and open it instead of re-requesting it from the Mega. Yes, during an update they can stop serving the old scripts and deny access, but you will at least always know when an update has occurred.
It's obviously a crypto challenge to anyone who has ever played them. It maps way too nicely to human concepts. This is what every amateur putting together an "alien challenge" without attempting to be scientific about it ends up doing, and it's easy to tell. That's fine if you're doing it for fun, but it's obviously not real.
And that is confirmed:
https://www.popularmechanics.com/space/a19257/nsa-key-to-extraterrestrial-messages/
I've been here solved that. ACM tried to run an challenge about an "alien computer" that was obviously not alien, but ended up being very real. I was part of the team that reverse engineered it first, but the whole contest collapsed and all interest waned after we ended up finding the very-much-not-alien chip involved by accident. We did cover the initial process, but unfortunately never got around to writing the follow-up posts.
https://fail0verflow.com/blog/2012/unprogramming-intro/
https://web.archive.org/web/20160304030848/http://queue.acm.org/unprogramming.cfm
> every bit of media that is “exclusive” to DRM-encumbered formats shows up, every single time, unlocked on file-sharing networks and torrent sites.
Incorrect. PC games, software, console games - many of these have not and likely will not be cracked. That's not to say there aren't many out there but if you have paid attention to information dripping out of cracking groups, you'll see it's becoming much more difficult to get around DRM.
Similarly, Cinavia works. RTMPE works.
It doesn't mean they should be there. It doesn't mean that adding the DRM doesn't cause annoyances to legitimate consumers. But that blanket statement that whatever DRM you add is ineffective is simply wrong.
Edit: quick example - ps4 released Nov 2013. Can you play pirated games on it? Nope. You can install linux but it's likely a number of years before piracy can happen.
https://fail0verflow.com/blog/2015/console-hacking-2015-liner-notes.html
> it is, after all, a popular hobby of children who have nothing but time on their hands and access to the Internet. You certainly don’t need to buy hardware or have access to special training to get started.
yup, that's how I learned all of this!
> And, to be clear, I do think the current situation of closed systems is not great,
Agreed!
> and I do think that we do have a lot of engineers who grew up on open systems that they could tinker on going on to design things like iPhone for their children to use.
These days there are also more open system like, say, the Raspberry Pi. Back in my day (oh god, I'm growing old!) we had to first exploit video game consoles to get something comparable :-)
We made a slightly related argument when we didn't really feel like driving the WiiU homebrew scene almost 8 years ago (stop making me feel old!) [1]
[1] https://fail0verflow.com/blog/2013/espresso/
The coupling of a cryptoprocessor[1] to avoid network packets and circuitry tampering with a locked kernel could stop people to use cheats. The CPU would only execute a signed kernel[2] while the kernel would only load signed modules. Today, each gaming studios/publishers are working on their own anticheat solution in their corner. Here, the anticheat would be the platform itself, you would only have to focus on keeping the kernel secure to turn all games cheats free (in theory). video game consoles are going this route with varying degrees of success[3]
[1] https://en.wikipedia.org/wiki/Secure_cryptoprocessor
[2] https://en.wikipedia.org/wiki/Code_signing
[3] https://en.wikipedia.org/wiki/PlayStation_Portable_homebrew
https://en.wikipedia.org/wiki/PlayStation_3_homebrew
https://fail0verflow.com/blog/2014/console-hacking-2013-omake/
The top-level Verilog module and Vivado .xdc file (contains pin mappings, timing constraints, etc) from Gidel for the HawkEye 20G-48. [0] No SDK from Gidel though.
My back burner project for them is to create a PCIe TLP sniffer/MiTM/device emulator by hooking up two together via 10 GbE for relaying TLPs with one of the remaining 10 GbE connection going to a host PC for the sniffed/injected TLPs. The Aria 10 FPGA PCIe hard IP allows for either root or endpoint mode so I “just” need to draw the rest of the owl, avoiding any Quartus IP modules that would make the setup non-transparent.
I’m not sure what using a 10 Gbit link for PCIe will be like with faster devices but fail0verflow got away with TLP proxying with 115200 baud UART. [1]
[0]: https://www.ebay.com/itm/335904285904 [1]: https://fail0verflow.com/media/33c3-slides/#/11