Most of what we do here at Hackaday is look out for cool projects and then write them up so that you all know about them. Nothing is better than being really stoked about a clever hack and then being able to share it with tens of thousands of like-minded folks. Sure, it’s our job, but we really do it because we love to share. And it’s clear that you all do too! After all, we write up the hacks that you document for us.

We recently featured a hack where the guy who did the work in question said that he didn’t think it was “worthy of Hackaday”. (Of course, it was!) And I don’t like that sentiment at all, honestly, because a hack that you enjoyed doing is a hack worth sharing, even if just for sharing the joy of doing it, and that came across fully.

Of course we gladly feature the ultra-bravado hacks where the nearly impossible is made real. But there’s equal value in the simple hacks that inspire others to pursue one odd path or another. Or even pieces where there’s no hack involved, but simply the sharing of something cool.

This week, [Arya Voronova] wrote a piece about her experience using MicroPython on embedded devices, and it apparently resonated with a lot of our readers. It’s not a deep-dive into MicroPython, or a mind-bending abuse of the language. Instead, it’s a simple “this is what I love about doing things this way”, and that’s a great perspective that often gets lost when we get deep in the technical weeds.

I had the same realization a few months back at Hackaday Europe. In the lightning talks, most everyone gave talks about cool projects that they are working on, and they’re absolutely worth watching for that. [Jaap Meijers] gave a wonderful talk about making animated QR codes, but it wasn’t about how he invented animated QR codes, because he was just using someone else’s project. Instead, it was about how neat he thought someone else’s work was, and how he really wanted to share it with us. (And now you know too.)

Epic hacks are fantastic, no question. But the simple expression of the love of hacking, whether in words or in the doing, is equally important. Show us your work, but don’t forget to show us your joy along the way.

Experimenting in the world of particle physics probably brings to mind large, expensive pieces of equipment like particle accelerators, or at least exotic elements or isotopes that most of us can’t easily find. But plenty of common objects emit various particles, and it turns out that detecting these particles does not require government backing or acres of test equipment. In fact, you can get this job done with a few readily-available parts and [Tim] shows us how it’s done with his latest project.

The goal of his build is to have a working particle detector for less than $10 per board, although he’s making them in bulk to be used in an educational setting. The board uses a set of photodiodes enclosed in a protective PCB sandwich to detect beta particles from a Potassium-40 source. The high-energy electron interacts with the semiconductor in the photodiode and creates a measurable voltage pulse, which can be detected and recorded by the microcontroller on the board. For this build an RP2040 chip is being used, with a number of layers of amplification between it and the photodetector array used to get signals that the microcontroller can read.

Getting particle physics equipment into the hands of citizen scientists is becoming a lot more common thanks to builds like this which leverage the quirks of semiconductors to do something slightly outside their normal use case, and of course the people building them releasing their projects’ documentation on GitHub. We’ve also seen an interesting muon detector with a price tag of around $100 and an alpha particle detector which uses a copper wire with a high voltage to do its work.

If you were expecting a post about ancient kings and queens, you are probably at the wrong website. [Burn Heart] has a fascination with ancient measuring devices and set out to recreate period-correct rules, although using decidedly modern techniques.

The first example is a French rule for measuring the “pied du Roi” or king’s foot. Apparently, his royal highness had large feet as a the French variant is nearly 13 inches long. The next rulers hail from Egypt and measure cubits and spans. Turns out the pyramid builders left a lot of information about measurements and their understanding of math and tools like dividers.

Other rules from Rome, Japan, and the Indus Valley are also included. According to the post, one set of these rulers used locally sourced wood, but a second “limited” edition used wood that the originals might have. Most of the rulers were etched via CNC, although the French ruler was hand-etched.

The Romans, apparently, had smaller feet than French royalty, as their Pes or foot was about 11.65 inches. There are plenty of little tidbits in the post ranging from the origin of the word inch to why the black wood used for piano keys is called ebony.

We’ll stipulate this isn’t exactly a hack, although it is fine workmanship and part of hacker culture is obsessing over measuring things, so we thought it was fair game. These days, rulers are often electronic. Which makes it natural to put them on a PC board.

The printing press was first invented in 1440 AD by Johannes Gutenberg. It’s not so relevant to our day to day lives today, but it’s a technology that forever changed the path of human history. Now you can whip one up yourself using this teeny design from the [3DPrintingEnthusiast]!

