Porting rfcat to cheap hardware?

[AsFaBw]

I really love rfcat... ...although the available hardware seems to be for me quite expensive (starting with the TI CC1111EMK ~70Euro as the black chronos board is not available any more). I wonder for some time, whether there is a possibility to port rfcat for cheaper hardware.

One device I came across is the Max!Cube ( https://www.eq-3.de/produkte/max-heizungssteuerung/max-hausloesung/bc-lgw-o-tw.html ). The device has an CC1101 and is available from 22,95 inclusive shipping (within Germany).

There is already custom firmware available for homeautomation ( https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices/CUBe ).

There is also the possibility to add up to 3 further cheap CC1101 boards into the device. That could allow to operate one CC1101 in monitor mode, while another could be sending.

Is there somebody out there having the software capabilities to merge the two projects (rfcat/MaxCube interface).

I would be interested in your thoughts and comments...

[atlas0fd00m]

hey @AsFaBw , thank you for your kind words! we love RfCat as well, and welcome contributions for porting it to other hardware.

sadly, the cheaper boards i've seen that RfCat works on already seem to be discontinued (Ciseco URF/SRF USB dongles featuring the CC1111).

porting RfCat to other boards with CC1101 radios is possible, but non-trivial. the base RfCat firmware is centered around the 8051 microcontroller in the CC1111. the CC1111 wraps together the CC1101 radio core along with a 8051 microcontroller core and a USB controller. the CC1101 is just the radio, and relies on any number of other microcontrollers and a SPI interface to control the radio. this means a custom firmware for whatever other microcontroller core and USB stack is necessary to be written, basically from scratch. if that's part of the fun for you, awesome! the command and control interface is not that difficult to implement, assuming the USB stack doesn't limit you in some important way. to that end, writing USB firmware is a daunting task, and getting everything correct on even one platform is a new dimension in firmware implementation. i learned a lot, but don't currently have the kind of time it takes to port to another platform.

hope this helps, and keep hacking! @

[AsFaBw]

Hi atlas0fd00m,

thanks a lot for the fast feedback and kind of warning. I had a look to the code and recognize what you mean. To get it stable seems for me not like a weekend task😊

I made my first experiences with a CC1101 standalone and also with a CC430 in a chronos watch (https://www.youtube.com/watch?v=k_Fw7ZacG9s / https://www.youtube.com/watch?v=jKvlf8iOvZk )… …but those projects are small against the code size of rfcat… …so I have some respect to go for it😊

It is really a pitty that all the cheap solutions are not available on the market any more.

Best regards & thanks again, Thomas

[FFY00]

@atlas0fd00m do you have any documentation related to the actual RfCat (host) <-> MCU (device) transport packets? It doesn't seem that hard to implement such a communication stack in a cheap microcontroller, I was thinking Atmel or STMicro ones. That would make it easily portable between devices since it can make use of the Arduino platform and/or the STM32 ecosystem. TBH I am more inclined to the STM32 platform as it has more processing power, is more extensible and has proper debug support (SWD and JTAG w/ OpenOCD). Either way, even that would be easily ported to Arduino.

[atlas0fd00m]

no docs aside from the code. on the Python side, you can find the details in rflib/chipcon_usb.py, particularly in send() and runEP5_recv().

it's a super simple protocol. the idea is to provide a little C2 inside the target hardware. we started off with memory peek and poke capabilities, and built from there.

the protocol is at it's foundation unidirectional, where the dongle can originate messages to the Python side and obviously the Python client can originate messages to the dongle. to achieve this, the Python client polls the dongle repeatedly (direct USB EP5 access). however... if the Python client originates communication, it almost always expects a response (see code on both sides to see what i mean)

there is one minor difference between Python-originated and dongle-originated messages.
each dongle-originated message starts with a "@" character so that both sides can resync if something gets out of sync. (the Python code chops off and throws away anything up to the next @ symbol in this case).

however, the protocol from there is basically the same in both directions, as indicated by the Python handler code: msg = "%c%c%s%s"%(app,cmd, struct.pack("<H",len(buf)),buf)

1 byte "application" (typically this is used to separate "system" functions from RfCat or other custom apps 1 bytes "command" (some refer to this as the "verb") 2 bytes (LSB) - length of data N bytes - data

on the dongle-side, received messages are handled in the next main loop iteration, based on the app/cmd combo, and a response sent back.

on the Python-side, received messages deposited into an appropriate "mailbox" until accessed. if the message is a response, chances are good the originating code is waiting for the response so it's handled immediately. alternately, in the case of a the SYSTEM app, debug messages and the like are handled before being pushed into the mailbox system.

does this help? i understand that the raw USB nature of RfCat might cause some difficulties. the purpose of RfCat's initial stack was to implement the full USB stack in one file, without licensing cost/constraint. if you end up with a chip you need to modify that approach, we could potentially create a module for accessing your dongle in a slightly different way.

[AsFaBw]

Thanks a lot for the detailed explanation!!!

You mentioned the cheaper Ciseco SRF sticks. I finally found them to be on final sale on: https://www.watterott.com/de/SRF-Module-cased-URF https://www.watterott.com/de/URF-Module-uncased In contrast to the description they came as expected with a CC1111 instead of the claimed CC1110. So might be a choice for others. Further option, that was not clear to me and may be to some others. The Yardstick One GitHub includes the gerber files for PCB production...

[AsFaBw]

May be also not cheap solution if no motherboard is available yet... ...but could also be an interesting neighbor... https://github.com/greatscottgadgets/greatfet/wiki/Neighbors

[crazyquark]

Hi @AsFaBw, just ordered one of those last SRF modules from Watterott. Do you know if the needed pins are exposed for flashing? (Oops should have thought of that BEFORE...)

[AsFaBw]

Yes, they are available. You can open the plastic housing, connect the programmer, program it,, and then close the housing again.

By the way: another alternative may be something like following https://github.com/AsFaBw/greatfet-erica ...just started and not sure if it will burn or work:-)

[crazyquark]

I actually got the one without housing... who needs that :) Thanks for the reply.

[crazyquark]

Hi @AsFaBw, Could you point me in the right direction? I got the uncased URF module from Watterott but I do not know what pins can be used for flashing(I suspect the DD and DC pins are not available on the board...)

[AsFaBw]

Hi @crazyquark, I have the cased one, which is a bit different. But first of all have a look to http://www.ti.com/lit/ug/swru197h/swru197h.pdf figure 6. Here you see that P2.1 is DD and P2.2 is DC. In the datasheet http://www.ti.com/lit/ds/symlink/cc1110-cc1111.pdf you see on page 29, that pin 15 is P2_1 and 16 P2_2. Zooming in http://www.picaxe-shop.de/URF-Module-ohne-Gehaeuse you see that those two pins are routed to two testpoints. So I would connect there. On the cased version, the signals are routed to some connector wholes. I just hold the wires through that and programmed it (without any soldering).

[crazyquark]

@AsFaBw thanks a lot!

[crazyquark]

@AsFaBw me again :)... So I wired it up like in this post: https://projectaweek.com/2016/04/11/rfcat-on-ez430-chronos-dongle-with-cc-debug/ However, the CC debugger does not detect the chip, no matter what I do. Maybe I need to put in bootloader mode or something before connecting?

P.S. I think the RST pin id not connected properly?

I figured it out, the RESET_N pin is actually broken out to a pad on the back of the board, RST is routed via a resistor to DTR actually... so not useful.

I managed to flash it after all with TI's Flash Programmer and CC Debugger.

[AsFaBw]

Just to be sure. You should NOT connect the usb side of the stick. Just the stick with the cables to the Cc Debugger.

Von meinem iPhone gesendet

Am 07.09.2019 um 13:59 schrieb Cristian Sandu notifications@github.com:

@AsFaBw me again :)... So I wired it up like in this post: https://projectaweek.com/2016/04/11/rfcat-on-ez430-chronos-dongle-with-cc-debug/ However, the CC debugger does not detect the chip, no matter what I do. Maybe I need to put in bootloader mode or something before connecting?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[maximevince]

