AF114 germanium transistors and related ones like the AF115 through AF117 were quite popular during the 1960s, but they quickly developed a reputation for failure. This is due to what should have made them more reliable, namely the can shielding the germanium transistor inside that is connected with a fourth ‘screen’ pin. This failure mode is demonstrated in a video by [Anthony Francis-Jones] in which he tests a number of new-old-stock AF-series transistors only for them all to test faulty and show clear whisker growth on the can’s exterior.

Naturally, the next step was to cut one of these defective transistors open to see whether the whiskers could be caught in the act. For this a pipe cutter was used on the fairly beefy can, which turned out to rather effective and gave great access to the inside of these 1960s-era components. The insides of the cans were as expected bristling with whiskers.

The AF11x family of transistors are high-frequency PNP transistors that saw frequent use in everything from consumer radios to just about anything else that did RF or audio. It’s worth noting that the material of the can is likely to be zinc and not tin, so these would be zinc whiskers. Many metals like to grow such whiskers, including lead, so the end effect is often a thin conductive strand bridging things that shouldn’t be. Apparently the can itself wasn’t the only source of these whiskers, which adds to the fun.

In the rest of the video [Anthony] shows off the fascinating construction of these germanium transistors, as well as potential repairs to remove the whisker-induced shorts through melting them. This is done by jolting them with a fairly high current from a capacitor. The good news is that this made the component tester see the AF114 as a transistor again, except as a rather confused NPN one. Clearly this isn’t an easy fix, and it would be temporary at best anyway, as the whiskers will never stop growing.

Who knows what you’ll find in a second-hand shop? [Zeal] found some old keyboards made to fit early Alcatel phones from the year 2000 or so. They looked good but, of course, had no documentation. He’s made two videos about his adventure, and you can see them below.

The connector was a cellphone-style phone jack that must carry power and some sort of serial data. Inside, there wasn’t much other than a major chip and a membrane keyboard. There were a few small support chips and components, too.

This is a natural job for a logic analyzer. Sure enough, pressing a key showed some output on the logic analyzer. The device only outputs data, and so, in part 2, [Zeal] adds it to his single-board Z-80 computer.

It makes a cute package, but it did take some level shifting to get the 5V logic to play nice with the lower-voltage keyboard. He used a processor to provide protocol translation, although it looks like you could have easily handled the whole thing in the host computer software if you had wanted to do so.

Truthfully, there isn’t much chance you are going to find this exact keyboard. However, the process of opening a strange device and reverse engineering what it is all about is classic.

Don’t have a logic analyzer? A scope might have been usable for this, but you can also build one for very little these days. Using a PS/2 keyboard isn’t really easier, by the way, it is just well-documented.

[Hunter Irving] is a talented hacker with a wicked sense of humor, and he has written in to let us know about his latest project which is to make a GameCube keyboard controller work with Animal Crossing.

This project began simply enough but got very complicated in short order. Initially the goal was to get the GameCube keyboard controller integrated with the game Animal Crossing. The GameCube keyboard controller is a genuine part manufactured and sold by Nintendo but the game Animal Crossing isn’t compatible with this controller. Rather, Animal Crossing has an on-screen keyboard which players can use with a standard controller. [Hunter] found this frustrating to use so he created an adapter which would intercept the keyboard controller protocol and replace it with equivalent “keypresses” from an emulated standard controller.

In this project [Hunter] intercepts the controller protocol and the keyboard protocol with a Raspberry Pi Pico and then forwards them along to an attached GameCube by emulating a standard controller from the Pico. Having got that to work [Hunter] then went on to add a bunch of extra features.

First he designed and 3D-printed a new set of keycaps to match the symbols available in the in-game character set and added support for those. Then he made a keyboard mode for entering musical tunes in the game. Then he integrated a database of cheat codes to unlock most special items available in the game. Then he made it possible to import images (in low-resolution, 32×32 pixels) into the game. Then he made it possible to play (low-resolution) videos in the game. And finally he implemented a game of Snake, in-game! Very cool.

If you already own a GameCube and keyboard controller (or if you wanted to get them) this project would be good fun and doesn’t demand too much extra hardware. Just a Raspberry Pi Pico, two GameCube controller cables, two resistors, and a Schottky diode. And if you’re interested in Animal Crossing you might enjoy getting it to boot Linux!

Thanks very much to [Hunter] for writing in to let us know about this project. Have your own project? Let us know on the tipsline!

