10-Foot High 3D Printer Based On Ender 3

There are two main ways to 3D print large things. You can either make lots of small 3D prints and stick them together, or you can use a larger 3D printer. [Emily the Engineer] went the latter route by making her Ender 3 a full 10 feet tall.

The best Doug Dimmadome hat we’ve seen in a while, printed on the 10-foot Ender 3. If you’re unfamiliar, Doug Dimmadome is the owner of the Dimmsdale Dimmadome.

The Ender 3’s modular construction made this feat straightforward in the early steps. The printer was simply disassembled, with longer aluminium extrusions bolted in their place. New wheels were resin printed via Onshape to to run along the new extrusions, which were of a slightly different profile to the original parts. Wiring was also a hurdle, with the 10-foot printer requiring a lot longer cables than the basic Ender 3.

An early attempt to make the Z-axis work with a very long threaded rod failed. Instead, a belt-driven setup was subbed in, based on existing work to convert Ender 3s to belt drive. With a firmware mod and some wiring snarls fixed, the printer was ready to try its first high print. Amazingly, the printer managed to complete a print at full height, albeit the shaking of the tall narrow print lead to some print quality issues. The frame and base were then expanded and some struts installed to add stability, so that the printer could create taller parts with decent quality.

While few of us would need a 10-foot high Ender 3, it’s easy to see the value in expanding your printer’s build volume with some easy mods. [Emily] just took it to the extreme, and that’s to be applauded. Video after the break.

Continue reading “10-Foot High 3D Printer Based On Ender 3”

This Week In Security: Magic Packets, GPU.zip, And Enter The Sandman

Leading out the news this week is a report of “BlackTech”, an Advanced Persistent Threat (APT) group that appears to be based out of China, that has been installing malicious firmware on routers around the world. This firmware has been found primarily on Cisco devices, and Cisco has released a statement clarifying their complete innocence and lack of liability in the matter.

It seems that this attack only works on older Cisco routers, and the pattern is to log in with stolen or guessed credentials, revert the firmware to a yet older version, and then replace it with a malicious boot image. But the real fun here is the “magic packets”, a TCP or UDP packet filled with random data that triggers an action, like enabling that SSH backdoor service. That idea sounds remarkable similar to Fwknop, a project I worked on many years ago. It would be sort of surreal to find some of my code show up in an APT.

Don’t Look Now, But Is Your GPU Leaking Pixels

There’s a bit debate on who’s fault this one is, as well as how practical of an attack it is, but the idea is certainly interesting. Compression has some interesting system side effects, and it’s possible for a program with access to some system analytics to work out the state of that compression. The first quirk being leveraged here is that GPU accelerated applications like a web browser use compression to stream the screen view from the CPU to the GPU. But normally, that’s way too many pixels and colors to try to sort out just by watching the CPU and ram power usage.

And that brings us to the second quirk, that in Chrome, one web page can load a second in an iframe, and then render CSS filters on top of the iframe. This filter ability is then used to convert the page to black and white tiles, and then transform the white tiles into a hard-to-compress pattern, while leaving the black ones alone. With that in place, it’s possible for the outer web page to slowly recreate the graphical view of the iframe, leaking information that is displayed on the page.

And this explains why this isn’t the most practical of attacks, as it not only requires opening a malicious page to host the attack, it also makes some very obvious graphical changes to the screen. Not to mention taking at least 30 minutes of data leaking to recreate a username displayed on the Wikipedia page. What it lacks in practicality, this approach makes up for in cleverness and creativity, though. The attack goes by the GPU.zip moniker, and the full PDF is available. Continue reading “This Week In Security: Magic Packets, GPU.zip, And Enter The Sandman”

Turing Complete Programming On ARM With Two Instructions

There are many questions that can be asked for software projects, with most of these questions starting with ‘Why…?’. This is true for the challenge of proving that cascading stylesheets are Turing-complete, or that you don’t need all those fancy ISA bits of an ARM processors when you already got the LDM and STM commands in the 32-bit ISA. What originally started off as a bit of a running gag in a group of developers led to [Kellan Clark] implementing a Turing-complete computer and a functioning interpreter using nothing but these two opcodes.

Adding some Brainfsck to your ARM, inside your GBA.
Adding some Brainf**k to your ARM, inside your GBA.

These two opcodes essentially allow the storing or reading of data into memory from any combination of the 16 general-purpose registers (GPRs). This makes them both extremely versatile and also extremely open to ‘abuse’ like in this example. For a straightforward implementation that could prove the concept, [Kellan] decided to pick one of everyone’s favorite esoteric programming languages: Brainf**k, creating the charmingly titled Armf**k that allows anyone to write BF programs for any suitable ARM processor, like the ARM7TDMI in the Game Boy Advance that [Kellan] targeted.

As a proof of concept it’s unquestioningly intriguing, and a great example of how the most powerful parts of any ISA are those that move data around. After all, as anyone who writes ASM and C knows, computers are just machines that can copy bytes around really fast to make stuff happen. Mind-blowing examples like these serve to illustrate that point quite well.

Tip kindly provided by [eeucalyptus].

Building A Weather Display In Rust

We’ve seen a lot of weather displays over the years, and plenty of the more modern ones have been using some form of electronic paper. So what makes this particular build from [Harry Stern] different? The fact that the firmware running on the ESP32 microcontroller at its heart was developed in Rust.

The weather station itself is capable of operating for several months on its rechargeable NiMH battery bank. The Rust section of the project is in two parts, the first of which runs on a server which downloads the weather data and aggregates it into an image. The second part runs on the ESP32 using esp-idf which configures peripherals, turns on and connects to Wi-Fi, retrieves the image from the server, displays the image and then puts the display to sleep. By doing the heavy lifting on the server, the display should be able to run for longer than it would if everything was happening on the ESP32.

The project code is available from this GitHub page which should allow even Rust beginners to follow along, and the case file is also available for those with a 3D printer. [Harry] has a few upgrades planned for future releases as well, including a snap-fit case, a custom PCB, and improved voltage regulator for better battery life, and enhanced error handling for the weather API. And Rust isn’t the only interesting part of this project, either. As prices for e-paper displays continue to fall, more and more of them are found in projects like weather stations and even complete laptops which use these displays exclusively.