I started working on porting to cc1101 via SPI. My current set-up is a CC1101 connected through SPI to a Raspberry Pi. I am using wiringpi make SPI access easy, but that's just a thin layer, which can be swapped to any SPI interface API.

Porting is not going to be trivial, since many of the tasks executed on the microcontroller must now be done on the host, in this case the RPi running the rfcat python application.

Note that not much is functional for now. It can just detect the CC1101 dongle connected to SPI. But if you want to join the fun: https://github.com/maximevince/rfcat/tree/rpi_spi I push more changes in the comings days / months.

[atlas0fd00m]

nice work, @maximevince :) i applaud your direction and passion! let me know if i can answer any questions.

@

[maximevince]

@atlas0fd00m thanks! I was wondering about the direction to take: Currently, I started by implementing most of the CPU logic that would be running on the cc1111, in python. Now, I am thinking of moving this to a separate C application on the RPi, which would separate application login in python, from the device implementation handing the CC1xxx interrupts etc... It would also keep the send/receive functions in python more streamlined between chipcon and cc1101. Then, I found out about the Metasploit hardware bridge API. But as I understand it, this does not plug between the hardware and the python application, but rather make the complete Python application available remotely, correct?

[YJesus]

Hi @crazyquark, I have the cased one, which is a bit different. But first of all have a look to http://www.ti.com/lit/ug/swru197h/swru197h.pdf figure 6. Here you see that P2.1 is DD and P2.2 is DC. In the datasheet http://www.ti.com/lit/ds/symlink/cc1110-cc1111.pdf you see on page 29, that pin 15 is P2_1 and 16 P2_2. Zooming in http://www.picaxe-shop.de/URF-Module-ohne-Gehaeuse you see that those two pins are routed to two testpoints. So I would connect there. On the cased version, the signals are routed to some connector wholes. I just hold the wires through that and programmed it (without any soldering).