Don’t expect to be making broadsheets with this thing—it’s a strictly table-top sized unit made on a 3D printer. Still, it does the job! The bed, frame, paper holder, and clamps are all 3D-printed. However, you will need some minor additional supplies to complete the carriage and inkballs.

As for your printing plates, you could go out and source some ancient lead type—or you could just 3D print some instead. The latter is probably easier if you’re living in 2024 like yours truly. Who knows, though. 2028 could be a banner year where printing presses roar back to prominence. Try not to think about the global scale disasters that would make that a reality.

In any case, there’s got to be some kind of irony about 3D-printing a printing press on a 3D printer? Perhaps, perhaps not. Debate it below!

Sometimes, a limb is damaged so badly that the only way to save the patient is to amputate it. Researchers have now found that humans aren’t the only species to perform life-saving amputations. [via Live Science]

While some ants have a gland that secretes antimicrobial chemicals to treat wounds in their comrades, Florida carpenter ants have lost this ability over the course of evolution. Lacking this chemical means to treat wounds, these ants have developed the first observed surgery in an animal other than humans.

When an ant has a wounded leg, its fellow ants analyze the damage. If the femur is the site of the wound, the other ants removed the damaged limb in 76% of cases by biting it off, while tibial wounds were treated in other ways. Experimental amputations of the tibia by researchers showed no difference in survivability compared to leaving the limb intact unless the amputation was performed immediately, so it seems the ants know what they’re doing.

Maybe these ants could be helpful surgical aids with some cyborg additions since they’ve already got experience? Ants can help you with programming too if that’s more your speed.

When we first spotted the article about a one-transistor amateur radio transceiver, we were sure it was a misprint. We’ve seen a lot of simple low-power receivers using a single transistor, and a fair number of one-transistor transmitters. But both in one package with only a single active component? Curiosity piqued.

It turns out that [Ciprian Popica (YO6DXE)]’s design is exactly what it says on the label, and it’s pretty cool to boot. The design is an improvement on a one-transistor transceiver called “El Pititico” and is very petite indeed. The BOM has only about fifteen parts including a 2N2222 used as a crystal-controlled oscillator for both the transmitter and the direct-conversion receiver, along with a handful of passives and a coupe of hand-wound toroidal inductors. There’s no on-board audio section, so you’ll have to provide an external amplifier to hear the signals; some might say this is cheating a bit from the “one transistor” thing, but we’ll allow it. Oh, and there’s a catch — you have to learn Morse code, since this is a CW-only transmitter.

As for construction, [Ciprian] provides a nice PCB  layout, but the video below seems to show a more traditional “ugly style” build, which we always appreciate. The board lives in a wooden box small enough to get lost in a pocket. The transceiver draws about 1.5 mA while receiving and puts out a fairly powerful 500 mW signal, which is fairly high in the QRP world. [Ciprian] reports having milked a full watt out of it with some modifications, but that kind of pushes the transistor into Magic Smoke territory. The signal is a bit chirpy, too, but not too bad.

We love minimalist builds like these; they always have us sizing up our junk bin and wishing we were better stocked on crystals and toroids. It might be good to actually buckle down and learn Morse too.

Modern tech is great, but we have to admit that we sometimes miss when electronic things looked complicated. A modern computer looks dull compared to, say, an IBM 360. Control rooms now look no different than a stock trading room, instead of being full of indicators, knobs, and buzzers. [BorisDigital] must have some of those same feelings. He built a very cool control panel for his Home Assistant setup. He based it somewhat on a jet cockpit and a little on a nuclear plant control room, and the result, as you can see in the video below, is great.

This is less of a how-to video and more of an inspirational one. After all, you won’t have the same setup, but there are many details about how it was constructed with a Raspberry Pi, 3D printing, and control of the Home Assistant via web services.

You might point out that you could put everything on a computer screen, but what fun is that? There is a touchscreen, so you do have some options. Normally, the panel hangs on the wall, but you can snap feet on to rest the panel on a desk or table.

The panel has about 50 I/O devices, so a GPIO expander — actually several of them — was necessary. To make a nice-looking label, he fills in 3D-printed inset text with spackle. It isn’t perfect, but it looks good enough.