Hold onto your hats, everyone — there’s stunning news afoot. It’s hard to believe, but it looks like over-reliance on chatbots to do your homework can turn your brain into pudding. At least that seems to be the conclusion of a preprint paper out of the MIT Media Lab, which looked at 54 adults between the ages of 18 and 39, who were tasked with writing a series of essays. They divided participants into three groups — one that used ChatGPT to help write the essays, one that was limited to using only Google search, and one that had to do everything the old-fashioned way. They recorded the brain activity of writers using EEG, in order to get an idea of brain engagement with the task. The brain-only group had the greatest engagement, which stayed consistently high throughout the series, while the ChatGPT group had the least. More alarmingly, the engagement for the chatbot group went down even further with each essay written. The ChatGPT group produced essays that were very similar between writers and were judged “soulless” by two English teachers. Go figure.

The most interesting finding, though, was when 18 participants from the chatbot and brain-only groups were asked to rewrite one of their earlier essays, with the added twist that the chatbot group had to do it all by themselves, while the brainiacs got to use ChatGPT. The EEGs showed that the first group struggled with the task, presumably because they failed to form any deep memory of their previous work thanks to over-reliance on ChatGPT. The brain-only folks, however, did well at the task and showed signs of activity across all EEG bands. That fits well with our experience with chatbots, which we use to help retrieve specific facts and figures while writing articles, especially ones we know we’ve seen during our initial scan of the literature but can’t find later.

Does anyone remember Elektro? We sure do, although not from personal experience, since the seven-foot-tall automaton built by Westinghouse for the World’s Fair in New York City in 1939 significantly predates our appearance on the planet. But still, the golden-skinned robot that made its living by walking around, smoking, and cracking wise at the audience thanks to a 78-rpm record player in its capacious chest, really made an impression, enough that it toured the country for the better part of 30 years and made the unforgettable Sex Kittens Go to College in 1960 before fading into obscurity. At some point, the one-of-a-kind robot was rescued from a scrap heap and restored to its former glory, and now resides in the North Central Ohio Industrial Museum in Mansfield, very close to the Westinghouse facility that built it. If you need an excuse to visit North Central Ohio, you could do worse than a visit to see Elektro.

It was with some alarm that we learned this week from Al Williams that mtrek.com 1701 appeared to be down. For those not in the know, mtrek is a Telnet space combat game inspired by the Star Trek franchise, which explains why Al was in such a tizzy about not being able to connect; huge Trek nerd, our Al. Anyway, it appears Al’s worst fears were unfounded, as we were able to connect to mtrek just fine. But in the process of doing so, we stumbled across this collection of Telnet games and demos that’s worth checking out. The mtrek, of course, as well as Telnet versions of chess and backgammon, and an interactive world map that always blows our mind. The site also lists the Telnet GOAT, the Star Wars Asciimation; sadly, that one does seem to be down, at least for us. Sure, you can see it in a web browser, but it’s not the same as watching it in a terminal over Telnet, is it?

And finally, if you’ve got 90 minutes or so to spare, you could do worse than to spend it with our friend Hash as he reverse engineers an automotive ECU. We have to admit that we haven’t indulged yet — it’s on our playlist for this weekend, because we know how to party. But from what Hash tells us, this is the tortured tale of a job that took far, far longer to complete than expected. We have to admit that while we’ll gladly undertake almost any mechanical repair on most vehicles, automotive ECUs and other electronic modules are almost a bridge too far for us, at least in terms of cracking them open to make even simple repairs. Getting access to them for firmware extraction and parameter fiddling sounds like a lot of fun, and we’re looking forward to hearing what Hash has to say about the subject.

The Humane AI Pin was ambitious, expensive, and failed to captivate people between its launch and shutdown shortly after. While the units do contain some interesting elements like the embedded projector, it’s all locked down tight, and the cloud services that tie it all together no longer exist. The devices technically still work, they just can’t do much of anything.

Since then, developers like [Adam Gastineau] have been hard at work turning the device into an experimental development platform: PenumbraOS, which provides a means to allow “untrusted” applications to perform privileged operations.

As announced earlier this month on social media, the experimental SDK lets developers treat the pin as a mostly normal Android device, with the addition of a modular, user-facing assistant app called MABL. [Adam] stresses that this is all highly experimental and has a way to go before it is useful in a user-facing sort of way, but there is absolutely a workable architecture.

When the Humane AI Pin launched, it aimed to compete with smartphones but failed to impress much of anyone. As a result, things folded in record time. Humane’s founders took jobs at HP and buyers were left with expensive paperweights due to the highly restrictive design.

