This excellent content from the Hackaday writing crew highlights recurring topics and popular series like Linux-Fu, 3D-Printering, Hackaday Links, This Week in Security, Inputs of Interest, Profiles in Science, Retrotechtacular, Ask Hackaday, Teardowns, Reviews, and many more.
If you have more than one Linux computer, you probably use ssh all the time. It is a great tool, but I’ve always found one thing about it strange. Despite having file transfer capabilities in the form of scp and sftp, there is no way to move a file back or forth between the local and remote hosts without starting a new program on the local machine or logging in from the remote machine back to the local machine.
That last bit is a real problem since you often access a server from behind a firewall or a NAT router with an ephemeral IP address, so it can’t reconnect to you anyway. It would be nice to hit the escape character, select a local or remote file, and teleport it across the interface, all from inside a single ssh session.
I didn’t quite get to that goal, but I did get pretty close. I’ll show you a script that can automatically mount a remote directory on the local machine. You’ll need sshfs on the local machine, but no changes on the remote machine where you may not be able to install software. With a little more work, and if your client has an ssh server running, you can mount a local directory on the remote machine, too. You won’t need to worry about your IP address or port blocking. If you can log into the remote machine, you are good.
Combined, this got me me very close to my goal. I can be working in a shell on either side and have access to read or write files on the other side. I just have to set it up carefully. Continue reading “Linux Fu: Simple SSH File Sharing”→
Most kids catch on to the fact that matter can exist in three states — solid, liquid, and gas — pretty early in life, usually after playing in the snow a few times. The ice and snowflakes, the wet socks, and the fog of water vapor in breath condensing back into water droplets all provide a quick and lasting lesson in not only the states of matter but the transitions between them. So it usually comes as some surprise later when they learn of another and perhaps more interesting state: plasma.
For the young scientist, plasma is not quite so easy to come by as the other phases of matter, coming about as it does from things they’re usually not allowed to muck with. High voltage discharges, strong electromagnetic fields, or simply a lot of heat can strip away electrons from a gas and make the ionized soup that we call plasma. But once they catch the bug, few things can compare to the dancing, frenetic energy of a good plasma discharge.
Jay Bowles picked up the plasma habit quite a while back and built his YouTube channel around it. Tesla coils, Van de Graaff generators, coils and capacitors of all types — whatever it takes to make a spark, Jay has probably made and used it to make the fourth state of matter. He’ll join us on the Hack Chat to talk about all the fun things to do with plasma, high-voltage discharge, and whatever else sparks his interest.
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.
The announcement of Autodesk’s changes to the Fusion 360 personal use license terms this week caused quite a dustup. Our article on the announcement garnered a lot of discussion and not a few heated comments. At the end of the day, though, Autodesk is going to do what it’s going to do, and the Fusion 360 user community is just going to have to figure out how to deal with the changes. One person who decided to do something other than complain is Justin Nesselrotte, who came up with a quick and easy bulk export tool for Fusion 360. This gets to the heart of the issue since the removal of export to STEP, IGES, and SAT files is perhaps the most painful change for our community. Justin’s script automatically opens every design and exports it to the file type of your choice. Since the license changes go into effect on October 1, you’d better get cracking if you want to export your designs.
Over on Twitter, Hackaday superfriend Timon gives us a valuable lesson in “you get what you pay for.” He found that a bunch of his header pin jumper cables weren’t even remotely assembled properly. The conductors of the jumper wire were only loosely inserted into the terminal’s crimp, where apparently no crimping pressure had been applied. The wires were just rattling around inside the crimp, rather than making sold contact. We’ve covered the art and science of crimping before, and it’s pretty safe to say that these jumpers are garbage. So if you’re seeing weird results with a circuit, you might want to take a good, close look at your jumpers. And as always, caveat emptor.
The GNU Radio Conference wrapped up this week, in virtual format as so many other conferences have been this year, and it generated a load of interesting talks. They’ve got each day’s proceedings over on their YouTube channel, so the videos are pretty long; luckily, each day’s stream is indexed on the playbar, so along with the full schedule you can quickly find the talks you’re interested in. One that caught our eye was a talk on the Radio Resilience Competition, a hardware challenge where participants compete head-to-head using SDRs to get signals through in an adversarial environment. It sounds like a fascinating challenge for the RF inclined. More details about registering for the competition can be had on the Radio Resilience website.
You know those recipe sites that give you a few choices on what to make for dinner based on the ingredients you have on hand? We always thought that was a clever idea, and now something like it has come to our world. It’s called DIY Hub, and it aims to guide makers toward projects they can build based on the parts they have on hand. Users create projects on the site, either hosting the project directly on the site or providing a link to projects on another site. Either way, the project’s BOM is cataloged so that users can find something to build based on parts stored in their “Garage”. Granted, most of us suffer from the exact opposite problem of not knowing what to build next, but this could be an interesting tool for stimulating the creative process, especially for teachers and parents. It’s currently in beta, and we’d love to see a few Hackaday.io projects added to the site.
And finally, we got a tip to an oldie but a goodie: How to Build a Castle. No, we don’t expect to see a rash of 13th-century castle builds gracing our pages anytime soon — although we certainly wouldn’t be opposed to the idea. Rather, this is a little something for your binge-watching pleasure. The BBC series, which was actually called Secrets of the Castle, was a five-part 2014 offering that went into great detail on the construction of Guédelon Castle, an experimental archaeology project in France that seeks to build a castle using only the materials and methods available in the 1200s. The series is hosted by historian Ruth Goodman and archaeologists Peter Ginn and Tom Pinfold, and it’s great fun for anyone interested in history and technology.
Mike and I were talking about two very similar clock projects we’d both built recently: they both use ESP8266 modules to get the time over WiFi and NTP, and they both failed. Mike’s failed because he was visiting relatives in a different timezone with different WiFi credentials, and mine failed because daylight savings time caught me off-guard. In both cases, we hard-coded stuff that could obviously change, but we drew vastly different conclusions.
Mike thought he’d solve his WiFi problem with a fallback to a captive portal, and maybe would have to figure out some web interface for configuring the timezone. A very clean, professional solution. Me? I’ve got good comments in the code, can find the UTC offset (or the WiFi creds) in a few minutes, and flash the new version up simply by fetching a USB cable, for something that happens twice a year. It’s hardly worth the trouble to cobble together a web interface.
There’s an XKCD for everything.
We’ve accidentally embodied a quandary that spans both the hardware and software worlds: should flexibility be exposed to the end-user or to the hacker who can peer under the hood or open up the source code? (And what if the end-user is the hacker?) What are the tradeoffs, in project complexity and in ease of use?
And in this, Mike is on the side of right and good, and I’m the heretic. I don’t always write my code to be extensible or re-usable. I sometimes write it to be quickly re-edited and patched whenever I need to. Is it full of magic numbers? Sure! But I know just where they are and how to change them. Heck, most are even well documented in their own header file. You could probably figure it out just about as fast. Would my father-in-law be able to tweak the timezone? Nope! But this ain’t his project anyway.
Dare to code for hackers! Don’t over-generalize or over-abstract. Less is more. Don’t be afraid to edit code. Tweak, compile, and re-flash when the situation changes. After all, that’s how you got the code there in the first place.
And although I’m on the wrong end of history, in this case I was right. You see, before daylight savings time could come around again, and I could have made use of that captive portal that I didn’t bother coding up anyway, my son entered first grade. Everything needs to be changed, from the hardware to the software. Will I code up the next version with flexible time regimes? As flexible as I need it to be, but not more.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
An enduring memory for most who used the 8-bit home computers of the early 1980s is the use of cassette tapes for program storage. Only the extremely well-heeled could afford a disk drive, so if you didn’t fancy the idea of waiting an eternity for your code to load then you were out of luck. If you had a Sinclair Spectrum though, by 1983 you had another option in the form of the unique Sinclair ZX Microdrive.
This was a format developed in-house by Sinclair Research that was essentially a miniaturized version of the endless-loop tape carts which had appeared as 8-track Hi-Fi cartridges in the previous decade, and promised lightning fast load times of within a few seconds along with a relatively huge storage capacity of over 80 kB. Sinclair owners could take their place alongside the Big Boys of the home computer world, and they could do so without breaking the bank too much.
Hackaday editors Mike Szczys and Elliot Williams take a look at all the hacks from the week that was. We think we’ve found the perfect tentacle robot, and its matching controller is also a tentacle. An unrelated project uses the same Bowden cable trick as the tentacle controller to measure deflection. If you’re more of a material-science geek, refining black sand to make your own inductors is a fascinating hack. And we wrap up the episode talking SSH keys and buses that go off road, but not in the way you might think.
Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!
Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!
The big news this week is the huge flaw in Microsoft’s Active Directory, CVE-2020-1472 (whitepaper). Netlogon is a part of the Windows domain scheme, and is used to authenticate users without actually sending passwords over the network. Modern versions of Windows use AES-CFB8 as the cryptographic engine that powers Netlogon authentication. This peculiar mode of AES takes an initialization vector (IV) along with the key and plaintext. The weakness here is that the Microsoft implementation sets the IV to all zeros.
XKCD.com CC BY-NC 2.5
It’s worth taking a moment to cover why IVs exist, and why they are important. The basic AES encryption process has two inputs: a 128 bit (16 byte) plaintext, and a 128, 192, or 256 bit key. The same plaintext and key will result in the same ciphertext output every time. Encrypting more that 128 bits of data with this naive approach will quickly reveal a problem — It’s possible to find patterns in the output. Even worse, a clever examination of the patterns could build a decoding book. Those 16 byte patterns that occur most often would be guessed first. It would be like a giant crossword puzzle, trying to fill in the gaps.
This problem predates AES by many years, and thankfully a good solution has been around for a long time, too. Cipher Block Chaining (CBC) takes the ciphertext output of each block and mixes it (XOR) with the plaintext input of the next block before encrypting. This technique ensures the output blocks don’t correlate even when the plaintext is the same. The downside is that if one block is lost, the entire rest of the data cannot be decrypted Update: [dondarioyucatade] pointed out in the comments that it’s just the next block that is lost, not the entire stream. You may ask, what is mixed with the plaintext for the first block? There is no previous block to pull from, so what data is used to initialize the process? Yes, the name gives it away. This is an initialization vector: data used to build the initial state of a crypto scheme. Generally speaking, an IV is not secret, but it should be randomized. In the case of CBC, a non-random IV value like all zeros doesn’t entirely break the encryption scheme, but could lead to weaknesses. Continue reading “This Week In Security: AD Has Fallen, Two Factor Flaws, And Hacking Politicians”→
