GitHub is an incredibly powerful tool for sharing source code, and its value to the modern hacker can’t be overstated. But there’s at least one downside to effortlessly sharing your source: it’s now much easier for the whole world to find out when you screw up. Back in the day, if you accidentally left a username or password in a tarball hosted on your site, you could pull it down before anyone noticed. But push something like that up to GitHub, and you’ve got a problem on your hands.
For an example, look no farther than this tool that crawls GitHub for Slack webhooks written by [Michele Gruppioni]. Exploiting the fact that Slack webhook links have a predictable format, the tool searches repositories to find code that erroneously includes the authentication token. With the token in hand, an attacker now has the ability to send unsolicited messages into that channel.
But [Michele] restrained himself and didn’t Rickroll the over 6,500 Slack channels he had access to after searching GitHub with his tool. Instead, he sent them all a friendly message explaining their webhook tokens were available on GitHub, and gave them a link to where they could get more information about his project.
Most of the people who contacted him after the fact appreciated that he sent a gentle warning and not something unsavory. Still, we’d recommend caution to anyone looking to expose a vulnerability in this manner. While [Michele] had honorable intentions, it’s certainly not unheard of for an embarrassed administrator to blame the messenger.
When used properly, webhooks can be a very handy way of pushing data into your chat platform of choice. We’ve previously looked at a practical example of a weather station that pushes current conditions into a Discord channel. Just try not to accidentally commit your authentication token to the world’s largest database of open source projects, or you might receive more than you bargained for.
The wildfires in California are now officially the largest the state has ever seen. Over 50,000 people have been displaced from their homes, hundreds are missing, and the cost in property damage will surely be measured in the billions of dollars when all is said and done. With a disaster of this scale just the immediate effects are difficult to conceptualize, to say nothing of the collateral damage.
While not suggesting their situation is comparable to those who’ve lost their homes or families, Electric Imp CEO [Hugo Fiennes] has recently made a post on their blog calling attention to the air quality issues they’re seeing at their offices in Los Altos. To quantify the problem so that employees with respiratory issues would know the conditions before they came into work, they quickly hacked together a method for displaying particulate counts in their Slack server.
The key to the system is one of the laser particle sensors that we’re starting to see more of thanks to a fairly recent price drop on the technology. A small fan pulls air to be tested into the device, where a very sensitive optical sensor detects the light reflected by particles as they pass through the laser beam. The device reports not only how many particles are passing through it, but how large they are. The version of the sensor [Hugo] links to in his blog post includes an adapter board to make it easier to connect to your favorite microcontroller, but we’ve previously seen DIY builds which accomplish the same goal.
[Hugo] then goes on to provide firmware for the Electric Imp board that reads the current particulate counts from the sensor and creates a simple web page that can be viewed from anywhere in the world to see real-time conditions at the office. From there, this data can be plugged into a Slack webhook which will provide an instantaneous air quality reading anytime a user types “air” into the channel.
We’ve covered a number of air quality sensors over the years, and it doesn’t look like they’re going to become any less prevalent as time goes on. If anything, we’re seeing a trend towards networks of distributed pollution sensors so that citizens can collect their own data on their air they’re breathing.
[Thanks to DillonMCU for the tip.]
We love seeing hardware and software from bygone eras getting a new lease on life through modern hacks, as longtime readers can surely attest to. Why leave this stuff to rot in a closet somewhere when it can be pushed into service today? Granted it might not always be the most efficient way to accomplish a task in the 21st century, but at least you’ll net some precious Internet Points for originality.
As a perfect example, take a look at this project which lets you read Slack messages through a Super Nintendo game. If your first thought was that such a thing would involve an unreasonable amount of effort and hoop jumping…then you would be correct. [Bertrand Fan] really had to think outside the box to make this one happen, and even admits a bit of imagination is required on the part of the end-user to use it. But it’s undeniably an original approach, so we hereby bestow the customary Internet Points unto him.
So how does this work, and where do the satellites come in? The key is in a fairly obscure Japanese SNES peripheral called the Satellaview, one of Nintendo’s early attempts at creating an online content delivery system for their consoles. Games designed with Satellaview support would be able to pull down new content from regular satellite broadcasts, not too bad for 1995. This means that if you have the hardware, and happen to own a satellite, you can push your own content into an unmodified SNES. No problem, right?
Alright, [Bertrand] didn’t really use a Satellaview modem plugged into an actual SNES. Plus we’re fairly sure he doesn’t have his own satellite network to broadcast Slack messages with anyway. But it turns out some SNES emulators have support for a virtual Satellaview modem, and there’s even software out there that will let you create new content “downloads” for the system’s included game: BS-X: The Story of The Town Whose Name Was Stolen. All he had to do was connect the dots.
[Bertrand] started by stripping the user interface out of SatellaWave, an open source tool for creating Satellaview content, so that it only need to be provided with an XML file of the content to be “downloaded” by the virtual satellite modem. Using the Slack API, he then came up with way to pull the last 10 messages from a server and push them into his modified version of SatellaWave. Each time somebody posts a new message his software kicks in to produce a new satellite download which automatically gets picked up by the SNES emulator and pops up in the game.
If this is still too practical for you, you can always go all in and run Slack on your Commodore 64.
Continue reading “Slack On The SNES Via Satellite”
Over the past few years, Reddit user [callingyougoulet] has created Boozer, a DIY beer dispenser that keeps track of how much of your brew you have left in your kegs. Installed in a Keezer (a freezer that contains beer kegs and faucets) [callingyougoulet]’s dispenser uses a Raspberry Pi to keep track of things. A series of flow sensors determine how much liquid has passed through them and, when the drink is poured, can calculate how much you poured and how much you have left.
Starting with a chest freezer, [callingyougoulet] built a nice wooden surround as well as installed a tower on top to hold the faucets. The top of the freezer has nice granite tiles covering it, and some LED accent lighting adds to the end product. However, taking the granite off in order to get at the kegs inside takes some time (about 20 minutes.)
Inside the freezer is the Raspberry Pi and four flow sensors, each one connected to a GPIO port on the Pi. After some calibration, the Python code running on the Pi can calculate a pretty close estimate of the amount of liquid poured. There’s also a temperature sensor in the freezer, so that you can tell how cool your beer is.
If the build had stopped there, it would have been a great project as-is, but [callingyougoulet] added twitter, Slack and MQTT outputs as options, so that a home automation system (or the entire internet) can tell how much and when you’ve been drinking and, more importantly, you can know how much is left in your kegs! There are some very cool keg cooling builds on the site, such as, a kegerator built from the ground up, and a very elegant kegerator built on the cheap check them out for ideas!
[Raphael Baron] needed a better way to control his office’s air conditioning units. Sure, they have remotes, but that’s too easy. [Raphael] came up with a solution that uses an ESP8266, a computer, IR LEDs, and a bot that runs on Slack.
[Raphael] built a prototype of the ESP8266 hardware on protoboard and used it to read and record the IR signals from the remote. Once he’d figured out the issues he was having with the IR library he was using, he could use it to send the IR commands to the AC unit. Since their office has two AC units, [Raphael] built a second prototype which had two IR LEDs but didn’t have the IR receiver. Using this he could turn both AC units on and off and set their temperatures.
For the server, [Raphael] turned to Clojure, a dialect of Lisp, which provides easy access to the Java Framework, mainly to get practice working with the language. The server’s main responsibility is to use Slack’s real-time API to listen for messages from a Slack bot and forward them to the ESP. In this way, a user talking to the Slack bot can send it messages which the server forwards to the microcontroller which, in turn, parses the messages and send IR commands to the AC units.
[Raphael] admits that this isn’t the most advanced, professional stuff, but it doesn’t matter. The schematics for the ESP8266 board and the code for both the ESP board and the server are available on GitHub. There seems to be a lot of hacks using Slack, such as this NERF Turret controlled by a Slack bot. Or this jukebox that users can interact with by talking to a Slack bot.
Slack is great, but there are a few small problems with the current implementations. There isn’t a client for Palm, there isn’t a client for the Newton, and there isn’t a client for the Commodore 64. The last of these severe oversights was recently fixed by [Jeff Harris]. He built a native Slack client in 6502 assembly for the Commodore 64.
When dealing with network applications and the C64, the first question that comes to mind is how to talk to the outside world. There are C64 NICs, and ESP dongles, but for this build [Jeff] turned to the C64 Userport. This card edge combination of a serial and parallel port allows the C64 to talk to anything with RS-232, and with a simple adapter, [Jeff] got his old computer talking to a Raspberry Pi connected to the Internet.
The C64 Slack client itself is written in 6502 assembly, and features everything you would expect. The Pi is required to talk to the Slack API, though, and uses a NodeJS app to translate the bits from the C64 to something the API can understand.
Does it work? Of course it does. Slack is just text, after all, and there doesn’t seem to be any PETSCII weirdness here. You can check out a video of the build in action below.
Continue reading “Slack, Backwards Compatible With 1982”
When you have a large software development team working on a project, monitoring the build server is an important part of the process. When a message comes in from your build servers, you need to take time away from what you’re doing to make sure the build’s not broken and, if it’s broken because of something you did, you have to stop what you’re doing, start fixing it and let people know that you’re on it.
[ridingintraffic]’s team uses Jenkins to automatically build their project and if there’s a problem, it sends a message to a Slack channel. This means the team needs to be monitoring the Slack channel, which can lead to some delays. [ridingintraffic] wanted immediate knowledge of a build problem, so with some software, IoT hardware, and a rotating hazard warning light, the team now gets a visible message that there’s a build problem.
An Adafruit Huzzah ESP8266 board is used as the controller, connected to some RF controlled power outlets via a 434MHz radio module. To prototype the system, [ridingintraffic] used an Arduino hooked up to one of the RF modules to sniff out the codes for turning the power outlets on and off from their remotes. With the codes in hand, work on the Huzzah board began.
An MQTT broker is used to let the Huzzah know when there’s been a build failure. If there is, the Huzzah turns the light beacon on via the power outlets. A bot running on the Slack channel listens for a message from one of the developers saying that problem is being worked on, and when it gets it, it sends the MQTT broker a message to turn the beacon off.
There’s also some separation between the internal network, the Huzzahs, and the Slack server on the internet, and [ridingintraffic] goes over the methods used to communicate between the layers in a more detailed blog post. Now, the developers in [ridingintraffic]’s office don’t need to be glued to the Slack channel, they will not miss the beacon when it signals to start panicking!