Thankfully, a load of reverse engineering has laid the path to getting some new life out of these ambitious devices. The project could sure use help from anyone willing to pitch in, so if that’s up your alley be sure to join the project; you’ll be in good company.

Recently [Florin] was in the market for a basic uninterruptible power supply (UPS) to provide some peace of mind for the smart home equipment he had stashed around. Unfortunately, the cheap Serioux LD600LI unit he picked up left a bit to be desired, and required a bit of retrofitting.

To be fair, the issues that [Florin] ended up dealing with were less about the UPS’ capability to deal with these power issues, and more with the USB interface on the UPS. Initially the UPS seemed to communicate happily with HomeAssistant (HA) via Network UPS Tools over a generic USB protocol, after figuring out what device profile matched this re-branded generic UPS. That’s when HA began to constantly lose the connection with the UPS, risking its integration in the smart home setup.

After tearing down the UPS to see what was going on, [Florin] found that it used a fairly generic USB-serial adapter featuring the common Cypress CY7C63310 family of low-speed USB controller. Apparently the firmware on this controller was simply not up to the task or poorly implemented, so a replacement was needed.

The process and implementation is covered in detail in the video. It’s quite straightforward, taking the 9600 baud serial link from the UPS’ main board and using a Silabs CP2102N USB-to-UART controller to create a virtual serial port on the USB side. These conversion boards have to be fully isolated, of course, which is where the HopeRF CMT8120 dual-channel digital isolator comes into play.

After assembly it almost fully worked, except that a Sonoff Zigbee controller in the smart home setup used the same Silabs controller, with thus the same USB PID/VID combo. Fortunately in Silabs AN721 it’s described how you can use an alternate PID (0xEA63) which fixed this issue until the next device with a CP2102N is installed

As it turns out, the cost of a $40 UPS is actually 10 hours of work and $61 in parts, although one cannot put a value on all the lessons learned here.

While LEGO themed video games have become something of a staple, in 1997 they were something of an odity. LEGO Island became the first LEGO video game released outside of Japan in 1997 and become something of a hit with over one million copies sold. The game was beloved among fans and set the stage for more LEGO video games to come. In an effort of love, [MattKC] put together a team to reverse engineer the game.

The team set out with the intent to create a near perfect recreation of the codebase, relying on custom made tools to run byte checks on the rewrite compilation and the original binary. While the project is functionally complete, [MattKC] believes it is impossible to get a byte accurate codebase. This is because of what the team called “compiler entropy.” Strange behaviors exists inside of Microsoft’s Visual C++ compiler of the era, and small changes in the code have seemingly random effects to unrelated parts of the binary. To mitigate this issue would likely require either partially reverse engineering Visual C++ or brute forcing the code, both of which would take a large amount of effort and time for no real benefit.

Another interesting step the team had to work out was how the game handled graphics. In the version of Direct X used, the developers could chose between immediate mode and retained mode. The difference largely boils down to how models and assets are handled. In immediate mode, Direct X is largely just a render engine and everything else is handled by the developer. With retained mode, Direct X works more similarly to a game engine where all the model and asset management is handled by Direct X. Almost all developers ended up using immediate mode to the point that Microsoft deprecated support for retained mode. For this reason, if you were to download and run LEGO island on a modern Windows PC, it would yell at you for not having the proper libraries. There is debate about how best to handle this moving forward. The team could rely on an unsupported library from Microsoft, reverse engineer that library only making the functions needed, or using leaked source code.

With the completion of the reverse engineering, engineering can commence. For example, an annoying and persistent bug caused the game to crash if you tried to exit. While it was effective in closing the game, it also caused progress to be lost. That particular bug was fixed simply by initializing a variable in the game’s fronted. Interestingly, that bug was not present in the late betas of the game that had been dug up from the depths of the internet leading to questions as to why a rewrite of the fronted was necessary so late in the development. Now efforts are commencing to port the game to other platforms which bring with it fresh headaches including rewriting for OpenGL and the balance of keeping a historically accurate game with the needs of modern development.

Taking a break from his usual prodding at suspicious AliExpress USB chargers, [DiodeGoneWild] recently had a gander at what used to be a good USB charger.

Before it went completely dead, the Anker 737 GaNPrime USB charger which a viewer sent him was capable of up to 120 Watts combined across its two USB-C and one USB-A outputs. Naturally the charger’s enclosure couldn’t be opened non-destructively, and it turned out to have (soft) potting compound filling up the voids, making it a treat to diagnose. Suffice it to say that these devices are not designed to be repaired.

