[Texane] had been thinking about how to monitor the state of his garage door from a remote place. The door itself isn’t around any power outlets, and is a few floors away from where his server would be located in his apartment. This presented a few design challenges – namely, the sensor itself should have a wireless connection to the server, and being low power would be a great idea. This led to the development of a minimalist framework for wireless communication that allows a sensor to run for weeks without a battery swap.
The wireless protocol itself is based on a simple key value pair; each individual sensor, coupled with a NRF905 radio, has passes an address, a key, and a value. There are allowances for checksums and acknowledgement, but as the PDF says, this is a very minimal protocol.
With the software out of the way, [Texane] turned to the hardware. The microcontroller is a simple Arduino clone, paired with a radio and a coin cell on a small board. The micro spends most of its time in a low power state, with the sensor, in this case a reed switch, tied to an interrupt pin.
There was a problem with the power consumption of the radio, though: when the short 17-byte message was transmitting, there was a significant voltage drop. This was okay with a fully charged battery, but with a partially drained coin cell, the possibility of brownouts was high. A big cap in parallel was enough to offset this voltage drop.
It’s still a little expensive for an all-in-one home automation and monitoring system, but developing a functional wireless protocol and the hardware to go with it is no small feat. It’s actually a great piece of kit that [Texane] is sure to find a few uses for.
If you’re old enough to have used a dial-up modem we’d bet you can do an imitation of the sounds it made while connecting. Those not-so-beautiful sounds heralded the dawning of a technological era. But few actually know what each of those distinct sounds were doing. Now’s your chance to learn. This post explains each step in the dail-up handshake process.
This may be the most useful infographic we’ve ever seen. Normally we just seem them as gimmicks, but [Oona Räisänen] really put together something special with this one. Her blog post includes an audio clip so that you can play back the full handshake sounds. The main box on the graphic shows the audio spectrum from that clip, with an explanation below it. But you’ll also want to read through her full write-up for a more narrative description.
The part we found the most interesting is that these modems needed to disable the echo suppression used by the telephone system in order to operate at full-duplex. Apparently land lines disabled the speaker while you were talking so that you didn’t hear your own voice. This was a problem if the modem was trying to send and receive at the same time.
There’s a special type of satisfaction that comes from really understanding how something works at the end of a reverse engineering project. This grid above is the culmination of [Spencer’s] effort to reverse engineer the IR protocol of a Propel ExecuHeli indoor helicopter toy.
The first thing he looked at was the three different controller channels which can be selected to allow multiple helicopters to be used in the same area. [Spencer] was surprised that they all used the same carrier frequency. The secret must be in the coded packets so his next challenge was to figure out how the data was being transmitted via the Infrared signal. It turns out the packets are using pulse-length coding (we were unfamiliar with this protocol but you can read a bit more about it here). The last piece of the puzzle was to capture packets produced by each unique change of the control module. With each bit (except for bit 11) accounted for he can now format his own codes for a controller replacement. Perhaps he’s looking to make the helicopter autonomous?
[Arpad] has spent quite a bit of time reverse-engineering a home automation system, and, as he is quick to point out, presents the information learned for informational purposes only. He’s really done his homework (and documented it well), looking into the US patent application, and figuring out how the protocol works.
If you’re wondering how someone is able to send a signal over an AC sine wave, at least one technique is the proprietary [Universal Powerline Bus]. This works by sending precisely times pulses in conjunction with the wave that would exist normally. Given the correct software on the other end, this can then be decoded and used for whatever data transfer is necessary.
Although as engineers and technologists, we certainly don’t condone stealing patents, part of point of one is that others are allowed to learn your secrets in exchange for some legal protection. [Arpad]’s motivation in doing this is that the technology is only widely available in the US with our puny 120 VAC 60Hz power. With this knowledge, he’s been able to transfer it to work with European 230 VAC 50Hz.
Continue reading “Reverse Engineering an AC Signal Protocol”
[Arthur] built an IR receiver to use with XBMC. Because it’s software specific he identifies the device on USB as a keyboard, and passes the IR commands as keystrokes used by the popular media platform.
Normally, homebrew IR receivers would use LIRC, the Linux Infrared Remote Control software. But this method doesn’t require you to have that running. In fact, it doesn’t need any setup on the PC end of things. Any remote that uses the Sony SIRC protocol will work off the bat.
[Arthur] chose a PIC 18f2550 for the project. It is a popular microcontroller because it has built-in USB handling. We’re a bit skeptical of the hardware design though. We didn’t see specifically which IR receiver he’s using, but many require some type of filtering so check the suggested layout in the datasheet for your module.
As a followup to last week’s post on automated protocol analysis, [Tod Beardsley] has written up how to start analyzing a protocol manually. He walks through several examples to show how to pull out the interesting bits in binary protocols. His first step was sending 10 identical select statements and capturing the outbound packets. He used the Ruby library PacketFu to help with the identification. It compared the ten packets and highlighted one byte that was incrementing by four with each packet, probably a counter. Looking at the response indicated a few other bytes that were also incrementing at the same rate, but at different values. Running the same query on two different days turned up what could be a timestamp. Using two different queries helped identify which byte was responsible for the statement length. While you may not find yourself buried in HEX on a daily basis, the post provides good coverage of how to think critically about it.
[I)ruid] from BreakingPoint Labs has been doing quite a bit of protocol reverse engineering as part of his work. He put together a post covering some of the tools that have been useful for this task. Text-based protocols have a lot of human readable characters that can help you identify fields. Binary protocols don’t have this luxury though. He recommends the Protocol Informatics Project for tackling these situations. It applies bioinformatics algorithms to network traffic. You give it a packet dump of the protocol and it compares them to find similarities the same way genetic sequences are compared. It can be confused by protocols that waste a lot of space, but it’s still a very clever approach to reversing.