The RADIUS authentication scheme, short for “Remote Authentication Dial-In User Service”, has been widely deployed for user authentication in all sorts of scenarios. It’s a bit odd, in that individual users authenticate to a “RADIUS Client”, sometimes called a Network Access Server (NAS). In response to an authentication request, a NAS packages up the authentication details, and sends it to a central RADIUS server for verification. The server then sends back a judgement on the authentication request, and if successful the user is authenticated to the NAS/client.

The scheme was updated to its current form in 1994, back when MD5 was considered a cryptographically good hash. It’s been demonstrated that MD5 has problems, most notably a chosen-prefix collision attack demonstrated in 2007. The basis of this collision attack is that given two arbitrary messages, it is possible to find a pair of values that, when appended to the end of those messages, result in matching md5 hashes for each combined message. It turns out this is directly applicable to RADIUS.

The attack is a man-in-the-middle, but not against an authenticating user. This attack is a man-in-the-middle between the NAS and the RADIUS server, and a real user isn’t even required. This elevated position does make an attack harder to achieve in some cases, but situations like RADIUS providing authentication for administrative access to a device is squarely in scope. Wrapping the RADIUS backend communications in a TLS layer does protect against the attack.

Gitlab

It’s once again time to go update your Gitlab instances, and this one sounds familiar. It’s another issue where an attacker could run pipeline jobs as an arbitrary user. This comes as one more of a series of problems in Gitlab, with at least one of them being exploited in the wild. It’s not surprising to see a high-visibility vulnerability leading to the discovery of several more similar problems. With this latest issue being so similar to the previous pipeline problem, it’s possible that it’s actually an incomplete patch or additional workaround discovered to exploit the same issue.

Exim

There’s a bug in the Exim email server, that impacts the processing of attachment blocking rules. Specifically, the filename in the email header is broken into multiple parts, with some confusing extra bytes in between. It’s technically compliant with the right RFC, but Exim’s mime handling code gets confused, and misses the right message name.

Exim server can be configured to block certain file types, and this vulnerability allows those blocked attachments through. The original CVSS of 9.1 is a tad insane. The latest update drops that to a 5.4, which seems much more appropriate.

Plormbing Your ORM

Prisma is a “Next Generation ORM (Object Relational Mapper), that takes database schema, and maps it to code objects. In other words, it helps write code that interacts with a database. There’s some potential problems there, like using filters on protected data, to leak information one byte at a time, in a very Hollywood manner.

This brings us to a second approach, a time-based data leak. Here a SQL query will execute slowly or quickly depending on the data in the database. The plormber tool is designed to easily build attempts at time-based leaks. Hence the pun. If you have a leak in your ORM, call a plORMber. *sigh*

Internet Explorer Rises Again

When Microsoft finally obsoleted Internet Explorer in 2022, I had some hope that it wouldn’t be the cause of any more security issues. And yet here we are, in 2024, talking about an exploitation campaign that used a 0-day in Windows to launch Internet Explorer.

A very odd file extension, .pdf.url, manages to appear as a pdf file with the appropriate icon, and yet opens IE when executed. This finally got classified by Microsoft as a vulnerability and fixed.

Bits and Bytes

There’s another SSH issue, related to regreSSHion. This time a vendor patch makes a call to cleanup_exit() from a signal handler function, calling more async-unsafe code. If that doesn’t make any sense, circle back around to last week’s installment of the column for the details. This time it’s Fedora, Red Hat, and other distros that used the patch.

One of the security barriers that most of us rely on is that traffic originating from the WAN side of the router should stay there. When that paradigm breaks down, we have problems. And that’s exactly what the folks at Claroty are working to defeat. The trick this time is a vulnerability in a router’s Dynamic DNS service. Manage to spoof a DNS lookup or MitM that connection, and suddenly it’s RCE on the router.

And finally, we’ve covered a pair of outstanding stories this week here at Hackaday. You should go read about how Ticketmaster’s app was reverse engineered, followed by a brilliant and completely impractical scheme to get your Internet connection for free while flying.

The host of problems to deal with when you’re feeling the need for FDM speed are many and varied, but high on the list is figuring out how to melt filament fast enough to accommodate high flow rates. Plus, the filament must be melted completely; a melty outside and a crunchy inside might be good for snacks, but not for 3D printing. Luckily, budget-minded hobbyists can build a drop-in booster to increase volumetric flow using only basic tools and materials.

