SKiDL is very, very cool. It’s a bit of Python code that outputs a circuit netlist for KiCAD.
Why is this cool? If you design a PCB in KiCAD, you go through three steps: draw the schematic, assign footprints to the symbolic parts, and then place them. The netlist ties all of these phases together: it’s a list of which parts are connected to which, the output of schematic capture and the input for layout. The ability to generate this programmatically should be useful.
For instance, you could write a filter circuit generator that would take the order, cutoff, and type of filter as inputs, and give you a spec’ed netlist as output. Bam! In your next design, when you need a different filter, you just change a couple of variables. Writing your circuits as code would make arranging the little sub-circuits modular and flexible, like functions in code.
At the very least, it’s an interesting alternative to the mouse, click, drag, click paradigm that currently dominates the schematic capture phase. Just as some of you like OpenSCAD for 3D modelling, some of you will like SKiDL for circuit design.
We’ve become so accustomed to the circuit diagram as the means of thinking about circuits that we’re not sure that we can ever give up the visual representation entirely. Maybe designing with SKiDL will be like sketching out block diagrams, where each block is a bit of Python code that generates a circuit module? Who knows? All we know is that it sounds potentially interesting, and that it’ll certainly be mind-expanding to give it a try.
Give it a shot and leave feedback down in the comments!
[Donncha O’Cearbhaill] has successfully exploited two flaws in Apport, the crash report mechanism in Ubuntu. Apport is installed by default in all Ubuntu Desktop installations >= 12.10 (Quantal). Inspired by [Chris Evan] work on exploiting 6502 processor opcodes on the NES, [Donncha] describes the whole process of finding and exploiting a 0-day on a modern linux system.
One of the flaws, tracked as CVE-2016-9949, relies on a python code injection in the crash file. Apport blindly uses the python eval() function on an unsanitized field (CrashDB) inside the .crash file. This leads directly to arbitrary python code execution. The other flaw, tracked as CVE-2016-9950, takes advantage of a path traversal attack and the execution of arbitrary Python scripts outside the system hook_dirs. The problem arises when another field (Package) from the crash report file is used without sanitizing when building a path to the package hook files.
CVE-2016-9949 is easily exploitable, if an attacker can trick a user into opening a specially crafted file (apport .crash file), the attacker can execute the python code of his/her choice. Two details make it a very interesting exploit.
The first thing to note is the exploit’s reliability. Given that it is pure python code execution, an attacker doesn’t have to worry about ASLR, Non-Exec Memory, Stack Canaries and other security features that Ubuntu ships by default. As the author notes:
“There are lots of bugs out there which don’t need hardcore memory corruption exploitation skills. Logic bugs can be much more reliable than any ROP chain.”
Another interesting detail is that the exploit file doesn’t need to have the .crash extension, as long as its content starts with the string “ProblemType: ” and the file extension is not associated already with other software, Ubuntu considers it being of mime-type type=”text/x-apport” (for example, .ZlP or .0DF). This significantly improves the chances of an unsuspecting user being fooled into open the file.
Continue reading “Reliably Exploiting Apport in Ubuntu”
The PicBerry is a student final project by [Advitya], [Jeff], and [Danna] that takes a hybrid approach to creating a portable (and affordable) combination digital oscilloscope and function generator. It’s based on the Raspberry Pi, features an intuitive Python GUI, and can generate and measure simultaneously.
But wait! The Raspberry Pi is a capable little Linux machine, but meeting real-time deadlines isn’t its strong suit. That’s where the hybrid approach comes in. The Pi takes care of the user interface and other goodies, and a PIC32 over SPI is used for 1 MHz sampling and running a DAC at 500 kHz. The idea of combining them into PicBerry is to get the best of both worlds, with the Pi and PIC32 each doing what they are best at. The readings are sent in batches from the PIC32 to the Pi, where the plot is updated every 30 ms so that user does not perceive any visible lag.
The project documentation notes that improvements can be made, the speeds are a far cry from regular bench equipment, and the software lacks some typical features such as triggering, but overall not bad at all for under $50 of parts. In fact, there are hardly any components at all beyond the Raspberry Pi, the PIC32, and a MCP4822 digital-to-analog converter. A short demo video is embedded below.
Continue reading “Hybrid Raspberry Pi + PIC32 = Oscilloscope and Function Generator”
First there was [Geohot]’s lofty goal to build a hacker’s version of the self-driving car. Then came comma.ai and a whole bunch of venture capital. After that, a letter from the Feds and a hasty retreat from the business end of things. The latest development? comma.ai’s openpilot project shows up on GitHub!
If you’ve got either an Acura ILX or Honda Civic 2016 Touring addition, you can start to play around with this technology on your own. Is this a good idea? Are you willing to buy some time on a closed track?
A quick browse through the code gives some clues as to what’s going on here. The board files show just how easy it is to interface with these cars’ driving controls: there’s a bunch of CAN commands and that’s it. There’s some unintentional black comedy, like a (software) crash-handler routine named crash.py.
What’s shocking is that there’s nothing shocking going on. It’s all pretty much straightforward Python with sprinklings of C. Honestly, it looks like something you could get into and start hacking away at pretty quickly. Anyone want to send us an Acura ILX for testing purposes? No promises you’ll get it back in one piece.
If you missed it, read up on our coverage of the rapid rise and faster retreat of comma.ai. But we don’t think the game is over yet: comma.ai is still hiring. Are open source self-driving cars in our future? That would be fantastic!
Via Endagadget. Thanks for the tip, [FaultyWarrior]!
We take our mother tongue for granted, a language we learn as young children without realizing the effort involved. It is only when as adults we try to pick up another language that we fully understand how much hard work surrounds each acquired word.
Depending on who you listen to, estimates vary as to the size of a typical native English speaker’s vocabulary. The ballpark figures seem to put most adults under 20 thousand words, while graduates achieve somewhere around 23 thousand words. It’s a subject [Alex Eames] became interested in after reading a BBC article on it, and he decided to write his own software to produce a personal estimate.
His Python script takes the Scrabble word list, and presents the user with a list of words, for each one of which they have to indicate their comprehension. After a hundred words have been presented it calculates an estimate of the size of the user’s vocabulary. [Alex] wrote it on and for the Raspberry Pi, but it should work quite happily on any platform with Python 3. It certainly had no problem with our Ubuntu-based PC.
There is plenty of opportunity for bragging over the size of one’s vocabulary with a script like this one, but it’s something of a statistical leveler in that if you are truthful in your responses it will almost certainly put you exactly where you might expect for your age or level of education. If you want to know the result this script returned for a Hackaday scribe, for example, the answer is 23554.
This subject is a slight departure into software from our usual hardware subject matter, but it’s one of those tests that becomes rather a consuming interest when performed competitively among a group of friends. How well will you fare?
[Nurgak] shows how one can use some of the great robotic tools out there to simulate a robot before you even build it. To drive this point home he builds the tutorial off of the easily 3D printable and buildable Robopoly platform.
The robot runs on Robot Operating System at its core. ROS is interesting because of its decentralized and input/output agnostic messaging system. For example, if you leave everything alone but swap out the motor output from actual motors to a simulator, you can see how the robot would respond to any arbitrary input.
[Nurgak] uses another piece of software called V-REP to demonstrate this. V-REP is a simulation suite for robotics and has a few ROS nodes built in. So in order to make a simulated line-following robot, [Nurgak] tells V-REP to send a simulated camera image to the decision making node of the robot in ROS. It then sends the movement messages back to V-REP which drives the pretend robot around.
He runs through a few more examples, proving that it’s entirely possible to become if not a roboticist, at least a really good AI programmer without ever dropping the big money on parts to build a robot.
It wasn’t long ago that faced with a controller project, you might shop for something with just the right features and try to minimize the cost. These days, if you are just doing a one-off, it might be just as easy to throw commodity hardware at it. After all, a Raspberry Pi costs less than a nice meal and it is more powerful than a full PC would have been not long ago.
When [Joe Coburn] wanted to make a pan and tilt webcam he didn’t try to find a minimal configuration. He just threw a Raspberry Pi in for interfacing to the Internet and an Arduino in to control two RC servo motors. A zip tie holds the servos together and potentially the web cam, too.
You can see the result in the video below. It is a simple matter to set up the camera with the Pi, send some commands to the Arduino and hook up to the Internet.
Continue reading “Pan and Tilt with Dual Controllers”