Sometimes, hacking requires a certain amount of restraint, especially when you find a system woefully unsecured. It would be so easy to play some pranks, but [bobdahacker] chose not to rickroll the entire FIFA World Cup.

The fun starts after [bobdahacker] signed up for a free FIFA agent profile. After a simple ID verification process, he had a login for the FIFA Agent platform, but they used the same account system across the whole organization in Microsoft Entra. When he tried to access the FIFA Football Data Platform system, it returned an error saying he had no assigned role to allow access. This was on the client side though, so he was able to bypass the error as the server didn’t block accounts without assigned roles.

Once inside, he found he was able to access not just the data, but had full control of the RTMP ingest URLs of all the FIFA matches. For those of us less conversant in streaming media protocols, “Those RTMP ingest URLs are the literal pipe from the stadium cameras to FIFA’s broadcast distribution chain. Camera -> RTMP ingest -> MediaKind -> broadcast partners -> your TV.” He could’ve shut off the feeds or injected whatever alternate stream he wanted, but instead chose to try contacting FIFA, their streaming contractor, and various law enforcement agencies since the World Cup was already underway when he made the discovery.

“Competitions, Matches, Teams, Tools, Exchange Platform, Analysis Dashboard, Commentator Information System, FIFA AI Pro, Admin” were also in the open. Live match scores could be changed, player bios, and any number of other stats could be modified. We’ll let you imagine the possibilities of what mischief could occur.

While rickrolling the world would be funny, a rickroll throwie will be a bit more circumspect. If you’re more interested in soccer/football than security hacks, we hope you enjoy this LEGO soccer tank or these robot soccer players and avoid any soccer ball-sized meteorites or legal troubles for your soccer-related invention.

Before the past year, many of us took computer memory for granted. It was one of the lower-cost parts of a PC build and was usually available in whatever quantity one desired. As its cost has skyrocketed, a lot of PC builders and other users of computers in general are taking a deeper look at memory, how much is really needed, and what its functions truly are. [Igor] is working on a drum sequencer project which needs a small amount of memory, and has built this dynamic RAM from discrete components.

The first video goes into the construction of the memory array and how its addressed. It’s only eight bytes total, and using fairly large electrolytic capacitors to store data means that a gigabyte of this memory would take up well over a thousand acres, but it’s still enough memory for [Igor]’s needs. In addition to the capacitor, each bit uses a pair of diodes to determine if a read or write is occuring, and a set of transistors on the read and write busses to perform those actions. Worth noting here is that dynamic RAM like this needs to be refreshed because the capacitors lose charge over time, but these large capacitors can hold charge sometimes overnight, as [Igor] has confirmed experimentally.

There’s a followup video to the construction of these modules as well, where [Igor] demonstrates a number of ways this module can be used, from controlling LED arrays, 7-segment displays, and then installs it into his drum machine. With 64 bits available it’s capable of creating up to eight beats with eight samples available per beat. Although there are complete machines available for all of this, we appreciate his goal of not buying any pre-manufactured hardware and instead constructing it all from the ground up. There are analog drum machine options available in this same style as well.

While there is a time and place for wirelessly controlled devices, sometimes you want something you can just reach out and touch to interact with, no apps to install or devices to configure. In this case [John] wanted a lamp that was just that. Drawing inspiration from the rotary phone, he created the LightComposer.

This small lamp, just a bit smaller than a hockey puck, uses a 3D printed enclosure and a straightforward PCB. It’s a very accessible project to recreate. The 3D prints are well thought out including a TPU ring on the bottom to keep the lamp from sliding around. The light source comes from 32 SK6812 LEDs, which are very similar to NeoPixels. An ATmega328P microcontroller powers the project and can easily be programmed using the Arduino IDE. A rotary encoder in the center, coupled to the top diffuser, lets you control LED brightness and color by turning it. The firmware also includes some fun hidden light-effect modes.

Head over to [John]’s site for all the files needed to make your own LightComposer, or links to buy a premade one. What devices have you made that use a straightforward physical user interface in lieu of an app? Be sure to check some of the other lamp builds we’ve featured before.

After recently publishing a few videos covering research into the poor adhesion between chopped carbon fiber (CCF) and the thermoplastic filaments as used with FDM 3D printing, some of the feedback received by [I built a thing] included the idea that the missing step to make CCF additives work was post-print annealing. Naturally this claim had to be investigated, both through the resulting physical characteristics as well as on a microscopic level in the same scanning electron microscope (SEM) as before.

Theories as to why annealing the parts would help here seem to focus on increased bonding and filling of voids in the printed CCF-infused material, while there are the typical worries with annealing such as parts warping and shrinking to also take into account as potential downsides of this treatment.

For the sample materials PETG and PETG-CF, as well as PLA and PLA-CF filaments are used, with each filament type featuring an annealed and not annealed version. These were then tested for tensile strength, stiffness and failure type, as well as dimensional accuracy and warping, before being examined under the SEM. A total of 160 samples were used, with 20 samples per material and annealing state.

