It is hard to remember that practical computers haven’t been around for even a century, yet. Modern computers have been around an even shorter period. Yet somehow people computed tables, kept ledgers, and even wrote books without any help from computers at all. Sometimes they just used brute force but sometimes they used little tricks that we’ve almost forgotten. For example, only a few of us remember how to use slide rules, but they helped send people to the moon. But what did database management look like in, say, 1925? You might think it was nothing but a filing cabinet and someone who knew how to find things in it. But there was actually a better system that had fairly wide use.
Vending machines used to be a pretty simple affair: you put some coins in, and food or drink that in all likelihood isn’t fit for human consumption comes out. But like everything else today, they are becoming increasingly complex Internet connected devices. Forget fishing around for pocket change; the Coke machine at the mall more often than not has a credit card terminal and a 30 inch touch screen display to better facilitate dispensing cans of chilled sugar water. Of course, increased complexity almost always goes hand in hand with increased vulnerability.
So when [Matteo Pisani] recently came across a vending machine that offered users the ability to pay from an application on their phone, he immediately got to wondering if the system could be compromised. After all, how much thought would be put into the security of a machine that basically sells flavored water? The answer, perhaps not surprisingly, is very little.
The write-up [Matteo] has put together is an outstanding case study in hacking Android applications, from pulling the
.apk package off the phone to decompiling it into its principal components with programs like
jadx. He even shows how you can reassemble the package and get it suitable for reinstallation on your device after fiddling around with the source code. If you’ve ever wanted a crash course on taking a peek inside of Android programs, this is a great resource.
By snooping around in the source code, [Matteo] was able to discover not only the location of the encrypted database that serves as the “wallet” for the user, but the routine that generates the encryption key. To cut a long story short, the program simply uses the phone’s IMEI as the key to get into the database. With that in hand, he was able to get into the wallet and give himself a nice stack of “coins” for the next time he hit the vending machines. Given his new-found knowledge of how the system works, he even came up with a separate Android app that allows adding credit to the user’s account on a rooted device.
In the video after the break, [Matteo] demonstrates his program by buying a soda and then bumping his credit back up to buy another. He ends his write-up by saying that he has reported his findings to the company that manufacturers the vending machines, but no word on what (if any) changes they plan on making. At the end of the day, you have to wonder what the cost-befit analysis looks like for a full security overhaul when when you’re only selling sodas and bags of chips.
When he isn’t liberating carbonated beverages from their capitalistic prisons, he’s freeing peripherals from their arbitrary OS limitations. We’re starting to get a good idea about what makes this guy tick.
Whether you want some quick and dirty data storage, or simply don’t have that heavy requirements for your local database system, SQLite is always a good choice. With its portable single-file approach, bindings to all major languages, and availability on systems of all sizes, it is relatively easy to integrate a SQLite database in your undertakings. And if you tend to develop directly in your production environment, you may be interested to hear that the folks at [aergo] made this a lot more flexible (and interesting) by adding Git-style branching to the SQLite engine.
Similar to Git, each database operation is now stored as a commit with a unique id as reference point, and new branches will keep track how they diverge from their parent reference point. This essentially lets you modify your data set or database schema on the fly, while keeping your original data not only untouched, but fully isolated and functional. Unfortunately, merging branches is not yet supported, but it is planned for the near future.
In case you don’t see much use for git-alike functionality in a database, how about the other way around then: using Git as a database, among other tricks?
KiCad, the open source EDA software, is popular with Hackaday readers and the hardware community as a whole. But it is not immune from the most common bane of EDA tools. Managing your library of symbols and footprints, and finding new ones for components you’re using in your latest design is rarely a pleasant experience. Swooping in to help alleviate your pain, [twitchyliquid64] has created KiCad Database (KCDB). a beautifully simple web-app for searching component footprints.
The database lets you easily search by footprint name with optional parameters like number of pins. Of course it can also search by tag for a bit of flexibility (searching Neopixel returned the footprint shown above). There’s also an indicator for Kicad-official parts which is a nice touch. One of our favourite features is the part viewer, which renders the footprint in your browser, making it easy to instantly see if the part is suitable. AngularJS and material design are at work here, and the main app is written in Go — very trendy.
The database is kindly publicly hosted by [twitchyliquid64] but can easily be run locally on your machine where you can add your own libraries. It takes only one command to add a GitHub repo as a component source, which then gets regularly “ingested”. It’s great how easy it is to add a neat library of footprints you found once, then forget about them, safe in the knowledge that they can easily be found in future in the same place as everything else.
If you can’t find the schematic symbols for the part you’re using, we recently covered a service which uses OCR and computer vision to automatically generate symbols from a datasheet; pretty cool stuff.
Has work been a little stressful this week, are things getting you down? Spare a thought for an unnamed sysadmin at the GitHub-alike startup GitLab, who early yesterday performed a deletion task on a PostgreSQL database in response to some problems they were having in the wake of an attack by spammers. Unfortunately due to a command line error he ran the deletion on one of the databases behind the company’s main service, forcing it to be taken down. By the time the deletion was stopped, only 4.5 Gb of the 300 Gb trove of data remained.
Reading their log of the incident the scale of the disaster unfolds, and we can’t help wincing at the phrase “out of 5 backup/replication techniques deployed none are working reliably or set up in the first place“. In the end they were able to restore most of the data from a staging server, but at the cost of a lost six hours of issues and merge requests. Fortunately for them their git repositories were not affected.
For 707 GitLab users then there has been a small amount of lost data, the entire web service was down for a while, and the incident has gained them more publicity in a day than their marketing department could have achieved in a year. The post-mortem document makes for a fascinating read, and will probably leave more than one reader nervously thinking about the integrity of whichever services they are responsible for. We have to hand it to them for being so open about it all and for admitting a failure of their whole company for its backup failures rather than heaping blame on one employee. In many companies it would all have been swept under the carpet. We suspect that GitLab’s data will be shepherded with much more care henceforth.
We trust an increasing amount of our assets to online providers these days, and this tale highlights some of the hazards inherent in placing absolute trust in them. GitLab had moved from a cloud provider to their own data centre, though whether or not this incident would have been any less harmful wherever it was hosted is up for debate. Perhaps it’s a timely reminder to us all: keep your own backups, and most importantly: test them to ensure they work.
Thanks [Jack Laidlaw] for the tip.
Rack server image: Trique303 [CC BY-SA 4.0], via Wikimedia Commons.
There are many ways to divide the hacker community into groups. Tubes vs transistors. Emacs vs VI, microcontroller vs discrete component designers. However, one of the more fundamental divisions in the community is how you organize your parts. We’ve seen giant warehouses with carefully organized bins and cabinets full of components, and we’ve seen storage crates with tangles of wires and bits of electron-bending components scattered among the wires.
If you are in the former camp, you’d probably enjoy partsbox.io (see image, right). If you are in the latter group, you probably need to check it out even more than the other people. The idea is simple: an online place to keep an inventory of your electronic parts. The implementation is not as simple, though. The web application will work on a mobile device or just about anywhere. You can view your components by type, by location (the shoe box under the bed vs the parts bin in the closet), or by a project’s bill of materials. You can use “known” parts or create private parts for things no one else has (for example, your custom PC boards, or those 3D printed brackets you made to hold a microswitch). If you add data for a component you can make it available to other users.
When a consumer electronics device is sold in the US, especially if it has a wireless aspect, it must be tested for compliance with FCC regulations and the test results filed with the FCC (see preparing your product for FCC testing). These documents are then made available online for all to see in the Office of Engineering and Technology (OET) Laboratory Equipment Authorization System (EAS). In fact, it’s this publishing in this and other FCC databases that has led to many leaks about new product releases, some of which we’ve covered, and others we’ve been privileged enough to know about before the filings but whose breaking was forced when the documents were filed, like the Raspberry Pi 3. It turns out that there are a lot of useful things that can be accomplished by poring over FCC filings, and we’ll explore some of them.