It has been a long time since we stored software and computer data on audiotape. But it used to be the de facto standard for hobby computers and [Noel] has a great video about the Amstrad’s system (embedded below) which was pretty typical and how the process could be sped up since today, you have perfect audio reproduction, especially compared to consumer-grade audiotape.
The cassette tapes suffered from several problems. The tape had an inherently low bandwidth, there was quite a bit of noise present from the analog circuitry and heads, and the transport speed wasn’t necessarily constant. However, you can easily digitally synthesize relatively noise-free sound at high fidelity and rock-solid frequency. So basically a microcontroller, like an Arduino, can look like an extremely high-quality tape drive.
We’ve covered the right-to-repair saga, and one of the companies that have become rather notorious is John Deere. The other side to the poorly managed interconnected mess is security issues. There’s a certain irony to how this story started: Somebody noticed that John Deere equipment didn’t have any CVEs at all. A normal person might think that this must mean their products are super secure, but a security researcher knows that something more interesting is afoot. Our old friends [Sick Codes], [John Jackson], and a host of others saw this as a sure sign that there were plenty of vulnerabilities to be found, and it seems they were correct.
Remote Access and Code from 2014…
Vulnerabilities included a handful of cross-site scripting attacks, an authentication bypass via request smuggling, misconfigured security, SQL injections, RCEs and more. Put together, these vulnerabilities allowed for full control of the John Deere system, including the ability to manipulate all the equipment connected to the system.
During the Defcon presentation, linked below, [Sick Codes] recalled the moment when they realized they were working on an important problem. Rather than complain about not getting paid for the vulnerabilities found, a contributor simply noted that he valued having food to eat. A coordinated attack on JD equipment could cause big problems for a bunch of farms across a country.
They ended up contacting CISA, due to a lack of serious response from the vendors. CISA took the threat seriously, and the problems starting getting fixed. This isn’t a problem limited to one company. Case had similar issues that have also been fixed, and it was implied that other vendors have similar problems that are still in the process of being addressed. Continue reading “This Week In Security: John Deere, ProxyLogin Detailed, And Pneumatic Tubes”→
These days we expect even the cheapest of burner smartphones to feature a multi-core processor, at least a gigabyte of RAM, and a Linux-based operating system. But obviously those sort of specs are unnecessary for an old school POTS desktop phone. Well, that’s what we thought. Then [Josh Max] wrote in to tell us about his adventures in hacking the CaptionCall, and now we’re eager to see what the community can do with root access on a surprisingly powerful Linux phone.
As the names implies, the CaptionCall is a desk phone with an LCD above the keypad that shows real-time captions. Anyone in the United States with hearing loss can get one of these phones for free from the government, so naturally they sell for peanuts on the second hand market. Well, at least they did. Then [Josh] had to go ahead and crack the root password for the ARMv7 i.MX6 powered phone, started poking around inside of its 4 GB of onboard NAND, and got the thing running DOOM.
Tapping into the serial port.
If you’re interested in the technical details, [Josh] has done a great job taking us step by step through his process. It’s a story that will be at least somewhat familiar to anyone who’s played around with embedded Linux devices, and unsurprisingly, starts with locating a serial port header on the PCB.
Finding the environment variables to pretty tightly locked down, he took the slow-route and dumped the phone’s firmware 80 characters at a time with U-Boot’s “memory display” command. Passing the recovered firmware image through binwalk and a password cracker got him the root credentials in short order, and from there, that serial port got a whole lot more useful.
[Josh] kicked the phone’s original UI to the curb, set up an ARM Debian Jessie chroot, and started working his way towards a fully functional Linux environment. With audio, video, and even keypad support secured, he was ready to boot up everyone’s favorite 1993 shooter. He’s been kind enough to share his work in a GitHub repository, and while it might not be a turn-key experience, all the pieces are here to fully bend the hardware to your will.
Historically, running DOOM on a new piece of hardware has been the harbinger of bigger and better things to come. With unfettered access to its Linux operating system up for grabs, we predict the CaptionCall is going to become a popular hacking target going forward, and we can’t wait to see it.
There’s a military adage that no plan survives first contact with the enemy. While we haven’t gone to war with Mars, at least not yet, it does seem to be a place where the best-laid scientific plans are tested in the extreme. And the apparent failure of Perseverance to retrieve its first Martian core sample is yet another example of just how hard it is to perform geotechnical operations on another planet.
To be sure, a lot about the first sampling operation went right, an especially notable feat in that the entire process is autonomous. And as we’ve previously detailed, the process is not simple, involving three separate robotic elements that have to coordinate their operations perfectly. Telemetry indicates that the percussive drill on the end of the 2.1 m robotic arm was able to use its hollow coring bit to drill into the rock of Jezero crater, and that the sample tube inside the coring bit was successfully twisted to break off the core sample.
But what was supposed to happen next — jamming of the small core sample inside the sample tube — appears not to have happened. This was assessed by handing the sample tube off to the Sample Handling Arm in the belly of Perseverance, where a small probe is used to see how much material was recovered — none, in this case. NASA/JPL engineers then began a search for the problem. Engineering cameras didn’t reveal the core sample on the Martian surface, meaning the sample handling robots didn’t drop it. The core sample wasn’t in the borehole either, which would have meant the camming mechanism designed to retain the core didn’t work. The borehole, though, looked suspicious — it appears not to be deep enough, as if the core sample crumbled to dust and packed into the bottom of the hole.
If this proves to be the cause of the failure, it will be yet another example of Martian regolith not behaving as expected. For InSight, this discovery was a death knell to a large part of its science program. Thankfully, Perseverance can pick up and move to better rock, which is exactly what it will be doing in September. They still have 42 unused sample tubes to go, so here’s to better luck next time.