[aamott]’s booster, which started life as a copper screw, is designed to replace the standard spacer in an extruder, with a bore that narrows as the filament gets closer to the nozzle to ensure that the core of the filament melts completely. Rather than a lathe, [aamott]’s main tool is a drill press, which he used to drill a 0.7 mm bore through the screw using a PCB drill bit. The hole was reamed out with a 10° CNC engraving bit, generating the required taper. After cutting off the head of the screw and cleaning up the faces, he cut radial slots into the body of the booster by threading the blade of a jeweler’s saw into the bore. The result was a bore wide enough to accept the filament on one end, narrowing to a (roughly) cross-shaped profile at the other.

Stacked up with a couple of knock-off Bondtech CHT nozzles, the effect of the booster was impressive — a 50% increase in flow rate. It’s not bad for a prototype made with simple tools, and it looks a little easier to build than [Stefan]’s take on the same idea.

As practical SD cards are, they lack much of what made floppy disks and cartridges so awesome: room for art and a list of contents, as well as the ability to not be lost in shaggy carpet or down a pet’s gullet. In a fit of righteous nostalgia, [Abe] decided that he’d turn SD cards into cartridges in the best way possible, and amazingly managed to not only finish the project after two years, but also make it look snazzy enough to have come straight out of the 1980s. The resulting cartridges come both with fixed (256 MB) and removable micro SD card storage, which are mounted on a PCB that passively connects to pogo pins in the custom, 3D printed reader.

The inspiration for this project kicked in while [Abe] was working on a floppy drive conversion project called the Floppy8, which crammed an MCU into an external floppy drive along with a rough version of these SD card-based cartridges that used the physical card’s edge connector to connect with a micro SD slot inside the converted floppy drive. The problem with this setup was that alignment was terrible, and micro SD cards would break, along with a range of other quality of life issues.

Next, the SD card was put into a slot on the carrier PCB that featured its own edge connector. This improved matters, but the overly complicated (moving) read head in the reader turned out to be very unreliable, in addition to FDM printed parts having general tolerance and durability issues. Eventually a simplified design which takes these limitations in mind was created that so far seems to work just fine.

Although SD cards in cartridges are not a new idea, using them purely as a data carrier is far less common. One could argue about the practicality of turning a fingernail-sized micro SD card into something much larger, but in terms of aesthetics and handleability it definitely gets an A+.

When we talk about audio amplifier tubes, we’re normally talking about the glass little blobby things you might find in a guitar amplifier. We’re not normally talking about big ol’ color CRTs, but apparently they can do the job too. That’s what [Termadnator] is here to show us.

The CRT in question is a 14″ unit from a common garden variety Philips color TV.  [Termadnator] pulled out the TV’s original circuitry, and replaced much of it with his own. He had to whip up a high-voltage power supply with a 555 and a laptop power supply, along with a bunch of fake MOSFETs pressed into service. He also had to build his own Leyden jar capacitor, too. The specifics of converting it to audio operation get a bit messy, but fear not—[Termadnator] explains the idea well, and also supplies a schematic. Perhaps the coolest thing, though, is the crazy color pattern that appears on the display when it’s working as an amp.

Sound output isn’t exactly loud, and it’s a little distorted, too. Still, it’s amusing to see an entire TV instead doing the job of a single amplifier tube. Video after the break.

[Thanks to bugminer for the tip!]

Although commonly referred to as a ‘timer IC’, the venerable NE555 and derivatives are in fact not timer ICs. This perhaps controversial statement is the open door that gets kicked in by [PKAE Electronics] over at YouTube, as he explains with excellent diagrams and simulations how exactly these ICs work, and what it takes to make it actually do timer things. For anyone who has ever used one of these chips there is probably nothing too mind-blowing, but it’s an infinitely better way to wrap your way around an NE555 and kin than a datasheet.

At its core, the 555 contains three 5 kOhm resistors as a voltage divider, which has been incorrectly postulated to be the source of the chip’s name. This voltage divider controls two comparators, which in turn control an SR flipflop. These comparators are used for the voltage trigger and threshold inputs, which in turn toggle the flipflop, respectively setting and resetting it. This by itself just means that the 555 can be used as a threshold detector, with settable control voltage. How a 555 becomes a timer is when the discharge, trigger and threshold pins are combined with external resistors and a capacitor, which creates a smooth square wave on the 555’s output pin.

