ReactOS 0.4.15 Released With Major Improvements

Recently the ReactOS project released the much anticipated 0.4.15 update, making it the first major release since 2020. Despite what might seem like a minor version bump from the previous 0.4.14 release, the update introduces sweeping changes to everything from the kernel to the user interface and aspects like the audio system and driver support. Those who have used the nightly builds over the past years will likely have noticed a lot of these changes already.

Japanese input with MZ-IME and CJK font (Credit: ReactOS project)
Japanese input with MZ-IME and CJK font (Credit: ReactOS project)

A notable change is to plug-and-play support which enables more third party drivers and booting from USB storage devices. The Microsoft FAT filesystem driver from the Windows Driver Kit can now be used courtesy of better compatibility, there is now registry healing, and caching and kernel access checks are implemented. The latter improvement means that many ReactOS modules can now work in Windows too.

On the UI side there is a much improved IME (input method editor) feature, along with native ZIP archive support and various graphical tweaks.

Meanwhile since 0.4.15 branched off the master branch six months ago, the latter has seen even more features added, including SMP improvements, UEFI support, a new NTFS driver and improvements to power management and application support. All of this accompanied by many bug fixes, which makes it totally worth it to regularly check out the nightly builds.

Converting Bluetooth Sensors To Zigbee

With the increase in popularity of Internet of Things (IoT) devices and their need to communicate wirelessly,  there’s been a corresponding explosion of wireless protocols to chose from. Of course there’s Wi-Fi and Bluetooth, but for more specialized applications there are some other options like Z-Wave, LoRa, Sigfox, and Thread. There’s a decent amount of overlap in their capabilities too, so when [SHS] was investigating some low-cost Xiaomi sensors it was discovered that it is possible to convert them from their general purpose Bluetooth protocol over to the more IoT-specialized Zigbee protocol instead.

These combination temperature and humidity sensors have already been explored by [Aaron Christophel] who found that it’s possible to flash these devices with custom firmware. With that background, converting them from Bluetooth to Zigbee is not a huge leap. All that’s needed is the Zigbee firmware from [Ivan Belokobylskiy] aka [devbis] and to follow the steps put together by [SHS] which include a process for flashing the firmware using an over-the-air update and another using UART if the wireless updates go awry. Then it’s just a short process to pair the new Zigbee device to the network and the sensor is back up and running.

Converting from one wireless protocol to another might not seem that necessary, but using Bluetooth as an IoT network often requires proxy nodes as support devices, whereas Zigbee can communicate directly from the sensor to a hub like Home Assistant. Other Zigbee devices themselves can also act as a mesh network of sorts without needing proxy nodes. The only downside of this upgrade is that once the Bluetooth firmware has been replaced, the devices no longer has any Bluetooth functionality.

Thanks to [RoganDawes] for the tip!

Major Bug Grants Root For All Major Linux Distributions

One of the major reasons behind choosing Linux as an operating system is that it’s much more secure than Windows. There are plenty of reasons for this including appropriate user permissions, installing software from trusted sources and, of course, the fact that most software for Linux including the Linux kernel itself is open source which allows anyone to review the code for vulnerabilities. This doesn’t mean that Linux is perfectly secure though, as researchers recently found a major bug found in most major Linux distributions that allows anyone to run code as the root user.

The exploit is a memory corruption vulnerability in Polkit, a framework that handles the privilege level of various system processes. It specifically impacts the program pkexec. With the proof-of-concept exploit (file download warning) in hand, all an attacker needs to do to escalate themselves to root is to compile the program on the computer and run it as the default user. An example is shown by [Jim MacDonald] on Twitter for those not willing to try this on their own machines.

As bad as this sounds, it seems as though all of the major distributions that this impacts have already released updates that patch the issue, including Debian, Ubuntu, Red Hat, Fedora, open SUSE, and Arch. There is also a temporary workaround that removes read/write permission from the pkexec program so it can’t run at all. That being said, it might be best to check that your Linux systems are all up-to-date and that no strangers have been typing random commands into the terminal recently.

Even More Firmware In Your Firmware

