Bypassing Bitlocker With A Logic Analzyer

August 25, 2023 by Dave Rowntree 27 Comments

Security Engineer [Guillaume Quéré] spends the day penetration testing systems for their employer and has pointed out and successfully exploited a rather obvious weakness in the BitLocker full volume encryption system, which as the linked article says, allows one to simply sniff the traffic between the discrete TPM chip and CPU via an SPI bus. The way Bitlocker works is to use a private key stored in the TPM chip to encrypt the full volume key that in turn was used to encrypt the volume data. This is all done by low-level device drivers in the Windows kernel and is transparent to the user.

TPM chip pins too small? Just find something else on the bus!

The whole point of BitLocker was to prevent access to data on the secured volume in the event of a physical device theft or loss. Simply pulling the drive and dropping it into a non-secured machine or some other adaptor would not provide any data without the key stored by the TPM. However, since that key must pass as plaintext from the TPM to the CPU during the boot sequence, [Guillaume] shows that it is quite straightforward — with very low-cost tools and free software — to simply locate and sniff out this TPM-to-CPU transaction and decode the datastream and locate the key. Using little more than a cheapo logic analyser hooked up to some conveniently large pins on a nearby flash chip (because the SCK, MISO, and MOSI pins are shared with the TPM) the simple TIS was decoded enough to lock onto the bytes of the TPM frame. This could then be decoded with a TPM stream decoder web app, courtesy of the TPM2-software community group. The command to look for is the TPM_CC.Unseal which is the request from the CPU to the TPM to send over that key we’re interested in. After that just grabbing and decoding the TPM response frame will immediately reveal the goods.

Continue reading “Bypassing Bitlocker With A Logic Analzyer” →

A Fuse Is Just A Fuse, Right?

July 5, 2023 by Al Williams 39 Comments

We like to think that most common electronic components are essentially commodity items. We don´t buy premium wire or resistors. You just assume these electronic components are more or less the same from anywhere unless you need some very special characteristics. What about fuses? We would assume they are all essentially the same, but [Ham Radio A2Z] says he’s throwing away his generic fuses after he found they didn’t work as he would expect.

Of course, name-brand fuses are tested to very specific tests, and you get to see the plots of how the fuses are supposed to melt for Bussmann fuses. Then he takes out a generic assortment of fuses he bought at a hamfest. No Bussmann fuses in that batch!

Comparing the generic fuses with some from Bussmann and Littlefuse, they all work fine to carry current. That isn’t the problem. The problem is when you feed the fuses 20 A and expect them to clear. A 5 A generic fuse carried over 20 A for a very long time, and, as you might expect, it got very hot. We kept waiting for the fuse to blow, but after three minutes, he gave up.

For comparison, a 10 A Bussmann fuse in the same conditions blew almost immediately — about 350 milliseconds. None of the generic fuses blew, and, in fact, the fuse in the video had been subjected to 20 A of over-stress several times already. It seems like it is nearly impossible to blow them at that current level despite it being four times the marked current. Not much of a bargain.

As the video points out, fuses aren’t as much to protect your equipment as much as they are to prevent fires, so don’t forget to include them even on simple projects. Remember the TI 99/4A? The power supply for that vintage computer has an odd little box in the power cable very near the plug. Why? Because they forgot to put a fuse in until the UL reminded them.

Continue reading “A Fuse Is Just A Fuse, Right?” →

Retrotechtacular: A Closer Look At The VT Proximity Fuze

June 9, 2023 by Dan Maloney 17 Comments

Here at Hackaday, our aim is to bring you only the freshest of hacks, which carries the burden of being Johnny-on-the-spot with our source material. So if something of obvious interest to our readers goes viral, we might just choose to skip covering it ourselves, figuring you all have probably seen it already. But, if we can dig a little deeper and bring extra value over and above what the viral content provides — well then that’s another story.

That’s pretty much the story behind the excellent video recently released by [Real Engineering] about “The Secret Weapon That Changed World War 2.” It concerns the VT series of proximity fuzes — it’s a legitimate alternate spelling of “fuse” if a somewhat archaic one — that were used for artillery shells and spin-stabilized rockets in World War II. The video gives an excellent overview of the development of the VT, which was used primarily in anti-aircraft artillery (AAA). The details about the development of the American VT fuze are excellent, although curiously there’s no mention that British experiments with a radio proximity fuze were part of the goldmine of information brought to America at great risk by the Tizard mission in 1940. While there has been plenty of contention about the exact role the British work played, it’s fair to say that it at least informed the development and fielding of the American VT fuze.

Continue reading “Retrotechtacular: A Closer Look At The VT Proximity Fuze” →

Linux Fu: Fusing Hackaday

February 16, 2022 by Al Williams 9 Comments