There are many ways to make basic components into an oscillator of some type, but the 555 is a great choice when you want something more refined that doesn’t involve using an entire MCU. That said, there’s far more that the 555 can be used for, as [PKAE] alludes to, and we hope that he makes more excellent videos on these applications.

We have to admit that we often think about building unusual things, but we hadn’t really considered building our own hydroelectric dam before. [Mini Construction] did, apparently, and there’s a timelapse of the build in the video below.

We wished this was more of a how-to video, although if you are handy with brickwork, the mechanical construction seems straightforward. Presumably, you’d need to understand how much force the water had but we don’t know if there was math involved or just seat-of-the-pants design.

We were unclear what the tower was for until we saw the turbine installed in it. We weren’t clear where it came from, and it looked like maybe it was repurposed from something else. If you recognize what it is, or have a guess, drop a comment, will you? While the brickwork was impressive, the wiring — especially near water — looked a bit suspect. We hope that was just test wiring and a more permanent arrangement was made later.

We have seen hacker hydroelectric before, but rarely. Waterwheels seem much more common. Honestly, the masonry work was the best we’ve seen since [Walt] built a bomb shelter.

Some time ago [Kelton] was working on a clock inspired by Rube Goldberg contraptions. It uses only a single motor, and he’s proud to now show off the finished product (video, embedded below.)

The clock shows hours on the left, and minutes on the right. Every sixty minutes the clock drops a marble. That marble kicks off a series of visually-satisfying operations that culminate in advancing the hour. Then everything resets, and it continues for as long as it has power.

At the top of each hour, the minute hand tips a marble with a gravity cam. That marble runs down a track gaining enough momentum to flip a kicker, and a short series of falling dominoes builds enough force to tip and trigger the spring-loaded ratchet that locks in a new hour. You can skip directly to 2:09 if you just want to listen to [Kelton] explain the whole operation from beginning to end.

We think it’s very interesting to note that this clock’s complexity is, if anything, understated. Each of the mechanisms involved must individually reset by their own separate mechanisms, each of which are as intriguing as their showier counterparts, and we’re sure they were every bit as difficult to get just right. And of course, it’s all driven by a single motor.

You may recall the promising start this clock project was off to and we’re delighted to see it come to completion, especially considering its complexity. Not every project sees completion, and fewer still get a version two, but that’s okay. What really floats our boat is seeing the process and details as well as hearing about what worked and what didn’t. We’re glad this clock reached the finish line, but even if something doesn’t work out, there’s always something to learn.

In case you haven’t heard, about a month ago MicroPython has celebrated its 11th birthday. I was lucky that I was able to start hacking with it soon after pyboards have shipped – the first tech talk I remember giving was about MicroPython, and that talk was how I got into the hackerspace I subsequently spent years in. Since then, MicroPython been a staple in my projects, workshops, and hacking forays.

If you’re friends with Python or you’re willing to learn, you might just enjoy it a lot too. What’s more, MicroPython is an invaluable addition to a hacker’s toolkit, and I’d like to show you why.

Hacking At Keypress Speed

Got a MicroPython-capable chip? Chances are, MicroPython will serve you well in a number of ways that you wouldn’t expect. Here’s a shining example of what you can do. Flash MicroPython onto your board – I’ll use a RP2040 board like a Pi Pico. For a Pico, connect an I2C device to your board with SDA on pin 0 and SCL on pin 1, open a serial terminal of your choice and type this in:

>>> from machine import I2C, Pin
>>> i2c = I2C(0, sda=Pin(0), scl=Pin(1))
>>> i2c.scan()

This interactivity is known as REPL – Read, Evaluate, Print, Loop. The REPL alone makes MicroPython amazing for board bringup, building devices quickly, reverse-engineering, debugging device library problems and code, prototyping code snippets, writing test code and a good few other things. You can explore your MCU and its peripherals at lightning speed, from inside the MCU.

When I get a new I2C device to play with, the first thing I tend to do is wiring it up to a MicroPython-powered board, and poking at its registers. It’s as simple as this:

>>> for i in range(16):
>>>     # read out registers 0-15
>>>     # print "address value" for each
>>>     print(hex(i), i2c.readfrom_mem(0x22, i))
>>> # write something to a second (0x01) register
>>> i2c.writeto_mem(0x22, 0x01, bytes([0x01]) )

