Show me the Data: Hackaday.io Year #01

Today marks exactly one year since we announced to the world the first product from our software lab – Hackaday.io. In what has been an incredibly exciting year for all of us, we evolved from a simple idea and a prototype to a truly massive community that’s making its mark on the world. Day after day, carefully listening to the invaluable feedback from our users, we have improved and moved forward, one line of code at the time.

We still have a long way to go, but we’ll pause for a second now and reflect on how far we’ve come. Then get right back to fixing bugs and developing new features.

It all started with a simple idea – building a better project hosting website. Though there are project and content websites galore out there, with new ones popping up every day, it all still felt too bland. We thought we could do better. After all, the medium is the message. The place where something lives sooner or later becomes a key part of its identity. So in order to prevent a dystopian future in which we’re all hosting our projects using the (fictional) Microsoft Maker Suite 2020 and simply don’t care, we started to work on providing an alternative.

We quickly realized that we had a much bigger mission on our hands. Sure, a better project hosting website would be nice, but what we felt we really needed was something [Brian Benchoff] has been talking about for quite some time – a “virtual hackerspace.” Not just a place where you can post your builds once you’re done (and hope someone sees it), but a living, breathing community: a place where you can start with an idea and get feedback as it develops, find collaborators, iterate, and ultimately end up building something way more amazing than you would have accomplished on your own.

This has been the aim of Hackaday for many years, but most of the collaboration was constrained to the limited space of post comment threads and biased by the editorial choice of articles and topics. With the introduction of Hackaday.io, we open up a space for anyone to unleash their creativity and expertise, and together, change the way people build things.

The Data

Unfortunately, making bold claims about how we’re out there changing the world is pretty much a commodity these days. As most Web startups can testify, it doesn’t take more than a simple landing page with nice photography and some uplifting message for any arbitrary claims to appear credible.

So instead of trying to convince you with words about how awesome the last year had been, we’ll just stick with the data.

Continue reading “Show me the Data: Hackaday.io Year #01″

Investigating the strength of the 4-digit PIN

If we wanted to take a look at the statistics behind 4-digit pin numbers how could we do such a thing? After all, it’s not like people are just going to tell you the code they like to use. It turns out the databases of leaked passwords that have been floating around the Internet are the perfect source for a little study like this one. One such source was filtered for passwords that were exactly four digits long and contained only numbers. The result was a set of 3.4 million PIN numbers which were analysed for statistical patterns.

As the cliché movie joke tells us, 1234 is by far the most commonly used PIN to tune of 10% (*facepalm*). That’s followed relatively closely by 1111. But if plain old frequency were as deep as this look went it would make for boring reading. You’ll want to keep going with this article, which then looks into issues like ease of entry; 2580 is straight down the center of a telephone keypad. Dates are also very common, which greatly limits what the first and last pair of the PIN combination might be.

We’ll leave you with this nugget: Over 25% of all PINs are made of just 20 different number (at least from this data set).

[Thanks Awjlogan]

Manual protocol analysis

packetfu

As a followup to last week’s post on automated protocol analysis, [Tod Beardsley] has written up how to start analyzing a protocol manually. He walks through several examples to show how to pull out the interesting bits in binary protocols. His first step was sending 10 identical select statements and capturing the outbound packets. He used the Ruby library PacketFu to help with the identification. It compared the ten packets and highlighted one byte that was incrementing by four with each packet, probably a counter. Looking at the response indicated a few other bytes that were also incrementing at the same rate, but at different values. Running the same query on two different days turned up what could be a timestamp. Using two different queries helped identify which byte was responsible for the statement length. While you may not find yourself buried in HEX on a daily basis, the post provides good coverage of how to think critically about it.

LED battery level indicator

[Kc7fys] came up with a this simple battery level indicator. It uses a single LED to display a battery’s voltage; if the voltage exceeds 12V, it glows green. If it is below 11V, the LED glows red. Anything in between generates an orange glow. The meter is built around an LM358 chip per this schematic, but his actual build looks pretty sloppy because of the dead-bug assembly (check out NASA’s pretty version). Nonetheless, it works, so clean it up and build one if you want to put it (or your batteries) to the test.