Ask Hackaday: Are Unlockable Features Good For The User?

February 2, 2017 by Mike Szczys 136 Comments

There are numerous examples of hardware which has latent features waiting to be unlocked by software. Most recently, we saw a Casio calculator which has the same features as its bigger sibling hidden within the firmware, only to be exposed by a buffer overflow bug (or the lead from a pencil if you prefer a hardware hack).

More famously, oscilloscopes have been notorious for having crippled features. The Rigol DS1052E was hugely popular on hacker benches because of it’s very approachable price tag. The model shipped with 50 MHz bandwidth but it was discovered that a simple hack turned it into the DS1102E 100 MHz scope. Tektronix has gotten in on this action as well, shipping modules like I2C, CAN, and LIN analyzation on the scope but requiring a hardware key to unlock (these were discovered to have a horribly insecure unlock method). Similar feature barriers are found on Rigol’s new reigning entry-level scope, the DS1054Z, which ships with protocol analyzation modules (among others) that are enabled only for the first 70 hours of scope operation, requiring an additional payment to unlock them. Most scope manufacturers are in on the game, and of course this is not limited to our tools. WiFi routers are another great example of hardware hosting firmware-unlockable features.

So, the question on my mind which I’d like to ask all of the Hackaday community is this: are unlockable features good for us, the people who use these tools? Let’s take a look at some of the background of these practices and then jump into a discussion in the comments.

Continue reading “Ask Hackaday: Are Unlockable Features Good For The User?” →

Fail Of The Week: GitLab Goes Down

February 2, 2017 by Jenny List 57 Comments

Has work been a little stressful this week, are things getting you down? Spare a thought for an unnamed sysadmin at the GitHub-alike startup GitLab, who early yesterday performed a deletion task on a PostgreSQL database in response to some problems they were having in the wake of an attack by spammers. Unfortunately due to a command line error he ran the deletion on one of the databases behind the company’s main service, forcing it to be taken down. By the time the deletion was stopped, only 4.5 Gb of the 300 Gb trove of data remained.

Reading their log of the incident the scale of the disaster unfolds, and we can’t help wincing at the phrase “out of 5 backup/replication techniques deployed none are working reliably or set up in the first place“. In the end they were able to restore most of the data from a staging server, but at the cost of a lost six hours of issues and merge requests. Fortunately for them their git repositories were not affected.

For 707 GitLab users then there has been a small amount of lost data, the entire web service was down for a while, and the incident has gained them more publicity in a day than their marketing department could have achieved in a year. The post-mortem document makes for a fascinating read, and will probably leave more than one reader nervously thinking about the integrity of whichever services they are responsible for. We have to hand it to them for being so open about it all and for admitting a failure of their whole company for its backup failures rather than heaping blame on one employee. In many companies it would all have been swept under the carpet. We suspect that GitLab’s data will be shepherded with much more care henceforth.

We trust an increasing amount of our assets to online providers these days, and this tale highlights some of the hazards inherent in placing absolute trust in them. GitLab had moved from a cloud provider to their own data centre, though whether or not this incident would have been any less harmful wherever it was hosted is up for debate. Perhaps it’s a timely reminder to us all: keep your own backups, and most importantly: test them to ensure they work.

Thanks [Jack Laidlaw] for the tip.

Rack server image: Trique303 [CC BY-SA 4.0], via Wikimedia Commons.

Hack Chat: The Incredible Sprite_tm And The ESP32

February 1, 2017 by Brian Benchoff 19 Comments

This Friday at 5pm PST, [Sprite_tm] will be leading a Hack Chat talking about the ESP32.

[Sprite_tm] should require no introduction, but we’re going to do it anyway. He’s can install Linux on a hard drive. He can play video games on his keyboard. He built the world’s tiniest Game Boy, and gave the greatest talk I’ve ever seen. Right now, [Sprite] is in China working on the guts of the ESP32, the next great WiFi and Bluetooth uberchip.