That i2c.scan() line alone replaces an I2C scanner program you’d otherwise have to upload into your MCU of choice, and you can run it within three to five seconds. Got Micropython running? Use serial terminal, Ctrl+C, and that will drop you into a REPL, just type i2c.scan() and press Enter. What’s more, you can inspect your code’s variables from the REPL, and if you structure your code well, even restart your code from where it left off! This is simply amazing for debugging code crashes, rare problems, and bugs like “it stops running after 20 days of uptime”. In many important ways, this removes the need for a debugger – you can now use your MCU to debug your code from the inside.

Oh, again, that i2c.scan()? You can quickly modify it if you need to add features on the fly. Want addresses printed in hex? (hex(addr) for addr in i2c.scan()). Want to scan your bus while you’re poking your cabling looking for a faulty wire? Put the scan into a while True: and Ctrl+C when you’re done. When using a typical compiled language, this sort of tinkering requires an edit-compile-flash-connect-repeat cycle, taking about a dozen seconds each time you make a tiny change. MicroPython lets you hack at the speed of your keyboard typing. Confused the pins? Press the `up` button, edit the line and run the i2c = line anew.

To be clear, all of code is running on your microcontroller, you just type it into your chip’s RAM and it is executed by your MCU. Here’s how you check GPIOs on your Pi Pico, in case you’re worried that some of them have burnt out:

>>> from machine import Pin
>>> from time import sleep
>>> pin_nums = range(30) # 0 to 29
>>> # all pins by default - remove the ones connected to something else if needed
>>> pins = [Pin(num, Pin.OUT) for num in pin_nums]
>>> 
>>> while True:
>>>   # turn all pins on
>>>   for i in range(len(pins)):
>>>     pins[i].value(True)
>>>   sleep(1)
>>>   # turn all pins off
>>>   for i in range(len(pins)):
>>>     pins[i].value(False)
>>>   sleep(1)
>>>   # probe each pin with your multimeter and check that each pin changes its state

There’s many things that make MicroPython a killer interpreter for your MCU. It’s not just the hardware abstraction layer (HAL), but it’s also the HAL because moving your code from board to board is generally as simple as changing pin definitions. But it’s all the other libraries that you get for free that make Python awesome on a microcontroller.

Batteries Included

It really is about the batteries – all the libraries that the stock interpreter brings you, and many more that you can download. Only an import away are time, socket, json, requests, select, re and many more, and overwhelmingly, they work the same as CPython. You can do the same r = requests.get("https://retro.hackaday.com"); print(r.text)[:1024] as you would do on desktop Python, as long as you got a network connection going on. There will be a few changes – for instance, time.time() is an integer, not a float, so if you need to keep track of time very granularly, there are different functions you can use.

Say, you want to parse JSON from a web endpoint. If you’re doing that in an Arduino environment, chances are, you will be limited in what you can do, and you will get triangle bracket errors if you mis-use the JSON library constructs because somehow the library uses templates; runtime error messages are up to you to implement. If you parse JSON on MicroPython and you expect a dict but get a list in runtime, it prints a readable error message. If you run out of memory, you get a very readable MemoryError printed out, you can expect it and protect yourself from it, even fix things from REPL and re-run the code if needed.

The user-supplied code is pretty good, too. If you want PIO or USB-HID on the RP2040, or ESP-CPU-specific functions on the ESP family, they are exposed in handy libraries. If you want a library to drive a display, it likely already has been implemented by someone and put on GitHub. And, if that doesn’t exist, you port one from Arduino and publish it; chances are, it will be shorter and easier to read. Of course, MicroPython has problems. In fact, I’ve encountered a good few problems myself, and I would be amiss not mentioning them.

Mind The Scope

In my experience, the single biggest problem with MicroPython is that writing out `MicroPython` requires more of my attention span than I can afford. I personally shorten it to uPy or just upy, informally. Another problem is that the new, modernized MicroPython logo has no sources or high-res images available, so I can’t print my own stickers of it, and MicroPython didn’t visit FOSDEM this year, so I couldn’t replenish my sticker stock.

On a more serious note, MicroPython as a language has a wide scope of where you can use it; sometimes, it won’t work for you. An ATMega328P can’t handle it – but an ESP8266 or ESP32 will easily, without a worry in the world, and you get WiFi for free. If you want to exactly control what your hardware does, counting clock cycles or hitting performance issues, MicroPython might not work for you – unless you write some Viper code.