Perhaps the biggest surprise here was how much PETG benefits from annealing, making it much more resilient to breaking, whereas neither PLA nor PLA-CF seemed to see much benefit. Shocking was how much worse PETG-CF performs than PETG, with the former being worse than both PLA and PLA-CF here.

In terms of dimensional accuracy, annealing caused a Z direction expansion while shrinking the samples in the  other directions. The CCF addition here actually prevented much of the shrinking and expansion, showing the first clear benefit of this additive. Yet despite annealing at right above the glass transition temperature as is proper, this would seem to be the limit of this approach in terms of practical benefits.

Compared to the previous research that focused on PLA-CF, PETG-CF would seem to make the case even more strongly that there’s no real purpose to CCF additives, especially since you can already account for parts shrinkage during annealing before printing. That there’s no improvement to the CCF and thermoplastic interface adhesion is also no mystery, considering the science behind how e.g. thermoset materials create bonds with CF.

Usually the term ‘jailbreaking’ isn’t meant to be taken quite that literally, but in the case of the US prison tablet that [Hugh Jeffreys] got sent, it’s really quite apt. Unlike the typical transparent prison electronics, this tablet is hermetically sealed inside an opaque plastic case, with the Windows 10 install firmly locked-down and not allowing anything more to be done with it than access some prison-provided services via the browser in kiosk mode.

The first challenge was to see whether it could be booted at all, with just four metal pads visible on the side of the case. These turn out to correspond to USB pins, but the tablet only briefly tries to turn on with a charger connected. This means that a teardown is required, which ended up involving a hacksaw due to the sealed case.

Inside the case is the Windows tablet with the back cover removed, presumably for easy access to extend its USB port. All of this is embedded in foam and more gunk that makes disassembly rather messy. With the case opened it becomes clear that the likely reason why this tablet was junked was due to a bad third-party charger board, as using the tablet’s own USB port it charges happily and even turns on.

From there it’s a bit of a fight with the locked-down Windows installation, but as it’s just a Windows 10 Home installation, there’s no drive encryption or such to get in the way. This allows for the device to be fully jailbroken, revealing its specifications as an Iview Optimus-C-8001, powered by an Intel Atom Z8350 at 1.44 GHz with a blistering 2 GB of RAM. The Windows installation was from 2018, with apparently no updates since.

Despite the very high school arts-and-crafts appearance of the case itself, the tablet itself isn’t too shabby considering the limited hardware specifications. Although getting the case off is a bit of a pain, it’s not a bad catch if you can find one of these puppies in the e-waste bin.

Modern video game consoles rarely have expansion ports, but in the 80s and 90s it was practically guaranteed. With the speed that hardware was advancing it made sense to build in some way to expand a system’s capabilities throughout its lifespan, like the memory port in the Nintendo 64 or the Sega CD and 32X attachments for the Sega Genesis. Some were ultimately unused as well, like the port under the Super Nintendo or, arguably, the interesting way that [decrazyo] figured out how to add graphics capabilities to the original Nintendo Entertainment System.

The basis of this upgrade is the fact that the Picture Processing Unit (PPU) on the NES has four pins that are grounded. These four pins tell the NES to display the background color if the pixel is transparent. Since they’re normally grounded, this means the NES can only display a limited background image, but there’s no reason these pins must be grounded. By using a second PPU configured to output graphics information and wiring it to these four pins on the first PPU, the NES can be given all kinds of new abilities, such as adding parallax effects to backgrounds, rendering more sprites, and showing more colors in the backgrounds.

Of course, the hardware requirements for this will require a donor NES to get the second PPU as well as the necessary memory chip for it, and we don’t recommend tearing apart perfectly good retro consoles for experimentation if it can be avoided. Presumably, you could use this open-source NES hardware alternative instead. But for those with the parts and the gumption, creating a demo or adding graphics features to homebrew games using this second graphics chip is within reach.

As great and streamlined as the Windows desktop experience is, one area where it’s at best disappointing and at worst rage-inducing is when it comes to its command line interface (CLI) offerings. In Windows 9x/ME this could be excused by the fact that it was essentially just a dressed-up MS-DOS CLI experience, but on Windows NT-based OSes no such excuse exists.

Yet even after Microsoft finally acknowledged the shortcomings of the cmd.exe shell by 2006, they then proceeded to go their own way with PowerShell, industry standards be damned. Especially for those of us who have no beef with the UNIX/BSD/Linux CLI experience and the joys of shell scripting, this insistence was disappointing. Simultaneously, everyone from OS X/MacOS to Haiku were happily offering a familiar CLI environment alongside POSIX compatibility.

Although Windows NT OSes were POSIX compliant, they never offered a suitable shell along with it, nor any of the other things you’d expect in a modern-day BSD, Haiku or Linux CLI environment. In a recent article by my esteemed colleague Al Williams, these sore points were somewhat addressed as far as basic CLI tools go, but the issue goes obviously much deeper than just the basic userland tools. Which is where MSYS2 comes into the picture.

Defining The Problem