[Sprite] recently packed his bags and headed over to Espressif, creators of the ESP32. He’s one of the main devs over there, and he’s up to his neck in the varied and weird peripherals contained in this chip. His job includes porting NES emulators to a WiFi-enabled microcontroller. If you want to learn about the latest and greatest microcontroller, this is the guy you want to talk to, and he’s taking all questions.

Note that we usually do these things earlier in the day but this week we start rolling at 5 PM Pacific Friday to help match up with [Sprite’s] timezone. You can figure out when this event will happen with this handy time and date converter.

Here’s How To Take Part:

Buttons to join the project and enter the Hack Chat

Our Hack Chats are live community events on the Hackaday.io Hack Chat group messaging. Log into hackaday.io, visit that page, and look for the ‘Join this Project’ Button. Once you’re part of the project, the button will change to ‘Team Messaging’, which takes you directly to the Hack Chat.

You don’t have to wait until Friday; join whenever you want and you can see what the community is talking about.

And Tindie Too

In addition to [Sprite]’s Hack Chat on Friday, we’re going to have a Tindie Chat in the Tindie Dog Park on Friday at noon, Pacific time. You can figure out when that’ll be in your local time by following this link.

In the Tindie Chat, we’re going to be talking about all the aspects of selling hardware on Tindie. This is a phenomenal community that keeps on growing, and right now there’s some really, really cool hardware being offered up from makers and creators around the world.

Upcoming Hack Chats

We have a few more Hack Chats on the books. On February 10th, we’ll be talking RF with [Jenny List]. Sparkfun will be around for a Hack Chat on February 17th. If stats are your thing, we’ll have a chat on the ins and outs of R in a few weeks.

ENIAC: The Way We Were

January 31, 2017 by Al Williams 33 Comments

When I first got interested in computers, it was all but impossible for an individual to own a computer outright. Even a “small” machine cost a fortune not to mention requiring specialized power, cooling, and maintenance. Then there started to be some rumblings of home computers (like the Mark 8 we recently saw a replica of) and the Altair 8800 burst on the scene. By today’s standards, these are hardly computers. Even an 8-bit Arduino can outperform these old machines.

As much disparity as there is between an Altair 8800 and a modern personal computer, looking even further back is fascinating. The differences between the original computers from the 1940s and anything even remotely “modern” like an Altair or a PC are astounding. If you are interested in that kind of history, you should read a paper entitled “Electronic Computing Circuits of the ENIAC” by [Arthur W. Burks].

These mid-century designers used tubes and were blazing new ground. Part of what makes the ENIAC so different is that it had a different design principle than a modern computer. It was less a general purpose stored-program computer and more of a collection of logic circuits that could be configured to solve problems — sort of a giant vacuum tube FPGA, if you will. It used some internal representations that proved to be suboptimal which also makes it seem strange. The EDSAC — a later device — was closer to what we think of as a computer. Yet the ENIAC was a major step in the direction of a practical digital computer.

Cost and Size

The size of ENIAC is hard to imagine. The device had about 18,000 tubes, 7,000 diodes, 70,000 resistors, 10,000 capacitors, and 6,000 switches. There were ~~5 million hand-soldered joints~~! ([Thomas Haigh] tells us that while this is widely reported, the real number was about 500,000.) Physically, it stood 10 feet tall, 3 feet deep, and 100 feet long. The tube filaments alone required 80 kW of power. Even the cooling system consumed 20 kW. In total, it took 150 kW to run the beast.

The cost of the machine was about $487,000. Almost a half-million dollars in 1946 is plenty. But that’s nearly seven million dollars in today’s money. What was worth that kind of expenditure? The military built firing tables for shell trajectories. From the [Burks] paper:

“A skilled computer with a desk machine can compute a 60-second trajectory in about twenty hours…”

Keep in mind that in 1946, a computer was a person. [Burks] goes on to say that a differential analyzer can do the same job in 15 minutes. ENIAC, on the other hand, could do it in 30 seconds and with a greater precision than the differential analyzer.

Continue reading “ENIAC: The Way We Were” →

Fixing My 4×4: The Battle Of The Bent Valves

January 30, 2017 by Zoe Skyforest 161 Comments