If you want to have an extremely-low-power MCU that runs off something like energy harvesting, MicroPython might not work – probably. If you need your code run instantly once your MCU gets power, mind the interpreter takes a small bit of time to initialize – about one second, in my experience. If you want to do HDMI output on a RP2040, perhaps stick to C – though you can still do PIO code, there are some nice libraries for it.

Some amount of clock cycles will be spent on niceties that Python brings. Need more performance? There are things you can do. For instance, if you have a color display connected over SPI and you want to reduce frame rendering time, you might want to drop down to C, but you don’t have to ditch MicroPython – just put more of your intensive code into C-written device drivers or modules you compile, and, prototype it in MicroPython before you write it.

As Seen On Hackaday

If you’ve followed the USB-C PD talking series, you must’ve seen that the code was written in MicroPython, and I’ve added features like PD sniffing, DisplayPort handling and PSU mode as if effortlessly; it was just that easy to add them and more. I started with the REPL, a FUSB302 connected to a RP2040, poking at registers and reading the datasheet, and while I needed outside help, the REPL work was so so much fun!

There’s something immensely satisfying about poking at a piece of technology interactively and trying to squeeze features out of it, much more if it ends up working, which it didn’t, but it did many other times! I’ve been hacking on that PD stack, and now I’m slowly reformatting it from a bundle of functions into object-based code – Python makes that a breeze.

Remember the Sony Vaio board? Its EC (embedded controller) is a RP2040, always powered on as long as batteries are inserted, and it’s going to be running MicroPython. The EC tasks include power management, being a HID over I2C peripheral, button and LED control, and possibly forwarding keyboard and trackpoint events to save a USB port from the second RP2040, which will run QMK and server as a keyboard controller. MicroPython allows me to make the firmware quickly, adorn it with a dozen features while I do it, and keep the codebase expandable on a whim. The firmware implementation will be a fun journey, and I hope I can tell about it at some point.

Have you used MicroPython in your projects? What did it bring to your party?

Ticketmaster is having a rough time lately. Recently, a hacker named [Conduition] managed to reverse-engineer their new “safe” electronic ticket system. Of course, they also had the recent breach where more than half a billion accounts had personal and financial data leaked without any indication of whether or not the data was fully encrypted. But we’re going to focus on the former, as it’s more technically interesting.

Ticketmaster’s stated goals for the new SafeTix system — which requires the use of a smartphone app — was to reduce fraud and ticket scalping. Essentially, you purchase a ticket using their app, and some data is downloaded to your phone which generates a rotating barcode every 15 seconds. When [Conduition] arrived at the venue, cell and WiFi service was totally swamped by everyone trying to load their barcode tickets. After many worried minutes (and presumably a few choice words) [Conduition] managed to get a cell signal long enough to update the barcode, and was able to enter, albeit with a large contingent of similarly annoyed fans trying to enter with their legally purchased tickets.

The real kicker here is that since the barcode rotates every 15 seconds, printing it out simply isn’t an option. This alienates anyone who doesn’t have a smartphone, which includes individuals who may not be able to physically operate one. So the problem isn’t simply that users were being forced to install yet another application on their device, but that the system reduces accessibility to entertainment. [Conduition] was dismayed and frustrated with this, and so the reverse-engineering effort began.

Decoding the barcode was actually quite simple. It is a standard PDF417 barcode, which contains a long Base64 string, two six-digit numbers, and a Unix timestamp all concatenated together with colons. The only parts of the string that seemed to change over time were the two six-digit numbers. Hmm, can we think of a common technology which generates six-digit numbers that update seemingly randomly on a fixed cycle? Of course — it’s just a Time-based one-time password (TOTP), the technology behind 2FA authenticator apps!

So where were the secret keys coming from? TOTP only requires two things: a static secret string, and the current time. [Conduition] checked the communication with the Ticketmaster servers and found a particularly interesting request that returned JSON-formatted data, inside which were of course the two secret keys. One seems to be unique per customer, and the other per ticket.

