Porting nRF24L* about rfcat HOT 5 CLOSED

that would be awesome! please do! i continually fret about the cc2511 being baud-limited, when the nRF24 chips go up to 2mbps. do you have a usb dongle in mind?

• implementing the RfCat command and control on the chip would be the first step. make rflib understand how to talk to a specific nRF dongle (typically, pyusb talking to the chip).
• once you have the dongle enumerating in the OS, add peek/poke functionality
• from there, decide where it makes sense to do configuration/calculations. currently much of the RfCat functionality is implemented on the Python-side for ease and resources. anything that requires fast turn-around, however, gets placed in the firmware.

let me know what you think.

@

from rfcat.

The CrazyRadio PA USB dongle is great for using that custom firmware, and the mouse and keyboard attack tools that accompany it.
As far as implementing command and control, is the chipcon_usb.py code the python interface to the chipcon_usb.c firmware running on the dongle?
Assuming the nrf_research_firmware is already handling all of the necessary reads/writes to registers on the chip, and SPI and USB stuff; is this about the the place to start mapping those to the existing work in rfcat?

from rfcat.

basically, yes. that makes sense.

ping/poke/peek are the primary functionality. after that, we'll want the nRF to respond to the getBuildInfo() functions, partly so RfCat client code can identify what type of dongle we're using.

from rfcat.

Do you have anything representing the program flow (pseudo-code, flow-chart, bar-napkin)?

from rfcat.

just the code, my friend. it's pretty simple, but probably doesn't look like it.
i've broken the firmware code into layers. the ISR's, main(), and different handlers/buffers/flags which tell the firmware what to do and with what data.

the python side just talks to the handlers on the firmware end. send in a app/verb combo with the correct data. very extensible. responses get placed in a message queue (python list) and then handled by a "mailman" which places messages into the proper message queue (based on response app/verb). bi-directional functions will send in a message, then wait for a response by waiting for a message to show up in the correct message list. if the firmware wants to send a message to be handled by the RfCat python code, it will address the SYSTEM app. for instance, this helps make debugging messages appear when they occur, not waiting for a user to check for them.

from rfcat.