Reader [regulatre] has provided us with his furthering of hacking the OnStar system in GM cars. Previously, we wrote about some initial attempts to gain access to the system that OnStar uses to monitor and control cars called GMLAN. [regulatre] has managed to create an adapter between the GMLAN connector and a standard OBD2 plug, which should allow a number of standard readers to be able to retrieve data.
This method details using a bluetooth OBD2 reader, and passing the data onto a linux machine. It looks as though the writer of this method is looking to integrate OnStar reading and writing into an Android App which currently is an OBD monitor.
We love seeing follow-ups like this, because it puts everyone one step closer to full control of closed devices. As always, let us know if you take any of this in a new direction.
[Andy] has provided us with his new guide to hacking the OnStar GPS. Previously, we have covered a way to grab the GPS data from an unused OnStar system, however in recent years GM has added much more complex systems, which make it harder than swapping out a serial line. For the new version, [Andy] has figured out GM’s Controller Area Network (CAN), which they call GMLAN. He has also done most of the software snooping and sleuthing, and has mostly solved GMLAN’s method of announcing GPS data. There is sample code available to convert this information into generic latitude and longitude.
Unfortunately for the project, (and very fortunately for [Andy]), he has a child on the way and new job responsibilities, so he is offering up his results to the HaD community to finish up, double check, and provide a good how-to for everyone else. To anyone who decides to pick up this project and run with it, let us know!
this site shows you how to jack in to the gps receiver inside any gm onstar system. it’s as simple as soldering a up a serial cable. you can then connect to it and either run some gps diagnostic software, or switch the device to nmea mode so that you can use it with your gps mapping software in your car pc.
if you’ve got an onstar system but aren’t paying for the service this might be just the hack for you. thanks for the link leo!
What do you get if you strap a microscope onto a CNC and throw in a gaming controller? The answer, according to Reddit user [AskewedBox] is something kind of awesome: you get a microscope that can be controlled with the game controller for easier tracking of tiny creepy-crawlies.
[ASkewedBox] set up this interesting combination of devices, attaching their Adonostar AD246S microscope to the stage of a no-brand 1610 CNC bought off Amazon, then connected the CNC to a computer running Universal G-Code Sender. This great open source program takes the input from an Xbox game controller and uses it to jog the CNC.
With a bit of tweaking, the game controller can now move the microscope, so it can be used to track microbes and other small creatures as they wander around on the slide mounted below the microscope eating each other. The movement of this is surprisingly smooth: the small CNC and a well-mounted microscope means that there seems to be very little wobble or backlash as the microscope moves.
[Askewedbox] hasn’t finished yet, though: in the latest update, he adds a polarizing lens to the setup and mentions that he wants to add focus control to the system, which is controlled by a remote that comes with the microscope.
There are plenty of other things that could be added beyond that, though, such as auto pan and stitch for larger photos, auto focus stacking and perhaps even auto tracking using OpenCV to track the hideous tiny creatures that live in the microscopic realm. What would you do to make this even cooler?
Currently, if you want to use the Autopilot or Self-Driving modes on a Tesla vehicle you need to keep your hands on the wheel at all times. That’s because, ultimately, the human driver is still the responsible party. Tesla is adamant about the fact that functions which allow the car to steer itself within a lane, avoid obstacles, and intelligently adjust its speed to match traffic all constitute a driver assistance system. If somebody figures out how to fool the wheel sensor and take a nap while their shiny new electric car is hurtling down the freeway, they want no part of it.
So it makes sense that the company’s official line regarding the driver-facing camera in the Model 3 and Model Y is that it’s there to record what the driver was doing in the seconds leading up to an impact. As explained in the release notes of the June 2020 firmware update, Tesla owners can opt-in to providing this data:
Help Tesla continue to develop safer vehicles by sharing camera data from your vehicle. This update will allow you to enable the built-in cabin camera above the rearview mirror. If enabled, Tesla will automatically capture images and a short video clip just prior to a collision or safety event to help engineers develop safety features and enhancements in the future.
But [green], who’s spent the last several years poking and prodding at the Tesla’s firmware and self-driving capabilities, recently found some compelling hints that there’s more to the story. As part of the vehicle’s image recognition system, which usually is tasked with picking up other vehicles or pedestrians, they found several interesting classes that don’t seem necessary given the official explanation of what the cabin camera is doing.
If all Tesla wanted was a few seconds of video uploaded to their offices each time one of their vehicles got into an accident, they wouldn’t need to be running image recognition configured to detect distracted drivers against it in real-time. While you could make the argument that this data would be useful to them, there would still be no reason to do it in the vehicle when it could be analyzed as part of the crash investigation. It seems far more likely that Tesla is laying the groundwork for a system that could give the vehicle another way of determining if the driver is paying attention.
Honeypots are an entertaining way to learn about new attacks. A simulated vulnerable system is exposed to the internet, inviting anyone to try to break into it. Rather than actually compromising a deployed device, and attacker just gives away information about how they would attack the real thing. A honeypot run by 360Netlab found something interesting back in April: an RCE attack against QNAP NAS devices. The vulnerability is found in the logout endpoint, which takes external values without properly sanitizing them. These values are used as part of an snprintf statement, and then executed with a system() call. Because there isn’t any sanitization, special characters like semicolons can be injected into the final command to be run, resulting in a trivial RCE.
QNAP has released new firmware that fixes the issue by replacing the system() call with execv(). This change means that the shell isn’t part of the execution process, and the command injection loses its bite. Version 4.3.3 was the first firmware release to contain this fix, so if you run a QNAP device, be sure to go check the firmware version. While this vulnerability was being used in the wild, there doesn’t seem to have been a widespread campaign exploiting it.
While recent commercial competition has dropped the cost of reaching orbit to a point that many would have deemed impossible just a decade ago, it’s still incredibly expensive. We’ve moved on from the days where space was solely the domain of world superpowers into an era where multi-billion dollar companies can join on on the fun, but the technological leaps required to reduce it much further are still largely relegated to the drawing board. For the time being, thing’s are as good as they’re going to get.
Starlink satellites ready for launch
If we can’t count on the per pound cost of an orbital launch to keep dropping over the next few years, the next best option would logically be to design spacecraft that are smaller and lighter. Thankfully, that part is fairly easy. The smartphone revolution means we can already pack an incredible amount sensors and processing power into something that can fit in the palm of your hand. But there’s a catch: the Tsiolkovsky rocket equation.
Often referred to as simply the “rocket equation”, it allows you to calculate (among other things) the ratio of a vehicle’s useful cargo to its total mass. For an orbital rocket, this figure is very small. Even with a modern launcher like the Falcon 9, the payload makes up less than 5% of the liftoff weight. In other words, the laws of physics demand that orbital rockets are huge.
Unfortunately, the cost of operating such a rocket doesn’t scale with how much mass it’s carrying. No matter how light the payload is, SpaceX is going to want around $60,000,000 USD to launch the Falcon 9. But what if you packed it full of dozens, or even hundreds, of smaller satellites? If they all belong to the same operator, then it’s an extremely cost-effective way to fly. On the other hand, if all those “passengers” belong to different groups that split the cost of the launch, each individual operator could be looking at a hundredfold price reduction.
SpaceX has already packed 60 of their small and light Starlink satellites into a single launch, but even those craft are massive compared to what other groups are working on. We’re seeing the dawn of a new era of spacecraft that are even smaller than CubeSats. These tiny spacecraft offer exciting new possibilities, but also introduce unique engineering challenges.
