The Attack Shark is a modern keyboard with fancy magnetic keyswitches, macros, configurable blinky LEDs, and more. The problem is that the configuration software only works on Windows, so [JR Lanteigne] set out to fix that. Along the way, he completely worked out the configuration protocol that this keyboard needs, and wrote the comfortable sharkfin web-app so that you can flash yours too.
Don’t have an Attack Shark? Well, you might have one of the 522 other boards that are made on the same ROYUAN hardware, but are re-branded under 100 different names. Want to find out if yours is supported? Look it up in the list here, or just plug it in and find out.
[RJ]’s path to reverse engineering the config protocol wasn’t entirely straightforward, but since the “Windows only” application was actually an Electron app under the hood, he patched it to run on Linux and logged a few configuration sessions. Of course there are gotchas like two different firmware generations and the fact that writing to flash too fast put the keyboard into a boot loop, but after these problems were surmounted, it just remained to map all of the bytes out, and wrap it all up in a user-friendly application.
We don’t have one of these fancy-schmancy keyboards, but if we did, we’d certainly be glad to have the configuration protocol documented. Nothing is worse than finding out that the company that made your keyboard has gone belly-up, and you’re left with a backlight setup that doesn’t match your new deskpad. If you’re a keyboard-head and you don’t already follow [Kristina]’s series, well you should.
There are many ways to soft-brick a device to the point where it cannot easily be used again, and “Cloud locks” or parental locks are probably at the top of the list here. [eWastelander] recently got an XBox 360 console for a mere $15 that had been tossed out without removing said parental lock. This led him down the fun path of exploring just how deep this lock goes that’s supposed to keep little Timmy from doing naughty things on the family gaming console.
The short version is that, unless you want to go medieval on the hardware and perform a NAND Flash-level reset, your best bet is probably to brute-force the pass code. You do not even have to mash in the thousands of codes yourself, but can use a keyboard emulator on something like a Teensy development board. This got [eWastelander] into the console after a mere five hours of the little MCU running through the combinations.
There used to be a reset code as well, as detailed over at Console Mods, but this is unique to each console and this feature got removed in newer firmware revisions. In the video, attempts to modify the console via a soft mod failed due to the compromised games that provide a backdoor not being ‘Everyone’ rated, which is probably a common outcome here.
Ultimately it seems that either you plug in an MCU board or you break out the NAND Flash programmer. Brute-forcing the XBox 360 pass code is something that we covered back in 2013 already, with in 2020 [Agent24] porting the code to the Teensy, with the code download link provided in the video description. Since Microsoft long since stopped providing the reset service via its support, this might be the only way to revive an otherwise junk XBox 360.
With a recent change that removed dialog in favor of bsddialog, FreeBSD has now retired the last piece of GPL-licensed code in its base system. Although the impact of this change will be minor for users, it does highlight once again the Open Source divide that has split developers since the 1990s, when [Linus Torvalds] attached a scribbled set of notes to the v0.01 Linux kernel release that would later be replaced with the very similar GPL license and its derivatives.
This history and its impacts are also the subject of a recent video by [Brodie Robertson]. For the FreeBSD project the biggest change here is probably that the entire GNU subtree in the codebase is now gone, As detailed in the video, this is the end of a very long-running project, whereby FreeBSD in its early days incorporated GNU code for userland tools. These components and its replacements are detailed in the FreeBSD wiki.
Naturally, this change has upset some people for reasons best known to themselves, but from a project management perspective this makes a lot of sense. Not having BSD-incompatible licenses like GPL in your source code massively simplifies matters. The main difference being that the GPL is reciprocal, requiring that derivative works also be released under the GPL — a feature that is often at odds with commercial projects. Meanwhile, the BSD licenses merely require the use of BSD-licensed code to be declared.
The upshot of the BSD-license in the case of FreeBSD is that it has found it and its components used in many commercial products, including MacOS/OS X, the PlayStation’s Orbis OS, and of course the BSD networking stack is happily used in Windows, macOS and just about anywhere else. Meanwhile the GPL forced Linksys to open the firmware to its WRT54G series of routers, ultimately leading to the development of OpenWrt and similar projects.
Although the OSS licensing flamewars will likely never end, it’s hard to disagree that FreeBSD is pretty healthy at over thirty years old, even if using it as a desktop OS comes with a few asterisks.
At the 2024 Electromagnetic Field event in the UK, some awkward items turned up at the swap meet: radioactive sources. Fortunately there was [Tryst] at hand, who works in the nuclear industry, so they were safely collected. At this year’s EMF he was back, with a talk about what happened next.
It seems they were an industrial version of the smoke detectors we’ll all be familiar with, containing the same Americium alpha emitters, but in greater quantity. Their path from industry to hacker camp is purposefully shrouded in mystery to avoid future incidents happening because people are scared to come forward, but it seems that but for a bit of post-Brexit regulatory chaos they would normally have been taken back by their Danish manufacturer for disposal.
We’re treated to a fascinating deep dive into radioactive source regulation and just what these sources are. In short, they’re not too dangerous as they are, but what makes them a worry is that they can easily be dismantled and their contents released. Ingestion of alpha particle emitters is a particular worry, so they must be kept safe and accounted for. Which leaves [Tryst] with a set of radioactive sources that sit in a regulatory grey area and can’t easily be disposed of. He ends by asking for suggestions as to how they might be used, of which we favor a true random number generator.
Light-hearted interludes aside, this is a cautionary tale for all of us who delight in digging through technological junk, and we are lucky that our community includes people with the expertise to do something about items like these. The full talk is below the break.
With human bodies being bags of mostly salty water and countless messy biochemical processes, it’s little wonder that over time some residues tend to collect in these systems. Although evolution has seen fit to also evolve a range of mechanisms to clean up many of those messes, some of these waste products are left to gather, such as advanced glycation end-products (AGEs). Implicated in everything from diabetes to chronic kidney disease and general aging-related conditions, recently researchers have developed a way to break down one type of these AGEs.
Called N(6)-Carboxymethyllysine (CML), there is evidence to suggest that the presence of AGEs like it in the extracellular matrix (ECM) has damaging effects on the ECM’s functioning, as observed in e.g. the inhibiting of collagen crosslinking and the resulting ‘aging’ of skin among other tissues. Essentially these waste product jam up the normal biochemical machinery, while also triggering pro-inflammatory factors.
Beyond aging-related conditions, this can result in a whole range of other diseases that may be resolved if these waste products could be cleaned out. To this end [Narisa Trabosh] et al. of the San Francisco-based Revel Pharmaceuticals laboratory created CMLase, an enzyme that breaks down CML.
Arterial tissue treated with the CMLase enzyme shows a clear difference. (Credit: Trabosh et al., Nature communications, 2026)
The challenge here was to design this enzyme, which used a genetic selection approach in modified E. coli to narrow down suitable enzymes, optimized for dealing with free CML. Once they were fairly confident that they had a working enzyme, they had to test it and observe the results.
This testing was performed in model proteins in vitro, as well as in tissue samples from elderly donors. These latter included lens, skin and arterial tissue, all of which are long-lived tissues that have plenty of time to collect CML. After treatment with CMLase the presence of CML in these tissues was reduced by 55% for skin and 75% for arterial tissue.
Of course, as also noted in the article these are ex vivo experiments that do not yet directly translate to living patients. An initial human trial would need to show safety above all, even if the amount of waste produced by the clean-up of CML won’t be that significant.
Subsequent trials would need to demonstrate that such removal of CML leads to healthier tissues, which if confirmed would open the path for other pathogenic AGEs to get their own matching enzyme.
Back in the early 1980s when 8-bit home computers became affordable educational toys for children, the traditional paper publishing industry did its best to keep up. For a few brief years, there were children’s books dedicated to the innards of a computer in meticulous detail, and courtesy of [Jason Jacques] we have a chance to look at one of the lesser-known ones.
The British publisher Ladybird made a series of four computer books, and while the first three had content for both the Sinclair Spectrum and the BBC Micro, the last in the series only featured the BBC. [Jason] took that book and re-imagined the missing Sinclair Spectrum version.
The surprise is how deep it dives into the architecture of an 8-bit computer, and it’s refreshing to see something that’s not unduly dumbed-down for kids. We’re guessing that this would have appealed to the 5% of kids who ran with their computers rather than just playing Jet Set Willy back then, and we’re sure a few grown-up 50-somethings may remember it or books like it.
After getting his hands on a rope driver module from the Apollo project era that had a big ‘Scrapped Module’ stamped on it, [Mike Stewart] was naturally left curious as to what exactly had failed in this module. Originally destined for the Apollo Guidance Computer, these Raytheon-manufactured modules were the pinnacle of space-grade high-tech of the 1960s, with requisite acceptance testing so as to not endanger a very expensive space mission.
The cool part here is that the acceptance documents for the module in question (B16-B17) have been scanned in and can be found on the Internet Archive. With the part itself being potted and very much inaccessible, this document helpfully lays out the expected measurements on the module’s pins, as well as schematics and mechanical drawings. Unfortunately the reasons for the rejection were not recorded, so replicating the failing test results is required to understand the reason.
NASA Rope Driver Module with suspicious exploration marks. (Credit: Mike Stewart, YouTube)
A slight complication here is that the testing procedure doesn’t just involve hooking up a multimeter for some voltage and capacitance measurements. There are also temperature and voltage extremes, and vibration tolerance involved, which would be somewhat complex to test, but most of all risk damaging a historical artefact. Thus a somewhat conservative testing procedure was chosen, even if this may not reveal the actual fault.
As noted in the video, sometimes modules were also rejected because someone simply dropped it on the floor along the way. However, generally if a module was found to be faulty they would open it to diagnose said fault, with a closer look at this module indeed revealing suspicious marks in the potting compound where it was apparently opened and conceivably repaired. This also might explain why they also put the ‘For engineering use only’ on it.
With multiple of such locations visible in the potting compound, these locations were mapped to the schematics for the module, to get some idea of what may have been accessed. After this, basic testing was performed on the module, as per the acceptance testing document.
Along the way an error was detected in said document, in the form of the wrong pin number. In table 4-2 the input pin 269 was mistakenly listed as having output pin number 169 when it should have been pin 168. Pin 169 is chassis ground, so this was presumably fixed in a later version of the document.
After all the testing with just stationary, room-temperature conditions, everything appeared to check out. This means that likely this was indeed a repaired module that got subsequently used for engineering purposes rather than installed in flight-ready hardware. The only issue found was that channels were out of calibration, but whether this was an original flaw or due to the module being half a century old is hard to tell in the absence of repair logs.
Overall it’s an exciting opportunity to document another part of history, since so many of the details pertaining to these original modules and related technologies got lost or muddled over the decades.