Hi, I have the same srf case than you, as TI manuals says for smart RF minimum connection I need to pair DD and DC that I have found in cc debuger connector but I can't find it in SRF. Could you tell me which holes correspond with the pins ? Thank you !!

[YJesus]

ping @AsFaBw

[YJesus]

@AsFaBw me again :)... So I wired it up like in this post: https://projectaweek.com/2016/04/11/rfcat-on-ez430-chronos-dongle-with-cc-debug/ However, the CC debugger does not detect the chip, no matter what I do. Maybe I need to put in bootloader mode or something before connecting?

P.S. I think the RST pin id not connected properly?

I figured it out, the RESET_N pin is actually broken out to a pad on the back of the board, RST is routed via a resistor to DTR actually... so not useful.

I managed to flash it after all with TI's Flash Programmer and CC Debugger.

Hi @crazyquark after no luck with SRF I have bought the same of you. I have URF V 0.3a that is slightly different than http://www.picaxe-shop.de/URF-Module-ohne-Gehaeuse

If the two test points in the back of the stick (or in the front in V 0.3)near of the chip are P1 and P2 Could you point me where is RST and Power ? The stick has 1 RST pin hole and 2 PWR pin holes

Also, Did you put together Target Voltage Sense and 3.3v connected to PWR ?

Thank you !

[gusgorman402]

@maximevince Try these CC1101 examples. If you use a 5V Arduino, be sure to use logic level converter to 3.3V CC1101 module https://www.sparkfun.com/products/12009 https://github.com/LSatan/SmartRC-CC1101-Driver-Lib https://github.com/gusgorman402/rfmoggy https://www.hackster.io/jsmsolns/arduino-toyota-uk-tpms-tyre-pressure-display-b6e544

[atlas0fd00m]

/me facepalm: @maximevince wow, i asked if i could help and now i see how i dropped the ball. did you ever get there? if you need help, hit me again and i promise i'll try to get back to you better!

[maximevince]

@atlas0fd00m no worries! I had a basic version working using RPi + CC1101. However, quite some internal registers are different, and I did not pursue it further. I should probably at least just push wherever I left off to my github account. Since I was working a lot with ST's Spirit-1 and S2-LP chips, too, I moved my embedded development there.

But an rfcat-like tool for any kind of cheap sub-ghz chipset would still be really nice, of course.

Not sure when I'll pick the side-project up again. I'll be sure to let you know!

[atlas0fd00m]

thanks, @maximevince . i agree! travis goodspeed and i started working on a "sdrcat" project years ago, trying to simplify the SDR experience, but alas bitrot and lack of time kept it from becoming a real thing.

i'm always open to new hardware for the RfCat interface. currently RfCat works with CC1111 and CC2511 chips (for 2.4GHz). i've got code started to support CC2341 (15.4 chip), but i ran out of time. these all use the same processor (a 8051-based ChipCon chip), radio, and USB interface.

the RfCat USB interface is pretty simple (at least at the core requirements), and i'm happy to support/guide anyone who wants to write RfCat firmware for a different piece of hardware. if the radio is the same, we can use some of the existing python/firmware interface code. if not, we can still use the RfCat simplicity and wrap it into the RfCat family.

let me know if you'd be interested in implementing a new member of the RfCat family!

[joelsernamoreno]

Hello!

There is a project similar to rfcat, it may not be as powerful, but this works well with CC1101 modules:

https://github.com/rfquack/RFQuack

Recently we developed a device (Evil Crow RF), it has an ESP32-PICO module for WiFi and two CC1101 radio modules.

I tested with rfquack and it works!

The device will go on sale after the Chinese New Year (I am Spanish, but the manufacturing is in China). The device is low-cost and will cost around 20$ - 30$. It would be interesting to implement rfcat on it

I attach a picture so you can see the Evil Crow RF device: