Playing The Pixelflut

August 1, 2020 by Kerry Scharfglass 7 Comments

Every hacker gathering needs as many pixels as its hackers can get their hands on. Get a group together and you’ll be blinded by the amount of light on display. (We propose “a blinkenlights” as the taxonomic name for such a group.) At a large gathering, what better way to show of your elite hacking ability than a “competition” over who can paint an LED canvas the best? Enter Pixelflut, the multiplayer drawing canvas.

Pixelflut has been around since at least 2012, but it came to this author’s attention after editor [Jenny List] noted it in her review of SHA 2017. What was that beguiling display behind the central bar? It turns out it was a display driven by a server running Pixelflut. A Pixelflut server exposes a display which can be drawn on by sending commands over the network in an extremely simple protocol. There are just four ASCII commands supported by every server — essentially get pixel, set pixel, screen size, and help — so implementing either a client or server is a snap, and that’s sort of the point.

While the original implementations appear to be written by [defnull] at the link at the top, in some sense Pixelflut is more of a common protocol than an implementation. In a sense, one “plays” one of a variety of Pixelflut minigames. When there is a display in a shared space the game is who can control the most area by drawing the fastest, either by being clever or by consuming as much bandwidth as possible.

Then there is the game of who can write the fastest more battle-hardened server possible in order to handle all that traffic without collapsing. To give a sense of scale, one installation at 36c3 reported that a truly gargantuan 0.5 petabytes of data were spent at a peak of rate of more than 30 gigabits/second, just painting pixels! That’s bound to bog down all but the most lithe server implementation. (“Flut” is “flood” in German.)

While hacker camps may be on pause for the foreseeable future, writing a performant Pixelflut client or server seems like an excellent way to sharpen one’s skills while we wait for their return. For a video example check out the embed after the break. Have a favorite implementation? Tell us about it in the comments!

Continue reading “Playing The Pixelflut” →

Geocaching On Mars: How Perseverance Will Seal Martian Samples With A Return To Earth In Mind

July 30, 2020 by Dan Maloney 23 Comments

With the roughly 20-day wide launch window for the Mars 2020 mission rapidly approaching, the hype train for the next big mission to the Red Planet is really building up steam. And with good reason — the Mars 2020 mission has been in the works for a better part of a decade, and as we reported earlier this year, the rover it’s delivering to the Martian surface, since dubbed Perseverance, will be among the most complex such devices ever fielded.

“Percy” — come on, that nickname’s a natural — is a mobile laboratory, capable of exploring the Martian surface in search of evidence that life ever found a way there, and to do the groundwork needed if we’re ever to go there ourselves. The nuclear-powered rover bristles with scientific instruments, and assuming it survives the “Seven Minutes of Terror” as well as its fraternal twin Curiosity did in 2012, we should start seeing some amazing results come back.

No prior mission to Mars has been better equipped to answer the essential question: “Are we alone?” But no matter how capable Perseverance is, there’s a limit to how much science can be packed into something that costs millions of dollars a kilogram to get to Mars. And so NASA decided to equip Perseverance with the ability to not only collect geological samples, but to package them up and deposit them on the surface of the planet to await a future mission that will pick them up for a return trip to Earth for further study. It’s bold and forward-thinking, and it’s unlike anything that’s ever been tried before. In a lot of ways, Perseverance’s sample handling system is the rover’s raison d’être, and it’s the subject of this deep dive.

Continue reading “Geocaching On Mars: How Perseverance Will Seal Martian Samples With A Return To Earth In Mind” →

Mining Bitcoin On The ESP32 For Fun, Definitely Not Profit

March 19, 2019 by Lewin Day 7 Comments

Bitcoin’s great, if you sold at the end of 2017. If you’re still holding, your opinion might be a little more sour. The cost to compete in the great hashing race continues to rise while cryptocurrency values remain underwhelming. While getting involved at the top end is prohibitively expensive, you can still have some fun with the basic concepts – as [Jake] did, by calculating Bitcoin hashes on the ESP32.

It’s a project that is very much done for fun, rather than profit. [Jake] notes that even maxing out both cores, it would take 31 billion years to mine one block at current difficulty levels. Regardless, the underlying maths is nothing too crazy. Double-hashing the right data with the SHA256 algorithm is all that’s required, a task that is well within the ESP32’s capabilities. There’s hardware acceleration available, too – though this is weirdly slower than doing it in software.

Overall, you’re not going to get rich hashing Bitcoin on a cheap microcontroller platform. You might just learn something useful, though. If this isn’t weird enough though, you could always try the same thing on a 1970s Xerox Alto.

Looking Forward To SHA2017

July 30, 2017 by Jenny List 17 Comments

We’re at the start of August, which can only mean one thing. Europe’s hackers and makers are about to converge in a field somewhere for a long weekend of sitting around drinking beer and Club-Mate, eating unhealthy street food, being assaulted by some of the most underground chiptune electronic dance music on the planet, sharing the fruits of their labours with their peers, and gazing lovingly upon other people’s hacks. This year it’s the turn of the Netherlands, for over the first full weekend in August that country will host the SHA2017 outdoor hacker camp in a scouting camp on the polders. It promises to be quite an event, with just short of 4000 attendees spread over several fields, arenas, and social areas, and we’re going to be there. Tent and power lead with Schuko plug sorted, massive pile of stickers secured, DECT phone charged, emergency supplies of PG Tips packed.

There is so much to take in at these events that it can sometimes be difficult to catch everything. One can do the rounds as diligently as possible and still miss some of the cool stuff, so this is where you come in. Are you going to SHA? Are you bringing anything you consider cool to the event? Tell us about it in the comments, we’d love to hear about it as would we’re sure the rest of our readers.

Meanwhile, if you think you’ve missed the boat, don’t panic! At the time of writing, there are about 180 tickets still unsold, but they’ll be going fast! Head over to the SHA2017 tickets site to get yours.

(The stripey header, in case you were wondering, is SHA2017’s branding using as you might have guessed, the SHA algorithm to generate HTML colours. What you see are the colours for “Hackaday”.)

SHAttered — SHA-1 Is Broken In

February 23, 2017 by Pedro Umbelino 96 Comments

A team from Google and CWI Amsterdam just announced it: they produced the first SHA-1 hash collision. The attack required over 9,223,372,036,854,775,808 SHA-1 computations, the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations. While this may seem overwhelming, this is a practical attack if you are, lets say, a state-sponsored attacker. Or if you control a large enough botnet. Or if you are just able to spend some serious money on cloud computing. It’s doable. Make no mistake, this is not a brute-force attack, that would take around 12,000,000 single-GPU years to complete.

SHA-1 is a 160bit standard cryptographic hash function that is used for digital signatures and file integrity verification in a wide range of applications, such as digital certificates, PGP/GPG signatures, software updates, backup systems and so forth. It was, a long time ago, proposed as a safe alternative to MD5, known to be faulty since 1996. In 2004 it was shown that MD5 is not collision-resistant and not suitable for applications like SSL certificates or digital signatures. In 2008, a team of researchers demonstrated how to break SSL based on MD5, using 200 Playstations 3.

Early since 2005 theoretical attacks against SHA-1 were known. In 2015 an attack on full SHA-1 was demonstrated (baptized the SHAppening). While this did not directly translate into a collision on the full SHA-1 hash function due to some technical aspects, it undermined the security claims for SHA-1. With this new attack, dubbed SHAttered, the team demonstrated a practical attack on the SHA-1 algorithm, producing two different PDF files with the same checksum.

The full working code will be released in three months, following Google’s vulnerability disclosure policy, and it will allow anyone to create a pair of PDFs that hash to the same SHA-1 sum given two distinct images and some, not yet specified, pre-conditions.

For now, recommendations are to start using SHA-256 or SHA-3 on your software. Chrome browser already warns if a website has SHA-1 certificate, Firefox and the rest of the browsers will surely follow. Meanwhile, as always, tougher times are ahead for legacy systems and IoT like devices.

25C3: Hackers Completely Break SSL Using 200 PS3s

December 30, 2008 by Eliot 78 Comments

A team of security researchers and academics has broken a core piece of internet technology. They made their work public at the 25th Chaos Communication Congress in Berlin today. The team was able to create a rogue certificate authority and use it to issue valid SSL certificates for any site they want. The user would have no indication that their HTTPS connection was being monitored/modified.

Continue reading “25C3: Hackers Completely Break SSL Using 200 PS3s” →

ToorCon 9: Crypto Boot Camp

October 19, 2007 by Eliot 3 Comments

[Rodney Thayer] gave a 2 hour seminar on cryptographic technology. It was designed to give the audience a working knowledge for dealing with vendors. He gave some rules of thumb for choosing encryption. In order of preference, when doing symmetric key crypto: use AES with a minimum 128bit key, if not that 3-key Triple-DES, or last RC4 with 128bit key. For hashing: SHA 256 preferred, SHA 1 if you can’t do any better, and MD5 if you can’t SHA. For public key: RSA using at least a 2048bit key. The top choices in these lists were picked because they’ve stood up to years of scrutiny. One major theme of talk was to never roll your own crypto algorithm or buy someone elses. Proprietary algorithms get broken all the time, like the GSM A5 crypto we talked about earlier this year.