There are many ways to measure radioactivity level, semiconductor detectors sense interactions between ionizing radiation and p-n junction. Because in hobbyist area most popular are Geiger-Muller based detectors (in short: not a semiconductor but lamp based devices), I think it’s a cool idea to take a look at this approach.
In this post I will present such home-made sensor and a set of software to parse collected results.
A nice build log of ZeroBoy portable retropie project, that is available on Github:
You know when you see something and it give you instant inspiration and you also see a few ways you would also improve it. The thing I seen was wonky resistor score zero it’s basically a raspberry pi “hat” that has buttons in the layout of a nes controller. What I first thought was to make my own “hat” but flip it 180 degrees and add pass though pins so I could add a screen on top of that. Joint me below for my journey I went though.
BLE (Bluetooth Low Energy) sensor devices like the Hexiwear are great, but they cannot store a large amount of data. For a research project I have to collect data from many BLE devices for later processing. What I’m using is a Python script running on the Raspberry Pi which collects the data and stores it on a file
There’s a lot of reasons you might want to emulate the keyboard on your Commodore 64. The ravages of time and dust may have put the original keyboard out of order, or perhaps you need to type in a long program and don’t fancy pecking away with the less-than-stellar feedback of the standard keys. [podstawek] has come up with the solution: a Commodore 64 keyboard emulator that works over serial.
It’s a simple concept, but one that works well. A Python script accepts incoming keypresses or pre-typed text, then converts them into a 6-bit binary code, which is sent to an Arduino over the serial connection. The Arduino uses the 6-bit code as addresses for an MT8808 crosspoint switch.
The MT8808 is essentially an 8×8 matrix of controllable switches, which acts as the perfect tool to interface with the C64’s 8×8 keyboard matrix. Hardware wise, this behaves as if someone were actually pressing the keys on the real keyboard. It’s just replacing the original key switches with an electronic version controlled by the Arduino.
[podstawek] already has the setup working on Mac, and it should work on Linux and Windows too. There’s a little more to do yet – modifying the script to allow complex macros and to enable keys to be held – so check out the Github if you want to poke around in the source. Overall it’s a tidy, useful hack to replace the stock keyboard.
It’s an ingenious trick — a Python script goes through the commit history of a repository, looking at every string of text greater than 20 characters, and analyzing its Shannon entropy. This is a mathematical way of determining if it looks like a relatively random string of numbers and letters. If it has high entropy, it’s probably a key of some sort.
Sharing source code is always a double-edged sword for security. Any flaws are out for all to see, and there are both those who will exploit the flaws and those who will help fix them. It’s a matter of opinion if the benefits outweigh the gains, but it’s hard to argue with the labor benefits of getting more eyes on the code to hunt for bugs. It’s our guess though, that a lot of readers have accidentally committed secret keys in a git repository and had to revert before pushing. This tool can crawl any publicly posted git repo, but might be just as useful in security audits of your own codebase to ensure accidentally viewable keys are invalidated and replaced.
Like so many other home appliances, it’s likely that even your air conditioner has a serial interface buried inside it. If you’re wondering why, it’s because virtually every microcontroller on the planet has a UART built in, and it’s highly useful for debugging during the development process, so it makes sense to use it. Thus, it was only a matter of time before we saw a hacked airconditioner controlled by a Raspberry Pi.
[Hadley] was growing frustrated with the IR remote for his Mitsubishi air conditioner; it can issue commands, but it’s a one way interface – there’s no feedback on current status or whether commands are received, other then the occasional beep or two. Deciding there had to be a better way, [Hadley] grabbed a Saleae Logic Analyser and started probing around, determining that the unit spoke 5 V TTL at 2400 bps with even parity. The next step was to start talking back.
The post doesn’t go into detail about how the messaging protocol was decoded – we’d love to see the process involved. From there it was a simple matter of rolling up some Python scripts to talk serial to the air conditioner. The system allows control over HTML using MQTT over websockets.
The real benefit here is the two-way communication – not only can commands be sent to the unit, but messages can be received as well. The air conditioner will both confirm commands received, as well as send updates when changes are made using the IR remote – this allows the controller to remain in sync with the air conditioner’s current state.
This project demonstrates a much more powerful way of automating your HVAC system at home than just simple on-off control, and merely requires some basic digital hacking skills along with the know-how to safely work with mains-powered appliances. As proof you can try this yourself, someone’s ported the code to the ESP8266 already! If you’re keen to learn more about working with your HVAC hardware, why not read up on what it takes to be a HVAC technician?
Puzzles provide many hours of applied fun beyond any perfunctory tasks that occupy our days. When your son or daughter receives a snake cube puzzle as a Christmas gift — and it turns out to be deceptively complex — you can sit there for hours to try to figure out a solution, or use the power of Python to sort out the serpentine conundrum and use brute-force to solve it.
Finding himself in such a scenario, [Randy Nuss] walks us through his solution while giving insight into how he approaches writing code — learning other methods of problem solving can be a valuable experience in itself, and thematically fitting, considering this particular case! [Nuss] includes his final code near the end of his post, but his write up instead outlines it in enough detail that would guide others along the correct path. Once it ran successfully, he was cajoled into creating a visualization of the solution since the actual code completes in less than a second.
If a hack is a means to make a given task easier to accomplish, then some fancy coding to solve a puzzle — while perhaps defeating the purpose — is arguably still a hack that simply uses a different avenue. Sometimes, the puzzle winds up being the hack itself when you are gifting something special.
It’s been about a year and a half since the Batteroo, formally known as Batteriser, was announced as a crowdfunding project. The premise is a small sleeve that goes around AA and AAA batteries, boosting the voltage to extract more life out of them. [Dave Jones] at EEVblog was one of many people to question the product, which claimed to boost battery life by 800%.
Batteroo did manage to do something many crowdfunding projects can’t: deliver a product. Now that the sleeves are arriving to backers, people are starting to test them in the wild. In fact, there’s an entire thread of tests happening over on EEVblog.
One test being run is a battery powered train, running around a track until the battery dies completely. [Frank Buss] wanted to run this test, but didn’t want to manually count the laps the train made. He whipped up a script in Python and OpenCV to automate the counting.
The script measures laps by setting two zones on the track. When the train enters the first zone, the counter is armed. When it passes through the second zone, the lap is recorded. Each lap time is kept, ensuring good data for comparing the Batteroo against a normal battery.
The script gives a good example for people wanting to play with computer vision. The source is available on Github. As for the Batteroo, we’ll await further test results before passing judgement, but we’re not holding our breath. After all, the train ran half as long when using a Batteroo.
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!
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.