Hello. I've wanted to contact you with the e-mail but there isn't any information about you. I have some questions about your project presented in Blackhat 2014. That's are about the ZWAVE protocol. Firstly, I downloaded the grc(Zwave in grc) files from the 'bitbucket'. Is it just for the sniffing the Zwave pkts? It can do the TX like directly turning off the Zwave light? and Could I get the demo videos and the descriptions about it ? Thank you!
Well, I have to admit that it’s been a long time since I wrote here.
Lot of people complained during the past years that DPAPIck was only supporting Windows XP and Vista and basically wanted to know if one day we were going to support newer versions of Microsoft Windows.
Thanks to Francesco Picasso (@dfirfpi), this project now supports Windows versions from XP to the latest Windows 8.1 (sorry, we haven’t tested it on Windows 10 yet). He did the work and sent me a patch that allowed DPAPIck to run against Windows 7 blobs but it was also breaking XP support at the same time. So I took some extra time to give that a bit of polish and to improve a few things on how the tool was processing data.
During the previous part, we were able to use GNU Radio and a Software Defined Radio (SDR) in order to receive and demodulate RF packets.
Now is the time to go a bit further: extract and decode packets and then, the counterpart, encode and send packets back.
Even though I will use my robot vacuum as an example, this blog post can be considered as a simple how-to about writing a simple packet sink in GNU Radio.
First of all, I am pretty happy to write this article because I usually don’t have a lot of opportunities to write about forensics topics on this blog. The main reason for that situation is because I am almost always working on that field for my employer so this does not have a place on this blog . But this time it was related to a spare time project I did during my holidays!
You’re not going to have a lot of details about the whole project because it is still ongoing and moreover I am working on it with a friend and we hope to do a bigger publication once we are done. Anyway, I went through a lot a caveats so I thought it was worth writing about that step in our study.
Few times ago I have published an article about two RFID locks that I encountered while traveling and a rough blackbox analysis of these two technologies. Unfortunately, back then, I only had few samples of key cards regarding Vingcard’s locks and that led me to take false assumptions.
But I was lucky enough very recently as to meet this lock once more. And because it was a three weeks stay, it was pretty easy to purposely tell the reception that my card was not working anymore, a couple of times, in order to have them reprogram it (yay, I’m a bad guy!). The purpose here was, first, to check what values can change over time (they usually encode the duration of the stay instead of the checkout timestamp) and secondly, to ensure that there is not a kind of timestamp-dependant key.
I haven’t talked about this project for a while but I was still working on it. So, what took me so long that I didn’t write about it?
Well, as I told you in Part 1, my final goal is to be able to control the robot vacuum with a GoodFET and a transceiver. The robot relies on an A7105 transceiver which is not directly supported by the GoodFET project and I don’t want to add support for it as I have already written code to support a Chipcon CC2500 transceiver that might be radio-compatible with the Avantcom one.
Knowing all the parameters we need by spying the configuration phase on the SPI bus from the remote control should have been enough to build another remote. But sometimes things don’t go well!