With it being an autopsy, the unit got broken down into the individual PCBs, with a short detected that eventually got traced down to an IC marked ‘SW3536’, which is one of the ICs that communicates with the connected USB device to negotiate the voltage. With the one IC having shorted, it appears that it rendered the entire charger into an expensive paperweight.

Since the charger was already in pieces, the rest of the circuit and its ICs were also analyzed. Here the gallium nitride (GaN) part was found in the Navitas GaNFast NV6136A FET with integrated gate driver, along with an Infineon CoolGaN IGI60F1414A1L integrated power stage. Unfortunately all of the cool technology was rendered useless by one component developing a short, even if it made for a fascinating look inside one of these very chonky USB chargers.

Once a printed circuit board (PCB) has been assembled it’s rather hard to look inside of it, which can be problematic when you have e.g. a multilayer PCB of an (old) system that you really would like to dissect to take a look at the copper layers and other details that may be hidden inside, such as Easter eggs on inner layers. [Lorentio Brodeso]’s ‘LACED’ project offers one such method, using both chemical etching and a 5 Watt diode engraving laser to remove the soldermask, copper and FR4 fiberglass layers.

This project uses sodium hydroxide (NaOH) to dissolve the solder mask, followed by hydrogen chloride (HCl) and hydrogen peroxide (H₂O₂) to dissolve the copper in each layer. The engraving laser is used for the removing of the FR4 material. Despite the ‘LACED’ acronym standing for Laser-Controlled Etching and Delayering, the chemical method(s) and laser steps are performed independently from each other.

This makes it in a way a variation on the more traditional CNC-based method, as demonstrated by [mikeselectricstuff] (as shown in the top image) back in 2016, alongside the detailed setup video of how a multi-layer PCB was peeled back with enough resolution to make out each successive copper and fiberglass layer.

The term ‘laser-assisted etching’ is generally used for e.g. glass etching with HF or KOH in combination with a femtosecond laser to realize high-resolution optical features, ‘selective laser etching’ where the etchant is assisted by the laser-affected material, or the related laser-induced etching of hard & brittle materials. Beyond these there is a whole world of laser-induced or laser-activated etching or functionalized methods, all of which require that the chemical- and laser-based steps are used in unison.

Aside from this, the use of chemicals to etch away soldermask and copper does of course leave one with a similar messy clean-up as when etching new PCBs, but it can provide more control due to the selective etching, as a CNC’s carbide bit will just as happily chew through FR4 as copper. When reverse-engineering a PCB you will have to pick whatever method works best for you.

Top image: Exposed inner copper on multilayer PCB. (Credit: mikeselectricstuff, YouTube)

If you talk about Starlink, you are usually talking about the satellites that orbit the Earth carrying data to and from ground stations. Why not? Space is cool. But there’s another important part of the system: the terminals themselves. Thanks to [DarkNavy], you don’t have to tear one open yourself to see what’s inside.

The terminal consists of two parts: the router and the antenna. In this context, antenna is somewhat of a misnomer, since it is really the RF transceiver and antenna all together. The post looks only at the “antenna” part of the terminal.

The unit is 100% full of printed circuit board with many RF chips and a custom ST Microelectronics Cortex A-53 quad-core CPU. There was a hack to gain root shell on the device. This led to SpaceX disabling the UART via a firmware update. However, there is still a way to break in.

[DarkNavy] wanted to look at the code, too, but there was no easy way to dump the flash memory. Desoldering the eMMC chip and reading it was, however, productive. The next step was to create a virtual environment to run the software under Qemu.

There were a few security questions raised. We wouldn’t call them red flags, per see, but maybe pink flags. For example, there are 41 trusted ssh keys placed in the device’s authorized_keys file. That seems like a lot for a production device on your network, but it isn’t any smoking gun.

We’ve watched the cat-and-mouse between Starlink and people hacking the receivers with interest.

Ever wondered what happens when you insert a bill into a vending machine? [Janne] is back with his latest project: reverse engineering a banknote validator. Curious about how these common devices work, he searched for information but found few resources explaining their operation.

To learn more, [Janne] explored the security features that protect banknotes from counterfeiting. These can include microprinting, UV and IR inks, holograms, color-shifting coatings, watermarks, magnetic stripes, and specialty paper. These features not only deter fraud but also enable validators to quickly verify a bill’s authenticity.

[Janne] purchased several banknote validators to disassemble and compare. Despite varied exteriors, their core mechanisms were similar: systems to move the bill smoothly, a tape head to detect magnetic ink or security strips, and optical sensors to inspect visible, UV, and IR features. By reverse engineering the firmware of two devices, he uncovered their inner workings. There is a calibration procedure they use to normalize their readings, then it will analyze a bill through a sophisticated signal processing pipeline. If the data falls within a narrow acceptance range, the device authenticates the bill; otherwise, it rejects it.