There are many ways to update an embedded system in the field. Images can fly through the air one a time, travel by sneaker or hitch a ride on other passing data. OK, maybe that’s a stretch, but there are certainly a plethora of ways to get those sweet update bytes into a target system. How are those bytes assembled, and what are the tools that do the assembly? This is the problem I needed to solve.

Recall, my system wasn’t a particularly novel one (see the block diagram below). Just a few computers asking each other for an update over some serial busses. I had chosen to bundle the payload firmware images into the binary for the intermediate microcontroller which was to carry out the update process. The additional constraint was that the blending of the three firmware images (one carrier and two payload) needed to happen long after compile time, on a different system with a separate toolchain. There were ultimately two options that fit the bill.

The system thirsty for an update

Continue reading “Even More Firmware In Your Firmware”

Putting The Firmware In Your Firmware

Performing over-the-air updates of devices in the field can be a tricky business. Reliability and recovery is of course key, but even getting the right bits to the right storage sectors can be a challenge. Recently I’ve been working on a project which called for the design of a new pathway to update some small microcontrollers which were decidedly inconvenient.

There are many pieces to a project like this; a bootloader to perform the actual updating, a robust communication protocol, recovery pathways, a file transfer mechanism, and more. What made these micros particularly inconvenient was that they weren’t network-connected themselves, but required a hop through another intermediate controller, which itself was also not connected to the network. Predictably, the otherwise simple “file transfer” step quickly ballooned out into a complex onion of tasks to complete before the rest of the project could continue. As they say, it’s micros all the way down.

The system de jour

Continue reading “Putting The Firmware In Your Firmware”

Google Turns Android Up To 11 With Latest Update

Just going by the numbers, it’s a pretty safe bet that most Hackaday readers own an Android device. Even if Google’s mobile operating system isn’t running on your primary smartphone, there’s a good chance it’s on your tablet, e-reader, smart TV, car radio, or maybe even your fridge. Android is everywhere, and while the development of this Linux-based OS has been rocky at times, the general consensus is that it seems to have been moving in the right direction over the last few years. Assuming your devices actually get the latest and greatest update, anyway.

So it’s not much of a surprise that Android 11, which was officially released yesterday, isn’t a huge update. There’s no fundamental changes in the core OS, because frankly, there’s really not a whole lot that really needs changing. Android has become mature enough that from here on out we’re likely to just see bug fixes and little quality of life improvements. Eventually Google will upset the apple cart (no pun intended) with a completely new mobile OS, but we’re not there yet.

Of course, that’s not to say there aren’t some interesting changes in Android 11. Or more specifically, changes that may actually be of interest to the average Hackaday reader. Let’s take a look at a handful of changes and tweaks worth noting for the more technical crowd.

Continue reading “Google Turns Android Up To 11 With Latest Update”

Updating To Windows 10 For Fun And Profit: Make Those OEM Keys Go Further

Microsoft seems to have an every-other-version curse. We’re not sure how much of this is confirmation bias, but consider the track record of releases. Windows 95 was game-changing, Windows 98 famously crashed during live demo. Windows 2000 was amazing, Windows ME has been nicknamed the “Mistake Edition”. XP was the workhorse of the world for years and years, and Vista was… well, it was Vista. Windows 7 is the current reigning champion of desktop installs, and Windows 8 was the version that put a touchscreen interface on desktops. The “curse” is probably an example of finding patterns just because we’re looking for them, but the stats do show a large crowd clinging to Windows 7.

Windows 10 made a name for itself by automatically installing itself on Windows 7 and Windows 8 computers, much to the annoyance of many unexpecting “victims” of that free upgrade. Several years have gone by, Windows 10 has gotten better, and support for Windows 7 ends in January. If you’re tied to the Windows ecosystem, it’s time to upgrade to Windows 10. It’s too bad you missed out on the free upgrade to Windows 10, right?

About that… It’s probably an unintended side effect, but all valid Windows 7 and Windows 8 keys are also valid Windows 10 keys. Activation is potentially another issue, but we’ll get to that later.

Continue reading “Updating To Windows 10 For Fun And Profit: Make Those OEM Keys Go Further”