The Ticketmaster API documentation only briefly mentions this feature, but they do state that customers must refresh their ticket barcodes within 20 hours before an event starts. These two pieces of information were enough to allow [Conduition] to whip up a simple app that accepts the secret keys and the ticket ID and pops out the rotating barcodes. This would allow you to sell your tickets in the 20 hours prior to an event, or even just give them away to friends without having to give their personal data to Ticketmaster and allow you to take back control of your tickets.

Thanks to [Chrischi] for the tip!

Here at Hackaday, we take pride in presenting the freshest hacks and the best of what’s going on today in the world of hardware hacking. But sometimes, we stumble upon a hack from the past so compelling that we’ve got to bring it to you, so we can all marvel at what was possible in the Before Times.

This one, a completely homebrewed automatic photometric telescope, was designed and built by the father-son team of [Jack Ells] and [Peter Ells]. From the elder [Ells]’ field notes, the telescope saw its first light in 1988, giving us some idea of the scale of problems that had to be overcome to get this wonderful machine working. The optics are straightforward, as least as telescopes go — it’s an f-4.0 Newtonian reflector with an 8.5″ (221 mm) primary mirror on an equatorial mount. The telescope is very rugged-looking indeed, and even stands on brick piers for stability. The telescope’s mount is controlled by a BBC Micro running custom BASIC software.

For the photometric parts, the [Ells] boys installed a photo-multiplier tube at the focus of the telescope. More precisely, they used a liquid light guide to connect the eyepiece to a rack full of equipment, which included the PM tube, its high-voltage power supply, and a series of signal conditioners and counter circuits. The idea was to view a single star through a pinhole mask over the objective of the telescope and count the rate of photons received over time. Doing so would reveal periodic changes in the star’s brightness. Today we’d use similar data to search for exoplanet transits; while we don’t think that was a thing back in 1988, it looks like this telescope could easily have handled the job.

Sadly, [Jack Ells] died only two years after finishing the telescope. But he left it with his son, who eventually moved it to a location with better seeing conditions, where it gathered data for another eight years. The quality of the work is amazing, and as father-son projects go, this one is tough to beat.

The original Xbox forever changed the console world, because it was basically just PC components laced together in a slightly different architecture. It featured a Pentium 733 MHz CPU with just 64MB of RAM. [Prehistoricman] has been hard at work, figuring out how to up that to 256MB instead.

This isn’t [Prehistoricman’s] first rodeo. Previously, he managed to up the Xbox’s RAM to 128 MB. To figure out how to go further, he had to figure out the addressing scheme. A datasheet for the Xbox’s original memory chip was a help in this regard, as was the envytools project and an Xbox source code leak.

A BIOS hack was needed to move the auto-precharge pin to free up more address pins for the higher memory space. Furthermore, the only available memory chips that were suitable used BGA packages, so a small PCB with castellated edges was needed to adapt the chip to the Xbox’s motherboard, which expects a TQFP package.

Ultimately, getting this hack to work involved a lot of bare-metal hacking. It also won’t help the performance of commercial games at all, as they were all designed within the limitations of the original console. Still, it’s impressive to see this now-ancient platform hacked to do more. It’s also hilarious to compare it with a contemporary PC, which could simply accept 256 MB of RAM by using additional memory slots. Video after the break.

[Thanks to Stephen Walters for the tip!]

We’ve all been there. You are on a flight, there’s WiFi, but you hate to pay the few bucks just to watch dog videos. What to do? Well, we would never suggest you engage in theft of service, but as an intellectual exercise, [Robert Heaton] had an interesting idea. Could the limited free use of the network be coopted to access the general internet? Turns out, the answer is yes.

Admittedly, it is a terrible connection. Here’s how it works. The airline lets you get to your frequent flier account. When there, you can change information such as your name. A machine on the ground can also see that change and make changes, too. That’s all it takes.

It works like a drop box. You take TCP traffic, encode it as fake information for the account and enter it. You then watch for the response via the same channel and reconstitute the TCP traffic from the remote side. Now the network is at your fingertips.

There’s more to it, but you can read about it in the post. It is slow, unreliable, and you definitely shouldn’t be doing it. But from the point of view of a clever hack, we loved it. In fact, [Robert] didn’t do it either. He proved it would work but did all the development using GitHub gist as the drop box. While we appreciate the hack, we also appreciate the ethical behavior!

Some airlines allow free messaging, which is another way to tunnel traffic. If you can connect to something, you can probably find a way to use it as a tunnel.