Content warning: https://hackaday.com/wp-content/uploads/2018/06/machinetalk.jpg?w=800 If you own a 3D printer, CNC router, or basically anything else that makes coordinated movements with a bunch of stepper motors, chances are good that it speaks G-code. Do …read more h
If you own a 3D printer, CNC router, or basically anything else that makes coordinated movements with a bunch of stepper motors, chances are good that it speaks G-code. Do you?
If you were a CNC machinist back in the 1980’s, chances are very good that you’d be fluent in the language, and maybe even a couple different machines’ specialized dialects. But higher level abstractions pretty quickly took over the CAM landscape, and knowing how to navigate GUIs and do CAD became more relevant than knowing how to move the machine around by typing.
Reprap Darwin: it was horrible, but it was awesome.
Strangely enough, I learned G-code in 2010, as the RepRap Darwin that my hackerspace needed some human wranglers. If you want to print out a 3D design today, you have a wealth of convenient slicers that’ll turn abstract geometry into G-code, but back in the day, all we had was a mess of Python scripts. Given the state of things, it was worth learning a little G-code, because even if you just wanted to print something out, it was far from plug-and-play.
For instance, it was far easier to just edit the M104 value than to change the temperature and re-slice the whole thing, which could take an appreciable amount of time back then. Honestly, we were all working on the printers as much as we were printing. Knowing how to whip up some quick bed-levelling test scripts and/or demo objects in G-code was just plain handy. And of course the people writing or tweaking the slicers had to know how to talk directly to the machine.
Even today, I think it’s useful to be able to speak to the machine in its native language. Case in point: the el-quicko pen-plotter I whipped together two weekends ago was actually to play around with Logo, the turtle language, with my son. It didn’t take me more than an hour or so to whip up a trivial Logo-alike (in Python) for the CNC: pen-up, pen-down, forward, turn, repeat, and subroutine definitions. Translating this all to machine moves was actually super simple, and we had a great time live-drawing with the machine.
So if you want to code for your machine, you’ll need to speak its language. A slicer is great for the one thing it does – turning an STL into G-code, but if you want to do anything a little more bespoke, you should learn G-code. And if you’ve got a 3D printer kicking around, certainly if it runs Marlin or similar firmware, you’ve got the ideal platform for exploration.
Does anyone else still play with G-code?
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!
Content warning: https://hackaday.com/wp-content/uploads/2023/01/Mister-case-with-classic-controller-ports.png?w=800 Some careful measuring and a little extra effort can be all that separates what looks like a hack job from a slick end product, and that is apparent in [Er
Some careful measuring and a little extra effort can be all that separates what looks like a hack job from a slick end product, and that is apparent in [Eric Sorensen]’s classy retrogaming rig, complete with ports for original console controllers.
Neatly housing these components in a case makes all the difference.
[Eric] likes his vintage gaming, and was terrifically pleased with MiSTer, an open-source project that recreates various classic computers, game consoles and arcade machines using modern FPGA-based hardware. Of course, what makes retro gaming even better is using a platform’s genuine original controllers, which just takes a little extra hardware and wiring.
But [Eric] found that all the required accessories and peripherals started to look awfully cluttered. He solved this issue by packing everything carefully into a specialty PC case called the Checkmate A1500 Plus, which gives off a strong 80s design vibe. As a bonus, the front panels are all removable and that’s where [Eric] decided to house the custom controller ports.
First [Eric] carefully measured each controller connector to create CAD models, then designed matching front panels to house the connectors and 3D printed them. Once that was done, post-processing the panels was a long process of apply Bondo, sand, paint, and repeat as needed. The results looks fantastic, and this project is a prime example of how aesthetics and finish can matter.
Find yourself in a similar situation? [Tom Nardi] has shown us all that 3D prints don’t have to look 3D-printed, and careful application of paint and primer can really put the ‘pro’ in prototyping.
Raimondas Lapinskas reshared this.
Content warning: https://hackaday.com/wp-content/uploads/2023/01/clock-1.png?w=800 If [Bob Dylan] had seen [Pgeschwi]’s bike chain clock, it might have influenced the famous song. The clock uses a stepper motor and a bike chain to create a clock …read more https://hackad
If [Bob Dylan] had seen [Pgeschwi]’s bike chain clock, it might have influenced the famous song. The clock uses a stepper motor and a bike chain to create a clock that has a decidedly steampunk vibe. Despite the low-tech look, the build uses 3D printing and, of course, a bike chain.
A full view of the bike chain clock.
The clock doesn’t just show the time. There is a contraption to show the day of the week, and a pendulum shows the current phase of the moon. The visible wiring is all old-school brass wire on the wood base. [Pgeschwi] is considering changing out all the 3D printed parts for brass ones, so this may be just an early prototype of the final product, but it still looks great.
The design used common tools, including Tinkercad and an online gear generation tool. There are a lot of details you wouldn’t suspect until you tried to build something like this yourself. For example, making the chain reliably go in both directions required a timing belt to synchronize the top gears. Getting the numbers on the chain to pass by the gears.
It is hard to tell from the picture, but there’s an LED under the 10-minute marks that shows the unit’s digits of the time. There are no markings for it yet, but in the picture, the time is actually 4:09.
We love unusual clocks, and we see plenty of them. From Fibonacci clocks to magnetic field line clocks, we love them all.
Content warning: https://hackaday.com/wp-content/uploads/2023/01/5793871674628396365.png?w=800 Wolfenstein 3D and Doom are great examples of early FPS games. Back in that era, as Amiga was slowly losing its gaming supremacy to the PC, Apple wasn’t even on the playing …rea
Wolfenstein 3D and Doom are great examples of early FPS games. Back in that era, as Amiga was slowly losing its gaming supremacy to the PC, Apple wasn’t even on the playing field. However, [Chris Tully] has used the 90s HyperCard platform to create an FPS of his own, and it’s charming in what it achieves.
If you’re not familiar with it, HyperCard was a strange combination of database, programming language, and graphical interface system all rolled into one. It made developing GUI apps for the Macintosh platform simpler, with some limitations. It was certainly never intended for making pseudo-3D video games, but that just makes [Chris’s] achievement all the more impressive.
At this stage, [Chris’s] game doesn’t feature any NPCs, weapons, or items yet. It’s thus more of a First Person Walker than First Person Shooter. It features four small rooms with perpendicular, vertical walls, rendered either greyscale or 8-bit color. Now that he’s got the basic engine running, [Chris] is looking to recreate a bit of a Doom RPG experience, rather than copying Doom itself. He hopes to add everything from monsters to weapons, lava, and working HUD elements. If you want to dive in to the code, you can – HyperCard “stacks”, as they’re known, are made up of readily editable scripts.
[Chris] built the project to celebrate the aesthetic and limitations of the original Mac platform. While it could technically run on original hardware, it would run incredibly slowly. It currently takes several seconds to update the viewport on an emulated Mac Plus with 4MB of RAM. Thankfully, emulation on a modern PC can be sped up a lot to help the framerate.
We love seeing HyperCard pushed far beyond its original limits. We’ve seen it before, too, such as when it was used on a forgotten 90s Apple phone prototype. If you’ve been hacking away on retro software yourself, we’d love to see your projects on the tipsline!
Content warning: https://hackaday.com/wp-content/uploads/2023/01/Screenshot-2023-01-25-at-15-42-30-2111.08629.pdf.png?w=544 One of the great things about the Hackaday community is how quickly you find out what you don’t know. That’s not a bad thing, of course; after all,
One of the great things about the Hackaday community is how quickly you find out what you don’t know. That’s not a bad thing, of course; after all, everyone is here to get smarter, right? So let’s work together to get our heads around this paper (PDF) by [Zerina Kapetanovic], [Miguel Morales], and [Joshua R. Smith] from the University of Washington, which purports to construct a low-throughput RF transmitter from little more than a resistor.
This witchcraft is made possible thanks to Johnson noise, also known as Johnson-Nyquist noise, which is the white noise generated by charge carriers in a conductor. In effect, the movement of electrons in a material thanks to thermal energy produces noise across the spectrum. Reducing interference from Johnson noise is why telescopes often have their sensors cooled to cryogenic temperatures. Rather than trying to eliminate Johnson noise, these experiments use it to build an RF transmitter, and with easily available and relatively cheap equipment.
On the transmitter side, we have little more than an antenna connected to the common side of a digital RF switch, an Analog Devices ADG901 eval board. The switch toggles the antenna between a 50-Ohm dummy load or ground; this allows data to be modulated with on-off keying, with the Johnson noise generated by the dummy load representing a logical 1. The antenna is a pyramidal horn antenna made from foil-covered foamboard, offering 13.6 dBi of gain. The receiver is a pair of high-gain LNAs, a bandpass filter, and an SDR dongle with a Raspberry Pi, all attached to an identical antenna.
After running a number of control experiments to make sure they weren’t measuring general RF noise or feedthrough from the RF switch control signal, the authors did several demonstrations of what can be done with this. They were able to show throughput in the 20 bps range at 1.42-GHz, over distances of up to 7 meters, and offered a couple of practical uses, such as a battery-free remote temperature sensor.
It’s important to note that this isn’t using backscatter of ambient RF signals from local radio stations; we’ve seen those before and were suitably impressed with what they can do. This is just relying on thermal noise to generate a carrier, and that’s pretty cool too. We’d love to see someone replicate this — if you do, make sure you drop us a tip so we can write it up.
Thanks to [Reed] for the tip!
Content warning: https://hackaday.com/wp-content/uploads/2023/01/conditions-die.jpg?w=528 As simple as a processor’s instruction set may seem, especially in a 1978-era one like the Intel 8086, there is quite a bit going on to go from something like …read more https://hac
The condition PLA evaluates microcode conditionals.
As simple as a processor’s instruction set may seem, especially in a 1978-era one like the Intel 8086, there is quite a bit going on to go from something like a conditional jump instruction to a set of operations that the processor can perform. For the CISC 8086 CPU this is detailed in a recent article by [Ken Shirriff], which covers exactly how the instructions with their parameters are broken down into micro-instructions using microcode, which allows the appropriate registers and flags to be updated.
Where the 8086 is interesting compared to modern x86 CPUs is how the microcode is implemented, using gate logic to reduce the complexity of the microcode by for example generic parameter testing when processing a jump instruction. Considering the limitations of 1970s VLSI manufacturing, this was very much a necessary step, and an acceptable trade-off.
Each jump instruction is broken down into a number of micro-instructions that test a range of flags and updates (temporary) registers as well as the program counter as needed. All in all a fascinating look at the efforts put in by Intel engineers over forty years ago on what would become one of the cornerstones of modern day computing.
👉TRAIN WITH ME: https://swolenormousx.
Content warning: https://hackaday.com/wp-content/uploads/2023/01/Making-a-Gears-Cutting-Machine-8-4-screenshot.png?w=800 You can buy gears off the shelf, of course, and get accurately machined parts exactly to your chosen specification. However, there’s something rugged a
You can buy gears off the shelf, of course, and get accurately machined parts exactly to your chosen specification. However, there’s something rugged and individualist about producing your own rotating components. [Maciej Nowak] demonstrates just how to produce your own gears with a homemade cutting tool.
The cutting tool for the job is an M16 machine tap, chosen for the smaller flutes compared to a hand tap. This makes it more suitable for cutting gears. It’s turned by a belt driven pulley, run by a small motor. The workpiece to be cut into a gear is then fed into the cutting tool by sliding on a linear bearing, with its position controlled by a threaded rod. The rod can be slowly turned by hand to adjust the workpiece position, to allow the gear teeth to be cut to an appropriate depth.
The method of action is simple. As the tap turns it not only cuts into the workpiece, but rotates it on a bearing as well. By this method, it cuts regular teeth into the full circumference, creating a gear. Obviously, this method doesn’t create highly-complex tooth shapes for ultimate performance, but it’s more than capable of creating usable brass and steel gears for various purposes. The same tool can be used to cut many different sizes of gear to produce a whole geartrain. As a bonus, the resulting gears can be used with M16 threads serving as worm gears, thanks to the pitch of the tap.
If you find yourself needing to produce tough metal gears on the regular, you might find such a tool very useful. Alternatively, we’ve explored methods of producing your own sprockets too, both in a tidy manner, and in a more haphazard fashion. Video after the break.
Content warning: https://hackaday.com/wp-content/uploads/2023/01/Screenshot-2023-01-25-161747-e1674625689391.png?w=800 Anyone in the JDM scene can tell you, round air vents are prime real estate for round analog gauges. If you want a gauge but don’t want to block your …re
Anyone in the JDM scene can tell you, round air vents are prime real estate for round analog gauges. If you want a gauge but don’t want to block your vent, you could consider building these LED vent gauges from [ktanner] instead.
The design is simple. It relies on 3D printing a replacement bezel for the Mazda Miata’s stock round air vents. This bezel is designed to hold a NeoPixel ring from Adafruit. When built with the optional laser-cut diffuser, the parts have a near-stock look when the LEDs are turned off. It’s a classy, stealthy mod – exactly the sort of thing Miata owners need but never seem to have! (Author Note: don’t be mad, I was once one of you!)
With 24 addressable RGB LEDs, it’s possible to display all kinds of data by turning the LEDs on and off and varying the colors. For example, you could readily build a boost gauge that turns on more LEDs at higher boost pressure. It could then be set up to flash red in the event that you surpass safe thresholds. [ktanner] hasn’t specified any particular microcontroller for the setup — but just about any part you like can be used to drive NeoPixels, after all.
If you’re new to NeoPixels, you might find a simulator useful for developing your projects. Meanwhile, if you’re doing similar work on other cars, be sure to hit us up on the tipsline!
Hackaday Podcast 203: Flashlight Fuel Fails, Weird DMA Machines, and a 3D Printed Prosthetic Hand Flex
Content warning: https://hackaday.com/wp-content/uploads/2016/05/microphone.jpg?w=800 This week, Editor-in-Chief Elliot Williams and Managing Editor Tom Nardi meet up virtually to talk about all the hacks that are fit to print. This week’s episode starts off with …read mo
This week, Editor-in-Chief Elliot Williams and Managing Editor Tom Nardi meet up virtually to talk about all the hacks that are fit to print. This week’s episode starts off with a discussion about the recently unveiled 2023 Hackaday.io Low-Power Challenge, and how hackers more often than not thrive when forced to work within these sort of narrow parameters. Discussion then continues to adding a virtual core to the RP2040, crowd-sourced device reliability information, and mechanical Soviet space computers. We’ll wrap things up by wondering what could have been had Mattel’s ill-fated ThingMaker 3D printer actually hit the market, and then engage in some wild speculation about the issues plaguing NASA’s latest Moon mission.
Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!
Available in the cloud, or as download!
Where to Follow Hackaday Podcast
Places to follow Hackaday podcasts:
Episode 203 Show Notes:
What’s that Sound?
- Congrats to [TheElectricCanuck] for getting the sound of musical cards in bike spokes.
Interesting Hacks of the Week:
- RP2040 DMA Hack Makes Another ‘CPU Core’
- You Can Help Build A Resin Printer Review Database
- DIY Capacitor Leakage Tester With A Professional Finish
- Inside Globus, A Soviet-Era Analog Space Computer
- Designing A Simpler Prosthetic Finger
- Secure LoRa Mesh Communication Network
- Elliot’s Picks:
- Tom’s Picks:
Content warning: https://hackaday.com/wp-content/uploads/2023/01/coaster_primary_0.png?w=800 Looking for the perfect winter desk accessory? [Wq] has created a beautiful coaster made out of PCBs that can keep your drink warm with an internal heater. (Chinese). An ESP8266
Looking for the perfect winter desk accessory? [Wq] has created a beautiful coaster made out of PCBs that can keep your drink warm with an internal heater. (Chinese).
An ESP8266 sits as the main controller, with an additional MQTT control option, where the whole unit is powered over a USB-C connection. On board PCB traces, in the shape of a Hilbert curve, create the heating element used to heat beverages placed on the coaster, where [Wq] reports a measured resistance of the PCB trace network at 1.2 ohms. [Wq] writes that an AON6324 MOSFET replaces the D4184 that was previously being used, but might need some testing to get working properly. There are two capacitive touch sensors which has a TTP223E capacitive touch controller attached to detect input, with a multi-colored FM-3528 RGB LED for user feedback.
We love the artistry that went into building the coaster. For adventurous hackers wanting to build their own, the bill of materials (BOM), source code and board files are all available. We’ve seen everything from coasters and to PCB reflow boards, so it’s nice to see experimentation with a combination of these ideas.
Content warning: https://hackaday.com/wp-content/uploads/2016/01/darkarts.jpg?w=800 When we first saw tweets about a security issue in Grand Theft Auto V, it sounded a bit like a troll. “Press ‘alt and f4’ to unlock a cheat mode”, …read more https://hackaday.com/2023/01/
When we first saw tweets about a security issue in Grand Theft Auto V, it sounded a bit like a troll. “Press ‘alt and f4’ to unlock a cheat mode”, or the hacker that claims to be able to delete your character. [Tez2]’s warning tweet that you shouldn’t play GTA Online without a firewall sounds like another of these online urban legends. But this one actually seems legit. NIST is even in on the fun, assigning CVE-2023-24059 for the exploit.
When playing an online game, other users send a “join request” to join the active session. This packets can contain malformed data which has been observed to crash the game client remotely. It’s believed, though not publicly confirmed, that it’s also a Remote Code Execution (RCE) vulnerability. It seems likely that this aspect will be added to some of the various cheat panels that are already widely used for this 10-year-old game. So now, rather than just giving your own character infinite ammo and health, you can inflict some havoc on other players, possibly up to corrupting their character files and getting them banned.
But why stop there? If we have code execution inside the game, what stops another player from launching a real attack? A video game isn’t sandboxed like a browser, and there’s nothing preventing a disk wiper attack or even a worm from compromising a bunch of players. The worst part is that it’s an old game, and even though there’s a large playerbase, it’s not guaranteed to get a fix. There’s at least one project aiming to be a firewall to prevent the issue.
XNU’s 19 and 20 year old Bugs
[Adam Doupé] seems to have a knack for finding old bugs in Apple’s code, and this time it’s a pair of really old flaws in Apple’s kernel, XNU. The first is an issue in
dlil.c, the network interface handler. This issue is a type casting error, where an int is cast to a uint_16. If that cast overflows, the value becomes a large negative number, and the subsequent data write underflows the buffer and writes out-of-bounds. The method to trigger this one is a bit tricky, as it requires creating 65536 network interfaces.
There are two approaches to triggering that condition. The first is the simplest, a tiny script running as root, that calls
ifconfigrepeatedly to create the interfaces. While that could be interesting as part of an exploit chain, the more interesting idea is to make a malicious USB dongle that presents itself as multiple network interfaces. The rest of the post is [Adam]’s attempt to turn the underflow into an exploit. He didn’t quite pull it off, but it looks like it’s possible.
The second bug is even older, a 20 year old flaw in XNU’s
ndrv.c, the raw socket handler. It’s an edge case where a linked list with two members get improperly walked, one of the list members is freed, but the parent item still contains a pointer to the now-freed memory. Both bugs have now been fixed in the latest iOS and macOS releases.
Android (ARM) Too
Android isn’t one to be left out, with a great writeup from [Man Yue Mo] of Github Security Lab, about a problem in the Arm Mali GPU shipped as part of Pixel 6 devices. With great irony, we are told of how the one non-Google element in the all-Google phone led to kernel-space exploitation from within an app. Specifically, it’s the driver for that GPU, and how it handles JIT memory, which is memory segments that are managed by the kernel, and accessed by userspace and directly by the GPU. And as you might expect, having three different components accessing memory at once can cause problems.
In this case, the problem is how eviction is handled. Those chunks of memory get processed, and then can be returned to the free store. A performance optimization by the driver is to keep memory buffers “warm”, not actually asking the kernel to free them, and skipping the allocation process when the next request is needed. The problem is that memory in this limbo state is considered “evictable”, and the kernel can free those regions without doing so through the GPU driver. This leave the system in an odd state where the GPU driver and userspace still have valid pointers to a memory location, but the kernel has marked it free. The real fun begins when the freed memory location is claimed by an attacking process, and a fake JIT object put in its place. By some clever memory manipulation, this can be leveraged to produce a userspace mapping of kernel code, which can then be read and written. And the simplest step from there is to just modify the userspace application, making it run as root.
It’s a clever find, but what really stands out is the problem with getting it fixed. This was reported to Android engineers in July of 2022, and a few weeks later the report was closed as a “Won’t fix” issue. There is a legitimate point here, that it’s not Android code that contains the problem, and this needed to be fixed in the ARM driver. ARM issued an update that fixed the issue less than three months later, in August of 2022. A coordinated disclosure was scheduled with ARM for November, but it seems the Android engineers completely dropped the bug, and waited til the January update to finally ship the patch to Android users. And when it finally came, it was tracked as a different bug altogether, meaning the original report was closed and forgotten about. It’s a bit disheartening to see Google show such a flippant attitude toward a vulnerability of this severity, on their own product.
It’s beginning to look like a bad idea to put the Server Message Block Daemon driver in the Linux kernel, as we have another pre-auth integer underflow leading to denial of service. Researchers at Sysdig found the flaw this time, researching based on the previous ZDI-22-1690, which was a more serious RCE in the same kernel module. This one is a bit different from other integer underflows we’ve looked at. The wrap-around nature of integers instead saves this vulnerability from being a more serious one.
The real problem is that during SMB authentication, the data structure from the remote user contains a pair of length values, which are used to parse the incoming authentication data. It’s obvious that these values aren’t implicitly trusted, and some good error checking is done to prevent a trivial buffer overflow. The case that trips us up is when
nt_lenis less than
CIFS_ENCPWD_SIZE, and the resulting value is negative. When this negative integer is cast to the unsigned
memcpy()call, the negative integer is “unwrapped” to a nearly max-value
size_t. The memory copy function will attempt the instruction, but this is a rather uncontrolled operation, and eventually reaches inaccessible memory, and panics the kernel. So far there doesn’t seem to be a way to turn this particular flaw into a true RCE. And besides, after this many years, surely everyone knows not to expose an SMB service to untrusted users, right?
While Secure Boot hasn’t quite proven to be the dystopian PC lock-in that some of us feared, it’s still occasionally a pain to deal with while trying to fix something on a broken machine. Need a custom boot disk to run a tool? Yep, time to disable secure boot. But there’s a few cases where it’s helpful, like preventing boot malware from getting a toe-hold in an encrypted system. There’s maybe something to be said for a known quantity like secure boot.
Which is why it’s a bit odd to find that MSI decided to compromise it en masse on their desktop motherboards in a firmware update pushed out last January. And do note, MSI didn’t turn off secure boot. Check the firmware settings, or run
mokutil --sb-state, and these machines would happily inform you that Secure Boot was still enabled. But an obscure firmware setting, “Image Execution Policy” is set to “Always Execute” — so Secure Boot would still check the signature on the boot stack, and then boot it regardless of what was found. I’ll just quote the discoverer, [Dawid Potocki]’s conclusion: “Don’t trust that whatever security features you enabled are working, TEST THEM!”