Unix and, by extension, Linux, has a mantra to make everything possible look like a file. Files, of course, look like files. But also devices, network sockets, and even system information show up as things that appear to be files. There are plenty of advantages to doing that since you can use all the nice tools like grep and find to work with files. However, making your own programs expose a filesystem can be hard. Filesystem code traditionally works at the kernel module level, where mistakes can wipe out lots of things and debugging is difficult. However, there is FUSE — the file system in user space library — that allows you to write more or less ordinary code and expose anything you want as a file system. You’ve probably seen FUSE used to mount, say, remote drives via ssh or Dropbox. We’ve even looked at FUSE before, even for Windows.

What’s missing, naturally, is the Hackaday RSS feed, mountable as a normal file. And that’s what we’re building today.

Writing a FUSE filesystem isn’t that hard, but there are a lot of tedious jobs. You essentially have to provide callbacks that FUSE uses to do things when the operating system asks for them. Open a file, read a file, list a directory, etc. The problem is that for some simple projects, you don’t care about half of these things, but you still have to provide them.

Luckily, there are libraries that can make it a lot easier. I’m going to show you a simple C++ program that can mount your favorite RSS feed (assuming your favorite one is Hackaday, of course) as a file system. Granted, that’s not amazing, but it is kind of neat to be able to grep through the front page stories from the command line or view the last few articles using Dolphin. Continue reading “Linux Fu: Fusing Hackaday” →

Linux Fu: User Space File Systems — Now For Windows, Too!

August 31, 2021 by Al Williams 15 Comments

One of the nice things about the Unix philosophy that Linux inherited is that the filesystem is very modular. That’s good, too, because a typical system might want a choice of filesystems like ext4, reiserfs, btrfs, and even network systems like nfs. Besides that, there are fake file systems like /sys and /dev that help Linux make everything look like a file. The downside is that building a filesystem required changing the kernel or, at least, writing a loadable module. That’s not as hard as it sounds, but it is a little more difficult than writing a normal program. Then came FUSE — file system in user space. This is a single file system module that allows you to create new file systems by writing ordinary code.

Continue reading “Linux Fu: User Space File Systems — Now For Windows, Too!” →

Blowing A 5000 A Fuse Takes Some Doing

June 18, 2021 by Lewin Day 37 Comments

Fuses are generally there to stop excessive electrical currents from damaging equipment or people’s soft, fleshy bodies when faults occur. However, some people like to blow them just for fun, and [Photonicinduction] is just one of those people. He recently decided to push the boat out, setting his mind to the task of popping a 5000 A fuse in his own back yard. (Video, embedded below.)

The fuse looks quite haggard after the event

It’s not a job for the faint-hearted. The fuse is rated at 5,000 A — that’s the nominal rating for the currents at which it is intended to operate. Based on the datasheet, the part in question is capable of withstanding 30,000 A for up to five full seconds. To pop the fuse instantly takes something in the realm of 200,000 A.

To achieve this mighty current, a capacitor bank was built to dump a huge amount of energy through the fuse. Built out of ten individual capacitor units wired up in parallel, the total bank comes in at 10,000 μF, and is capable of delivering 200,000 A at 3000 V. (Just not for very long.) The bank was switched into circuit with the fuse via a pneumatic switch rated at just 12,000 A.

The results are ferocious, with both the fuse and switch contacts blasting out hot metal and flashes of light when the power is dumped. It’s a heck of a display. We’ve featured big capacitor banks before too, though they pale in comparison to what we’ve seen here today.

Continue reading “Blowing A 5000 A Fuse Takes Some Doing” →

Linux Fu: Send In The (Cloud) Clones

November 10, 2020 by Al Williams 17 Comments

Storing data “in the cloud” — even if it is your own server — is all the rage. But many cloud solutions require you to access your files in a clumsy way using a web browser. One day, operating systems will incorporate generic cloud storage just like any other file system. But by using two tools, rclone and sshfs, you can nearly accomplish this today with a little one-time setup. There are a few limitations, but, generally, it works quite well.

It is a story as old as computing. There’s something new. Using it is exotic and requires special techniques. Then it becomes just another part of the operating system. If you go back far enough, programmers had to pull specific records from mass storage like tapes, drums, or disks and deblock data. Now you just open a file or a database. Cameras, printers, audio, and even networking once were special devices that are now commonplace. If you use Windows, for example, OneDrive is well-supported. But if you use another service, you may or may not have an easy option to just access your files as a first-class file system.

The rclone program is the Swiss Army knife of cloud storage services. Despite its name, it doesn’t have to synchronize a local file store to a remote service, although it can do that. The program works with a dizzying array of cloud storage providers and it can do simple operations like listing and copying files. It can also synchronize, as you’d expect. However, it also has an experimental FUSE filesystem that lets you mount a remote service — with varying degrees of success.

What’s Supported?

If you don’t like using someone like Google or Amazon, you can host your own cloud. In that case, you can probably use sshfs to mount a file using ssh, although rclone can also do that. There are also cloud services you can self-host like OwnCloud and NextCloud. A Raspberry Pi running Docker can easily stand up one of these in a few minutes and rclone can handle these, too.

Continue reading “Linux Fu: Send In The (Cloud) Clones” →