Electric vehicles are becoming more and more common on the road, but when they’re parked in the driveway or garage there are still some kinks to work out when getting them charged up. Sure, there are plenty of charging stations on the market, but they all have different features, capabilities, and even ports, so to really make sure that full control is maintained over charging a car’s batteries it might be necessary to reach into the parts bin and pull out a trusty Arduino.
This project comes to us from [Sebastian] who needed this level of control over charging his Leaf, and who also has the skills to implement it from the large high voltage switching contactors to the software running its network connectivity and web app. This charging station has every available feature, too. It can tell the car to charge at different rates, and can restrict it to charging at different times (if energy is cheaper at night, for example). It is able to monitor the car’s charge state and other information over the communications bus to the vehicle, and even has a front-end web app for monitoring and controlling the device.
The project is based around an Arduino Nano 33 IoT with all of the code available on the project’s GitHub page. While we would advise using extreme caution when dealing with mains voltage and when interfacing with a high-ticket item like an EV, at first blush the build looks like it has crossed all its Ts and might even make a good prototype for a production unit in the future. If you don’t need all of the features that this charging station has, though, you can always hack the car itself to add some more advanced charging features.
Continue reading “Open Source Electric Vehicle Charging”
For years we’ve seen a trickle of really interesting home automation projects that use the Node-RED package. Each time, the hackers behind these projects have raved about Node-RED and now I’ve joined those ranks as well.
You can get this up and running in less than an hour and I’m going to tackle that as well as examples for playing with MQTT, setting up a web GUI, and writing to log files. To make Node-RED persistent on your network you need a server, but it’s lean enough to run from a Raspberry Pi without issue, and it’s even installed by default in BeagleBone distributions. Code for all examples in this guide can be found in the tutorial repository. Let’s dive in!
Continue reading “Automate Your Life With Node-RED (Plus A Dash Of MQTT)”
It is hard to imagine how the electronics hobby survived without the Internet. You found like-minded people and projects in magazines. And it is even harder to imagine what projects were in the magazines before the widespread availability of CPU chips. Think about it, there are only so many things you can build with a handful of tubes, transistors, and small ICs. But before the computer revolution took over the hobby, there were always a lot of articles about music synthesis. Coming full circle, you can now build a virtual synthesizer on the web using Zupiter, a modular synthesizer that runs in your browser.
That link is actually about Zupiter, but you can go straight to it if you just want to play. However, we had to do a little reading and try some of the examples, too. You can see a video about the synthesizer, below.
Continue reading “Modular Music Synthesis On The Web”
[Josip] has been playing around with race conditions on web interfaces lately, finding vulnerabilities on both Facebook and Digital Ocean. A race condition can occur when a piece of software processes multiple threads using a shared resource.
For example, [Josip] discovered that he was able to manipulate page reviews using just a single Facebook account. Normally, a user is permitted to leave just one review for any given Facebook page. This prevents a single user from being able to skew the page’s overall ranking by making a bunch of positive or negative reviews. The trick to manipulating the system was to intercept the HTTP request that submitted the page review. The request was then replayed over and over in a very short amount of time.
Facebook’s servers ended up processing some of these requests simultaneously, essentially unaware that multiple requests had come in so close together. The result was that multiple reviews were submitted, artificially changing the pages overall ranking even though only one review actually showed up on the page for this user. The user can then delete their single review, and repeat this cycle over and over. It took Facebook approximately two months to fix this vulnerability, but in the end it was fixed and [Josip] received a nice bounty.
The Digital Ocean hack was essentially the exact same process. This time instead of hacking page reviews, [Josip] went after some free money. He found that he was able to submit the same promotional code multiple times, resulting in a hefty discount at checkout time. Digital Ocean wasted no time fixing this bug, repairing it within just ten days of the disclosure.
[Laxman] is back again with another hack related to Facebook photos. This hack revolves around the Facebook mobile application’s “sync photos” function. This feature automatically uploads every photo taken on your mobile device to your Facebook account. These photos are automatically marked as private so that only the user can see them. The user would have to manually update the privacy settings on each photo later in order to make them available to friends or the public.
[Laxman] wanted to put these privacy restrictions to the test, so he started poking around the Facebook mobile application. He found that the Facebook app would make an HTTP GET request to a specific URL in order to retrieve the synced photos. This request was performed using a top-level access token. The Facebook server checked this token before sending down the private images. It sounds secure, but [Laxman] found a fatal flaw.
The Facebook server only checked the owner of the token. It did not bother to check which Facebook application was making the request. As long as the app had the “user_photos” permission, it was able to pull down the private photos. This permission is required by many applications as it allows the apps to access the user’s public photos. This vulnerability could have allowed an attacker access to the victim’s private photos by building a malicious application and then tricking victims into installing the app.
At least, that could have been the case if Facebook wasn’t so good about fixing their vulnerabilities. [Laxman] disclosed his finding to Facebook. They had patched the vulnerability less than an hour after acknowledging the disclosure. They also found this vulnerability severe enough to warrant a $10,000 bounty payout to [Laxman]. This is in addition to the $12,500 [Laxman] received last month for a different Facebook photo-related vulnerability.