Despite the presence of human drivers, modern cars are controlled by computers. In his talk at the Chaos Communication Congress [Guillaume Heilles] and [P1kachu] demonstrate the potential of taking control of a car’s computer. This of course leads to the natural conclusion of emulate an Xbox controller and using the car to play computer games.
His research was limited by the fact that the only cars they had access to were the daily drivers of different members of [P1kachu]’s family, which meant that all tinkering had to be strictly non-destructive. Despite this, they achieved impressive results and deliver a great introduction into reverse engineering.
[P1kachu] used a RasPi and an OBD-II adapter to access the car’s CAN bus and begins the presentation with a quick overview of the protocol. He then briefly touches on security measures that he ran into, which are optional and their implementation varies widely between manufacturers. His first attempt to access the CAN bus was successfully blocked by a challenge-response algorithm doing its work. His mother’s convertible however provided no such obstacles and gaining access allowed him to map the position of the steering wheel and pedals to a game controller, using the car to play video games.
After this, [Guillaume] steps in and walks us through the teardown of a gadget that plugs into the OBD-II port and claims to do amazing things for your car’s mileage by reprogramming the ECU. The device was not brand specific and after having seen the variations in the ways different manufacturers implement the protocol, [Guillaume] and [P1kachu] doubted that the gadget was capable of even holding the information required to modify every known implementation out there. Listening to the output of the device, along with a quick analysis of the circuit followed by decapping the single chip they found, showed that their doubt was justified. The lecture closes with an extended Q&A that adds more information on car hacking. Those that don’t have access to a car can instead tear down hot glue guns, doppler modules or antique calculators.
The feature of being easier to write than assembly is often seen as the biggest advantage of high-level programming languages. The other benefit that comes with them is portability. With high-level languages, algorithms can be developed independently from the underlying hardware. This allows software to live on once the hardware becomes obsolete.
The compiler was a concept that was met with resistance when it was first introduced. This was at a time when computers were custom-built machines bearing individual names like ENIAC, UNIVAC and Mark I. A time when the global demand for computers was estimated to be around five units by the CEO of IBM. In this scenario, it took a visionary to foresee a future where the number of computers would outgrow the number of programmers and hardware would evolve so much faster than software that a compiler would make sense. One visionary was [Grace Hopper].
Linux audio may be confusing for the uninitiated. As a system that has evolved and spawned at least two independent branches over time it tends to produce results that surprise or irritate the user. On the other hand it is open source software and thus can be fixed if you know what you do.
Over at reddit [rener2] was annoyed by the fact that listening to music on his laptop was a significantly worse experience under Linux than under Windows. Running Windows the output of the headphone jack covered the whole spectrum while his Linux set up cut off the low end resulting in a tinny sound. The culprit in this is the sound card: it has two different output paths for the internal speakers and the headphone jack. The signal for the internal speakers is routed through a high pass filter to spare them the embarrassment of failure to reproduce low frequencies.
When headphones are plugged in, the sound card driver is supposed to make the sound card bypass the filter and deliver the full spectrum. The authors of the Windows driver knew this and had it taken care of. In his video [rener2] runs us through the process of patching the ALSA driver while referencing the documentation of a sound card that he deems ‘similar enough’ to his Realtek ALC288.
Experiencing nostalgia for the outstanding Belgian cuisine [Adam], currently stuck in Ohio, found himself in craving some home-made speculoos. For the uninitiated, speculoos is what those brown cookies usually served with coffee on planes dream of becoming one day.
To add some extra regional flavour, [Adam] decided to print his own molds featuring motifs from Brussels. The risks of 3D prints in the kitchen are the subject of a lively discussion. They are addressed in this project by recommending the use of food safe filament and sealant for the molds. The fact that the dough will be removed from the molds almost instantly and that the molds don’t go into the oven puts the risks in the vicinity of using plastic cutting boards in your kitchen.
[Adam]’s write up features solid, well illustrated baking instructions that should enable any of you to replicate this delicacy. Some links to additional references and two recipes are thrown in for good measure. The article finishes with detailed instructions for designing your own molds that take the properties of the medium into account, to ensure your custom motif will still be recognizable after baking. Line art with a stroke width of around 2-3 mm seems to work best. It is that time of year and we hope to see a lot more tricks to take your cookie and edible house designs to the next level so don’t forget to send in a tip.
With 3D printed molds having been used to shape resin, silicone and even metal, we are at a point where cookie dough looks like a natural progression.
There is often an observable difference between what is considered the right thing to do, and what actually is being done.
Terry Pratchett said it best when he made Death declare mercy and justice nonexistent: “TAKE THE UNIVERSE AND GRIND IT DOWN TO THE FINEST POWDER AND SIEVE IT THROUGH THE FINEST SIEVE AND THEN SHOW ME ONE ATOM OF JUSTICE, ONE MOLECULE OF MERCY.” (Note that Death is not shouting, he simply speaks upper case.)
We can’t measure justice and mercy. These are collective fictions — things we agree to believe to enable us to get along — and finding consensus on the immeasurable extends to political systems, religion, and most of economics. In a recent article [zwischenzugs] makes the point that methodologies in software development fall into the same category. Like collective societal fictions, methodologies tend to elicit strong emotional responses among those dealing with them.
A software development methodology is a playbook for getting from nothing to something. It’s a control system for how people working on the project spend their time. And there are a lot of these prescribed methods, from Agile to Waterfall, and any combination of letters is likely to turn an abbreviation for a methodology. An interesting game when hanging out in groups of software engineers is to start the “Have you ever tried the…” conversation. Just don’t expect to move to another topic anytime soon.
One disheartening aspect of methodologies is their resistance to scientific scrutiny. Two samples of development teams will differ wildly in so many characteristics that a meaningful comparison of the way they organize their work is not possible. Which will leaves us with anecdotes and opinions when discussing these things.
Current opinions regarding the impact of methodologies on the success of a project range from ‘marginal’ to ‘essential’. The latter position is mainly propagated by consultants selling agile certifications, so you may want to take it with a grain of salt. Whether a team adheres strongly to the methodology or adopts it in name only, it’s obvious they serve a purpose — but that purpose may not match the face value of the method.
[Douglas] hometown Goshen, Indiana takes the state’s motto ‘The Crossroads of America’ seriously, at least when it comes to trains. The city is the meeting point of three heavily frequented railroad tracks that cross near the center of town, resulting in a car-traffic nightmare. When everybody agrees that a situation is bad, it is time to quantify exactly how bad it is. [Douglas] stepped up for this task and delivered.
He describes himself as cheap, and the gear he used to analyze the railroad traffic at a crossing visible from his home certainly fits the bill: a decades-old webcam, a scratched telephoto lens and a laptop with a damaged hinge.
With the hardware in place, the next step was to write the software to count and time passing trains. Doing this in stable conditions with reasonable equipment would pose no problem to any modern image processing library, but challenged with variable lighting and poor image quality, [Douglas] needed another solution.
Instead of looking for actual trains, [Douglas] decided to watch the crossing signals. His program crops the webcam image and then compares the average brightness of the left and right halves to detect blinking. This rudimentary solution is robust enough to handle low light conditions as well as morning glare and passing cars.
The rest is verifying the data, making it fit for processing, and then combining it with publicly available data on car traffic at the affected intersections to estimate impact. The next council meeting will find [Douglas] well prepared. Traffic issues are a great field for citizen science as shown in Stuttgart earlier. If the idea of bolting old lenses to webcams intrigues you, we got you covered as well.
The good people at MIT’s Computer Science and Artificial Intelligence Laboratory [CSAIL] have found a way of tricking Google’s InceptionV3 image classifier into seeing a rifle where there actually is a turtle. This is achieved by presenting the classifier with what is called ‘adversary examples’.
Adversary examples are a proven concept for 2D stills. In 2014 [Goodfellow], [Shlens] and [Szegedy] added imperceptible noise to the image of a panda that from then on was classified as gibbon. This method relies on the image being undisturbed and can be overcome by zooming, blurring or rotating the image.
The applicability for real world shenanigans has been seriously limited but this changes everything. This weaponized turtle is a color 3D print that is reliably misclassified by the algorithm from any point of view. To achieve this, some knowledge about the classifier is required to generate misleading input. The image transformations, such as rotation, scaling and skewing but also color corrections and even print errors are added to the input and the result is then optimized to reliably mislead the algorithm. The whole process is documented in [CSAIL]’s paper on the method.
What this amounts to is camouflage from machine vision. Assuming that the method also works the other way around, the possibility of disguising guns (or anything else) as turtles has serious implications for automated security systems.
As this turtle targets the Inception algorithm, it should be able to fool the DIY image recognition talkbox that Hackaday’s own [Steven Dufresne] built.