The field of computer science has undeniably changed the world for virtually every single person by now. Certainly for you as Hackaday reader, but also for everyone around you, whether they’re working in the field themselves, or are simply enjoying the fruits of convenience it bears. What was once a highly specialized niche field for a few chosen people has since grown into a discipline that not only created one of the biggest industry in modern times, but also revolutionized every other industry, some a few times over.
The fascinating part about all this is the relatively short time span it took to get here, and with that the privilege to live in an era where some of the pioneers and innovators, the proverbial giants whose shoulders every one of us is standing on, are still among us. Sadly, one of them, [Tony Brooker], a pioneer of the early programming language concept known as Autocode, passed away in November. Reaching the remarkable age of 94, the truly sad part however is that this might be the first time you hear his name, and there’s a fair chance you never heard of Autocode either.
But Autocode was probably the first high-level computer language, and as such played a fundamental role in the development of whatever you’re coding in today. So to honor the memory of [Tony Brooker], let’s remember the work he did with Autocode, and the leap in computer science history that it represented.
Continue reading “Tony Brooker And Autocode – The First High-level Language”
In any normal situation, if you’d read an article that about building your own quantum computer, a fully understandable and natural reaction would be to call it clickbaity poppycock. But an event like the Chaos Communication Congress is anything but a normal situation, and you never know who will show up and what background they will come from. A case in point: security veteran [Yann Allain] who is in fact building his own quantum computer in his garage.
Starting with an introduction to quantum computing itself, and what makes it so powerful also in the context of security, [Yann] continues to tell about his journey of building a quantum computer on his own. His goal was to build a stable computer he could “easily” create by himself in his garage, which will work at room temperature, using trapped ion technology. After a few iterations, he eventually created a prototype with KiCad that he cut into an empty ceramic chip carrier with a hobbyist CNC router, which will survive when placed in a vacuum chamber. While he is still working on a DIY laser system, he feels confident to be on the right track, and his estimate is that his prototype will achieve 10-15 qubits with a single ion trap, aiming to chain several ion traps later on.
As quantum computing is often depicted as cryptography’s doomsday device, it’s of course of concern that someone might just build one in their garage, but in order to improve future cryptographic systems, it also requires to fully understand — also on a practical level — quantum computing itself. Whether you want to replicate one yourself, at a rough cost of “below 15k Euro so far” is of course a different story, but who knows, maybe [Yann] might become the Josef Prusa of quantum computers one day.
Continue reading “36C3: Build Your Own Quantum Computer At Home”
SIM cards are all around us, and with the continuing growth of the Internet of Things, spawning technologies like NB-IoT, this might as well be very literal soon. But what do we really know about them, their internal structure, and their communication protocols? And by extension, their security? To shine some light on these questions, open source and mobile device titan [LaForge] gave an introductory talk about SIM card technologies at the 36C3 in Leipzig, Germany.
Starting with a brief history lesson on the early days of cellular networks based on the German C-Netz, and the origin of the SIM card itself, [LaForge] goes through the main specification and technology parts of each following generation from 2G to 5G. Covering the physical basics, I/O interfaces, communication protocols, and the file system located on the SIM card, you’ll get the answer to “what on Earth is PIN2 for?” along the way.
Of course, a talk like this, on a CCC event, wouldn’t be complete without a deep and critical look at the security side as well. Considering how over-the-air updates on both software and — thanks to mostly running Java nowadays — feature side are more and more common, there certainly is something to look at.
Continue reading “36C3: SIM Card Technology From A To Z”
With open source software, we’ve grown accustomed to a certain level of trust that whatever we are running on our computers is what we expect it to actually be. Thanks to hashing and public key signatures in various parts in the development and deployment cycle, it’s hard for a third party to modify source code or executables without us being easily able to spot it, even if it travels through untrustworthy channels.
Unfortunately, when it comes to open source hardware, the number of steps and parties involved that are out of our control until we have a final product — production, logistics, distribution, even the customer — makes it substantially more difficult to achieve the same peace of mind. To make things worse, to actually validate the hardware on chip level, you’d ultimately have to destroy it.
On his talk this year at the 36C3, [bunnie] showed a detailed insight of several attack vectors we could face during manufacturing. Skipping the obvious ones like adding or substituting components, he’s focusing on highly ambitious and hard to detect modifications inside an IC’s package with wirebonded or through-silicon via (TSV) implants, down to modifying the netlist or mask of the integrated circuit itself. And these aren’t any theoretical or “what if” scenarios, but actual possible options — of course, some of them come with a certain price tag, but in the end, with the right motivation, money is only a detail.
Continue reading “36C3: Open Source Is Insufficient To Solve Trust Problems In Hardware”
It’s no secret that the average smart phone today packs an abundance of gadgets fitting in your pocket, which could have easily filled a car trunk a few decades ago. We like to think about video cameras, music playing equipment, and maybe even telephones here, but let’s not ignore the amount of measurement equipment we also carry around in form of tiny sensors nowadays. How to use those sensors for educational purposes to teach physics is presented in [Sebastian Staacks]’ talk at 36C3 about the phyphox mobile lab app.
While accessing a mobile device’s sensor data is usually quite straightforwardly done through some API calls, the phyphox app is not only a shortcut to nicely graph all the available sensor data on the screen, it also exports the data for additional visualization and processing later on. An accompanying experiment editor allows to define custom experiments from data capture to analysis that are stored in an XML-based file format and possible to share through QR codes.
Aside from demonstrating the app itself, if you ever wondered how sensors like the accelerometer, magnetometer, or barometric pressure sensor inside your phone actually work, and which one of them you can use to detect toilet flushing on an airplane and measure elevator velocity, and how to verify your HDD spins correctly, you will enjoy the talk. If you just want a good base for playing around with sensor data yourself, it’s all open source and available on GitHub for both Android and iOS.
Continue reading “36C3: Phyphox – Using Smartphone Sensors For Physics Experiments”
Have you ever taken a look at all the information that Google has collected about you over all these years? That is, of course, assuming you have a Google account, but that’s quite a given if you own an Android device and have privacy concerns overruled by convenience. And considering that GPS is a pretty standard smartphone feature nowadays, you shouldn’t be surprised that your entire location history is very likely part of the collected data as well. So unless you opted out from an everchanging settings labyrinth in the past, it’s too late now, that data exists — period. Well, we might as well use it for our own benefit then and visualize what we’ve got there.
Location data naturally screams for maps as visualization method, and [luka1199] thought what would be better than an interactive Geo Heatmap written in Python, showing all the hotspots of your life. Built around the Folium library, the script reads the JSON dump of your location history that you can request from Google’s Takeout service, and overlays the resulting heatmap on the OpenStreetMap world map, ready for you to explore in your browser. Being Python, that’s pretty much all there is, which makes [Luka]’s script also a good starting point to play around with Folium and map visualization yourself.
While simply just looking at the map and remembering the places your life has taken you to can be fun on its own, you might also realize some time optimization potential in alternative route plannings, or use it to turn your last road trip route into an art piece. Just, whatever you do, be careful that you don’t accidentally leak the location of some secret military facilities.
As popular as the post-apocalyptic Zombie genre is, there is a quite unrealistic component to most of the stories. Well, apart from the whole “the undead roaming the Earth” thing. But where are the nerds, and where is all the apocalypse-proof, solar-powered tech? Or is it exactly this lack of tech in those stories that serves as incentive to build it in the first place? Well, maybe it doesn’t have to be the end of the world to seek for ways to cope with a collapse of our modern communication infrastructure either. Just think of natural disasters — an earthquake or hurricane causing a long-term power outage for example. The folks at [sudomesh] tackle exactly this concern with their fully open source, off-grid, solar-powered, LoRa mesh network, Disaster Radio.
The network itself is built from single nodes comprising of a battery-backed solar panel, a LoRa module, and either the ESP8266 or ESP32 for WiFi connectivity. The idea is to connect to the network with your mobile phone through WiFi, therefore eliminating any need for additional components to actually use the network, and have the nodes communicate with each other via LoRa. Admittedly, LoRa may not be your best choice for high data rates, but it is a good choice for long-range communication when cellular networks aren’t an option. And while you can built it all by yourself with everything available on [sudomesh]’s GitHub page, a TTGO ESP32 LoRa module will do as well.
If the idea itself sounds familiar, we did indeed cover similar projects like HELPER and Skrypt earlier this year, showing that LoRa really seems to be a popular go-to for off-grid communication. But well, whether we really care about modern communication and helping each other out when all hell breaks loose instead of just primevally defending our own lives is of course another question.