This excellent content from the Hackaday writing crew highlights recurring topics and popular series like Linux-Fu, 3D-Printering, Hackaday Links, This Week in Security, Inputs of Interest, Profiles in Science, Retrotechtacular, Ask Hackaday, Teardowns, Reviews, and many more.
Humans aren’t always great at respecting each other’s privacy. However, common sense says there’s a clear boundary when it comes to the thoughts in one’s own head and the feelings in one’s heart.
For bus drivers in Beijing though, it seems that’s no longer the case. These professional drivers are now being asked to wear emotional monitors while on the job, raising concerns from both legal and privacy advocates. But the devices aren’t really anything more than workout monitors, and whether they can actually make good on their Orwellian promise remains to be seen.
In Your Head, In Your Head!
The monitoring wristbands have been rolled out to some of Beijing’s long-distance bus drivers. Credit: Cypp0847, CC-BY-SA-4.0
When George Orwell wrote 1984, it was only 1949. However, he was able to foresee a world in which surveillance was omnipresent and inescapable. He also envsioned the concept of thoughtcrime, where simply contemplating the wrong things could get you in serious trouble with the authorities.
As we all know, Orwell was way off – these predictions didn’t become reality until well into the 2000s. In the latest horrifying development, technologies now exist that claim to be able to monitor one’s emotional state. Now, China’s transportation sector is rushing to push them on their workforces.
Long-distance bus drivers in Beijing are now being told to wear electronic wristbands when on the job. These wristbands claim to be able to capture the wearer’s emotional state, monitoring it on behalf of the employer. The scheme was the idea of the Beijing Public Transport Holding Group. The state-run organization claims the technology is intended for the safety of the public, and a trial of the wristbands began in July this year. Continue reading “Big Brother Or Dumb Brother? Bus Drivers In Beijing Are Forced To Wear “Emotional Monitors””→
“Necessity is the mother of invention,” or so the saying goes. We’ve never held to that, finding that laziness is a much more powerful creative lubricant. And this story about someone who automated their job with a script is one of the best examples of sloth-driven invention since the TV remote was introduced. If we take the story at face value — and it’s the Internet, so why wouldn’t we? — this is a little scary, as the anonymous employee was in charge of curating digital evidence submissions for a law firm. The job was to watch for new files in a local folder, manually copy them to a cloud server, and verify the file with a hash to prove it hasn’t been tampered with and support the chain of custody. The OP says this was literally the only task to perform, so we can’t really blame them for automating it with a script once COVID shutdowns and working from home provided the necessary cover. But still — when your entire job can be done by a Windows batch file and some PowerShell commands while you play video games, we’re going to go out on a limb and say you’re probably underemployed.
People have been bagging on the US Space Force ever since its inception in 2019, which we think is a little sad. It has to be hard being the newest military service, especially since it branched off of the previously newest military service, and no matter how important its mission may be, there’s still always going to be the double stigmas of being both the new kid on the block and the one with a reputation for digging science fiction. And now they’ve given the naysayers yet more to dunk on, with the unveiling of the official US Space Force service song. Every service branch has a song — yes, even the Army, and no, not that one — and they all sound appropriately martial. So does the Space Force song, but apparently people have a problem with it, which we really don’t get at all — it sounds fine to us.
First, it was the WiFi router: my ancient WRT54G that had given me nearly two decades service. Something finally gave out in the 2.4 GHz circuitry, and it would WiFi no more. Before my tears could dry, our thermometer went on the fritz. It’s one of those outdoor jobbies that transmits the temperature to an indoor receiver. After that, the remote for our office lights stopped working, but it was long overdue for a battery change.
Meanwhile, my wife had ordered a new outdoor thermometer, and it too was having trouble keeping a link. Quality control these days! Then, my DIY coffee roaster fired up once without any provocation. This thing has worked quasi-reliably for ten years, and I know the hardware and firmware as if I had built them myself – there was no way one of my own tremendously sophisticated creations would be faulty. (That’s a joke, folks.) And then the last straw: the batteries in the office light remote tested good.
We definitely had a poltergeist, a radio poltergeist. And the root cause would turn out to be one of those old chestnuts from the early days of CMOS ICs – never leave an input floating that should have a defined logic level. Let me explain.
Here’s how it went down. The WiFi-to-433 bridge failed to connect to the WiFi and errored out before the part of the code where it initialized GPIO pins. The 433 MHz transmitter was powered, but its digital input was left flopping in the breeze, causing it to spit out random data all the time, with a pretty decent antenna. This jammed everything in the house, and apparently even once came up with the command to turn on the coffee roaster, entirely by chance. Anyway, unplugging the bridge fixed everything.
This was a fun one to troubleshoot, if only because it crossed so many different devices at different times, some homebrew and some commercial, and all on different control systems. Until I put it together that everything on 433 MHz was failing, I hadn’t even thought of it as one event. And then it turns out to be a digital electronics classic – the dangling input!
Anyway, hope you enjoyed the ride. And spill some copper for the humble pull-down resistor.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
In a perfect world, all of our electronic devices would come with complete documentation, and there’d be open source libraries available for interfacing them with whatever we wanted. There’d never be arbitrary lockouts preventing us from using a piece of hardware in a way the manufacturer didn’t approve of, and the “cloud” wouldn’t be a black-box server in some data center on the other side of the planet, but a transparent and flexible infrastructure for securely storing and sharing information.
Unfortunately, that’s not the world we live in. What’s worse, rather than moving towards that electronic utopia, the industry appears to be heading in the opposite direction. It seems like every month we hear about another service shutting down and leaving viable hardware to twist in the wind. Just yesterday Google announced they’d be retiring their Stadia game streaming service early next year — leaving users with unique Internet-connected controllers that will no longer have a back-end to communicate with.
Matthew Alt
Luckily for us, there’s folks like Matthew [wrongbaud] Alt out there. This prolific hacker specializes in reverse engineering, and has a knack not just for figuring out how things work, but in communicating those findings with others. His conquests have graced these pages many times, and we were fortunate enough to have him helm the Introduction to Reverse Engineering with Ghidra class for HackadayU back in 2020. This week, he stopped by the Hack Chat to talk about the past, present, and future of reverse engineering.
Matthew got his start in reverse engineering during college, when he was working in a shop that specialized in tuning engine control units (ECUs). He was responsible for figuring out how the ECUs functioned, which ultimately would allow them to be modified to improve engine performance beyond the vehicle’s stock configuration. Sometimes that involved uploading modified calibration data, or disabling functions that were detrimental to engine performance. These software changes could potentially increase engine output by as much as 50 HP, though he says that sometimes the goal was to simply increase throttle response so the vehicle would feel more aggressive on the road.
Moving on to the tools of the trade, Matthew explained why he prefers using Ghidra for embedded targets over classic reverse engineering tools like IDA Pro. As an example he points to a recent project where he used Ghidra’s API and intermediary language PCode to crack passwords in Game Boy Advance games. Though he does mention that IDA still has its place if you’re looking to peek into some Windows C++ software.
Matthew also pointed to new techniques and tools for working with fault injection which have opened up a lot of exciting possibilities over the last few years. In fact, he says tools like ChipWhisperer will become invaluable as newer devices adopt advanced security features. When gadgets are using secure boot and encrypted firmware, gaining access is going to take a bit more than just finding an unleaded serial port on the board. Glitching attacks will become more commonplace, so you might as well get up to speed now.
Colin O’Flynn’s ChipWhisperer makes side-channel power analysis and glitching attacks far more accessible.
We’d like to thank Matthew Alt for not just stopping by the Hack Chat, but for being such a good friend to the Hackaday community. His work has been inspirational for all of us here, and it’s always exciting when he’s penned a new blog post detailing another challenge bested. The next time your favorite MegaCorp releases some anti-consumer gadget, you can take some comfort in knowing he’s still out there bending hardware to his will.
The Hack Chat is a weekly online chat session hosted by leading experts from all corners of the hardware hacking universe. It’s a great way for hackers connect in a fun and informal way, but if you can’t make it live, these overview posts as well as the transcripts posted to Hackaday.io make sure you don’t miss out.
This week, Editor-in-Chief Elliot Williams and Assignments Editor Kristina Panos gushed about NASA’s live obliteration of minor planet Dimorphos using a probe outfitted with a camera. Spoiler alert: the probe reaches its rock-dappled rocky target just fine, and the final transmitted image has a decidedly human tinge.
Kristina brought the mystery sound again this week, much to Elliot’s sonic delight. Did he get it? Did he figure it out? Well, no. The important thing is one of you is bound to get it.
We kick off the hacks with a really neat 3D printed linkage that acts as an elevator for a marble run, and then we discuss a mid-century hack that helps you decide whether it’s time to emerge from the fallout shelter using the contents of your typical 1950s pockets. We spent a few minutes comparing our recent radiation exposure levels — Kristina wins with about a dozen x-rays so far this year, but no full-body CT scans. Then we talk guitars for a bit, remember a forgotten CPU from TI, and spend a few cycles talking about a tone-wheel organ that sounds like a chorus of gleeful gerbils.
Finally, we talk toner transfer for 3D prints, argue in defense of small teams versus large committees, and get all tangled up in cursive.
According to researchers at GTSC, there’s an unpatched 0-day being used in-the-wild to exploit fully patched Microsoft Exchange servers. When they found one compromised server, they made the report to Microsoft through ZDI, but upon finding multiple Exchange servers compromised, they’re sounding the alarm for everyone. It looks like it’s an attack similar to ProxyShell, in that it uses the auto-discover endpoint as a starting point. They suspect it’s a Chinese group that’s using the exploit, based on some of the indicators found in the webshell that gets installed.
There is a temporary mitigation, adding a URL-based request block on the string .*autodiscover\.json.*\@.*Powershell.. The exact details are available in the post. If you’re running Exchange with IIS, this should probably get added to your system right now. Next, use either the automated tool, or run the PowerShell one-liner to detect compromise: Get-ChildItem -Recurse -Path -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200. This one has the potential to be another really nasty problem, and may be wormable. As of the time of writing, this is an outstanding, unpatched problem in Microsoft Exchange. Come back and finish the rest of this article after you’ve safed up your systems.
An interesting and also annoying aspect about the human immune system is that it is not a neat, centralized system where you input an antigen pattern in one spot and suddenly every T and B lymphocyte in the body knows how to target an intruder. Generally, immunity stays confined to specific areas, such as the vascular and lymph system, as well as the intestinal and mucosal (nasal) parts of the body.
The result of this is that specific types of vaccines have a different effect, as is demonstrated quite succinctly with the polio vaccines. The main difference between the oral polio vaccine (OPV) and inactivated vaccine (injected polio vaccine, or IPV) is that the former uses a weakened virus that induces strong immunity in the intestines, something that the latter does not. The effect of this is that while both protect the individual, it does not affect the fecal-oral infection route of the polio virus and thus the community spread.
The best outcome for a vaccine is when it both protects the individual, while also preventing further infections as part of so-called sterilizing immunity. This latter property is what makes the OPV vaccine so attractive, as it prevents community spread, while IPV is sufficient later on, as part of routine vaccinations. The decision to use a vaccine like the OPV versus the IPV is one of the ways doctors can tune a population’s protection against a disease.
This is where the current batch of commonly used SARS-CoV-2 vaccines are showing a major issue, as they do not provide significant immunity in the nasal passage’s mucosal tissues, even though this is where the virus initially infects a host, as well as where it replicates and infects others from. Here intranasal vaccines may achieve what OPV did for polio.