When one says that they’d like a ‘Linux shell on Windows’, it can be hard to pin down exactly what this means. As Al noted in his article on CoreUtils last week, there are solutions like Cygwin that add a translation layer between Windows and Linux-ish code and offer a basic shell experience, but what if you really want to have a full Linux-like shell experience including support for common POSIX tools and libraries, as well as typical tooling like make and gcc?

Microsoft’s CoreUtils package gets you a GNU userland-like experience, but that’s arguably a small part of the whole issue. The reason why over the years I drifted away from Linux tools ported to Windows – as well as bailed on WSL, WSL2, Cygwin and full-fat VMs – is due the amount of friction these added when all that I wanted was to use a Bash-like shell for day-to-day tasks and general software development. For all intents and purposes I wanted to pretend that I was just on a modern Linux distro like Arch without having to fire up some special application with significant overhead or waddle over to one of my systems that have Linux installed.

This means a GNU-style userland, basic POSIX compatibility, being able to run shell scripts, having access to a package manager like on BSDs/Linuxes/Haiku/etc., ideally all in a way where it blends quite seamlessly into the overall Windows GUI experience. Essentially the laziest and most off-the-shelf experience possible, if you want.

This is where a full-fat VM is obviously too heavy and restricted, while WSL(2) also carries too many of the VM-related flaws with it, as it’s too much trying to be Linux instead of integrating with the Windows experience. The ideal solution here would probably feel more like the standard terminal on Haiku.

The MSYS2 Solution

With MSYS2 you can use the same pacman package manager you’d use on Arch/Manjaro to fetch packages. You’re also using a regular Bash shell and the only major hurdles you’re likely to run into concern limitations with low-level tools like Valgrind and some Windows-related quirks that the MSYS2 developers can’t do too much about because Microsoft. Internally it’s still based on Cygwin, so you can count on a similar level of compatibility, but without fuss.

For day-to-day use it’s a very familiar Linux-like experience for especially software-development purposes and common shell-based shenanigans like automation tasks and running a range of tools such as ffmpeg and yt-dlp, both of which are of course readily available from the package repository. In this sense MSYS2 adds a terminal and CLI environment that blurs the lines between BSD/Haiku/Linux and Windows, just the way us cross-platform developers like things, as this way you can use the same scripts and same know-how and muscle-memory across terminals and TTYs.

Perhaps the only negative here is again due to MSYS2 being not fully integrated into Windows, resulting in e.g. binaries compiled within an MSYS2 environment relying on shared libraries that are not on the Windows system path. This can be worked around by copying all the DLLs into the binary folder, or doing system path things, but it’s one of the reasons why I do distribute binary builds for Windows of my OSS projects that are compiled using NMake and MSVC.

The MSYS2 Environments

When you first install MSYS2, the most important thing to learn are the distinctions between the various MSYS2 environments. This is the first thing you see after happily installing MSYS2, finding yourself staring at a list of various terminal options, as summarized below. Over the years a number of these environments have been retired, in particular the 32-bit environments, but also the MinGW64 environment that used to be the primary one until Windows 10 added the Universal C Runtime (UCRT).

The MSYS2 environments page provides a lot more detail, but the brief summary is that you should just use the UCRT terminal. It builds upon the MSYS environment just like the other options, essentially setting up a number of defaults, with some of these listed in the above table. Although you can use the Clang environments, these aren’t nearly as mature or full-featured, so your mileage may vary there.

Development Features

My basic software development workflow involves Notepad++ to write code and a Makefile, and the use of an MSYS2 UCRT terminal to run make, along with gdb, grep and utilities such as ldd for happy-fun debugging purposes. When I do embedded development that targets e.g. STM32, I can fetch the entire GCC-based toolchain for ARM Cortex-M via pacman and use that in exactly the same way as I would in a Linux-based terminal or TTY.

I have always found doing such development things the ‘Windows way’ to be rather tedious and cumbersome, having spent considerable time in the past using environments like Visual Studio and other IDEs such as Code::Blocks. While any approach can be made to work, just being able to use the same shell scripts, same gdb configurations, and the same Makefiles. across FreeBSD, Linux, Haiku, and Windows saves a lot of time and effort as you never have to duplicate effort.

MSYS2 Limitations

As alluded to earlier, MSYS2 doesn’t integrate perfectly in Windows as it is still just a third-party application. It also only covers userland, so kernel-level drivers and tools like Valgrind will require a full-blown Linux system. However, unless I’m doing some crazy involved profiling or debugging I’ll generally just use Dr. Memory on Windows, which works the same as Valgrind and also has packages for Linux and MacOS.

Whether it’s a limitation or not I’m not entirely sure, but stdout in MSYS2 Bash also sometimes does seem to have trouble outputting where Bash or similar on BSD/Haiku/Linux does not, which is an issue that I still need to diagnose in more depth one day to file a ticket for. That said, having created issue tickets for the MSYS2 (packages) project in the past has at least made it clear that its developers are quite responsive and fairly tame.

These minor niggles aside, I’m quite grateful to the MSYS2 project for allowing me to have both the solid Windows GUI experience and also have my heavily Arch-inspired CLI cake with pacman icing.