Head over to his site to check out all the details he discovered while exploring these devices, as well as exploring the other cool projects he’s worked on in the past. Reverse engineering offers a unique window into technology Check out other projects we’ve featured showcasing this skill.

Recently [Colin Leroy-Mira] found himself slipping into a bit of a rabbit hole while investigating why only under Apple II MAME emulation there was a lot of flickering when using the (emulated) Apple II MouseCard. This issue could not be reproduced on real (PAL or NTSC) hardware. The answer all comes down to how the card synchronizes with the system’s vertical blanking (VBL) while drawing to the screen.

The Apple II MouseCard is one of the many peripheral cards produced for the system, originally bundled with a version of MacPaint for the Apple II. While not a super popular card at the time, it nevertheless got used by other software despite this Apple system still being based around a command line interface.

According to the card’s documentation the interrupt call (IRQ) can be set to 50 or 60 Hz to match the local standard. Confusingly, certain knowledgeable people told him that the card could not be synced to the VBL as it had no knowledge of this. As covered in the article and associated MAME issue ticket, it turns out that the card is very much synced with the VBL exactly as described in The Friendly Manual, with the card’s firmware being run by the system’s CPU, which informs the card of synchronization events.

The fact that modern-day x86 processors still pretty much support the same operating systems and software as their ancestors did is quite a feat. Much of this effort had already been accomplished with the release of the 80386 (later 386) CPU in 1985, which was not only the first 32-bit x86 CPU, but was also backwards compatible with 8- and 16-bit software dating back to the 1970s. Making this work transparently was anything but straightforward, as [Ken Shirriff]’s recent analysis of the 80386’s main register file shows.

Using die shots of the 386’s registers and surrounding silicon, it’s possible to piece together how backwards compatibility was implemented. The storage cells of the registers are implemented using static memory (SRAM) as is typical, with much of the register file triple-ported (two read, one write).

Most interestingly is the presence of different circuits (6) to support accessing the register file for 8-, 16- or 32-bit writes and reads. The ‘shuffle’ network as [Ken] calls it is responsible for handling these distinct writes and reads, which also leads to the finding that the bottom 16 bits in the registers are actually interleaved to make this process work smoother.

Fortunately for Intel (and AMD) engineers, this feat wouldn’t have to be repeated again with the arrival of AMD64 and x86_64 many years later, when the 386’s mere 275,000 transistors on a 1 µm process would already be ancient history.

Want to dive even deeper in to the 386? This isn’t the first time [Ken] has looked at the iconic chip.

This project by [Miro] is awesome, not only did he build a replica Enigma machine using modern technologies, but after completing it, he went back and revised several components to make it more usable. We’ve featured Enigma machines here before; they are complex combinations of mechanical and electrical components that form one of the most recognizable encryption methods in history.

His first Enigma machine was designed closely after the original. He used custom PCBs for the plugboard and lightboard, which significantly cleaned up the internal wiring. For the lightboard, he cleverly used a laser printer on semi-transparent paper to create crisp letters, illuminated from behind. For the keyboard, he again designed a custom PCB to connect all the switches. However, he encountered an unexpected setback due to error stack-up. We love that he took the time to document this issue and explain that the project didn’t come together perfectly on the first try and how some adjustments were needed along the way.

The real heart of this build is the thought and effort put into the design of the encryption rotors. These are the components that rotate with each keystroke, changing the signal path as the system is used. In a clever hack, he used a combination of PCBs, pogo pins, and 3D printed parts to replicate the function of the original wheels.

Enigma machine connoisseurs will notice that the wheels rotate differently than in the original design, which leads us to the second half of this project. After using the machine for a while, it became clear that the pogo pins were wearing down the PCB surfaces on the wheels. To solve this, he undertook an extensive redesign that resulted in a much more robust and reliable machine.

In the redesign, instead of using pogo pins to make contact with pads, he explored several alternative methods to detect the wheel position—including IR light with phototransistors, rotary encoders, magnetic encoders, Hall-effect sensors, and more. The final solution reduced the wiring and addressed long-term reliability concerns by eliminating the mechanical wear present in the original design.

Not only did he document the build on his site, but he also created a video that not only shows what he built but also gives a great explanation of the logic and function of the machine. Be sure to also check out some of the other cool enigma machines we’ve featured over the years.