If you know me at all, you know I’m a car guy. I’m pretty green as far as hardcore wrenching skills go, but I like to tackle problems with my vehicles myself – I like to learn by doing. What follows is the story of how I learned a few hard lessons when my faithful ride died slowly and painfully in my arms over the final months of 2016.

For context, my beast of a machine was a 1992 Daihatsu Feroza. It’s a 4WD with a 1.6 litre fuel injected four-cylinder engine. It had served me faithfully for over a year and was reading around 295,000 kilometers on the odometer. But I was moving house and needed to pull a trailer with all my possessions on an 800 km journey. I didn’t want to put the stress on the car but I didn’t have a whole lot of choice if I wanted to keep my bed and my prized Ricoh photocopier. I did my best to prepare the car, topping up the oil which had gotten perilously low and fitting new tyres. I’d had a hell of a time over the winter aquaplaning all over the place and wasn’t in the mood for a big ugly crash on the highway. Continue reading “Fixing My 4×4: The Battle Of The Bent Valves” →

Retrotechtacular: The Best Pendulum Clock

January 30, 2017 by Elliot Williams 31 Comments

Would you believe a pendulum clock that can keep time accurately to within one second per year? If you answered “yes”, you’ve either never tried to regulate a pendulum clock yourself, or you already know about the Shortt Clock. Getting an electromechanical device to behave so well, ticking accurately to within 0.03 parts per million, is no mean feat, and the Shortt clock was the first timekeeping device that actually behaves more regularly than the Earth itself. Continue reading “Retrotechtacular: The Best Pendulum Clock” →

Hackaday Links: January 29, 2017

January 29, 2017 by Brian Benchoff 27 Comments

A 3D printer and laser cutter were cited as cause in two deaths. A couple (and two cats) were found dead in their apartment this week. The cause of death was carbon monoxide poisoning. Police and the gas company investigated the residence and found no other source of carbon monoxide besides a 3D printer and a laser cutter. Be sure to check out the people who know more about these deaths than the people who actually investigated these deaths in the comments below. In the mean time, get a CO detector. It’s nasty stuff.

At CES ~~last~~ this month, Lulzbot unleashed the MOARstruder. It’s an extruder with a massive, massive, 1.2mm nozzle. [James] from xrobots dot co dot uk just got his hands on the MOARstruder and the initial results are pretty cool. With a 1.2mm nozzle, you can print big parts fast (helpful for [James]’ massive builds), and the parts are stronger. Check out the video for a great hammer vs. printed part test.

We knew this would happen eventually. Pi Blades. Element14 is now offering ‘breakout boards but not quite’ for the full-size Raspberry Pis and Pi HATs. The idea of this product is to package clusters of Pis into an easy-to-use form factor. The Bitscope Blade Quattro, for example, provides power to four Pis. In other news, I own 20% of the world’s supply of vertical SODIMM sockets.

Arbitrary Code Execution On The Nintendo 64. A bit of background is required before going into this. Pokemon Stadium is a game for the N64. It used a Transfer Pak to read the save game data on Pokemon Game Boy cartridges to battle, trade, and organize Pokemon. Additionally, the Pokemon Tower in Pokemon Stadium allows players to play first-gen Game Boy Pokemon games from within an N64 – sort of like the SNES Super Game Boy. By using two Game Boy Pokemon games and two Transfer Paks, arbitrary code can be executed on the N64. Video demo right here. This is really cool, and the next obvious step is a ‘bootloader’ of sorts to allow arbitrary code downloading from controller button presses.

The Travelling Hacker Box is on the move! The original plan for the Travelling Hacker Box was to visit home base for the 2016 Hackaday SuperConference, then depart to foreign lands beginning with Canada, Greenland, Europe, Africa, Asia, Oceana, and the other America. After the SuperCon, the box was shipped out to its first recipient in Canada. The box came back. Something with customs. Now, the Travelling Hacker Box is on the move again. The plan is still the same, it’s just delayed a month or two. If you want to check out the future travels of the Travelling Hacker Box, here you go.

Hackaday

Hackaday Columns

4786 Articles

Ask Hackaday: Are Unlockable Features Good For The User?

Fail Of The Week: GitLab Goes Down