riverloopsec / killerbee

IEEE 802.15.4/ZigBee Security Research Toolkit
http://www.riverloopsecurity.com
Other
761 stars 215 forks source link

Why is jamming unimplemented for the RZRaven USB stick? #69

Closed SpencerMichaels closed 3 years ago

SpencerMichaels commented 8 years ago

I am trying to implement a jammer using Killerbee on an RZRaven USB. In dev_rzusbstick.py, jammer_on() and jammer_off() are marked as unimplemented. However, in the firmware (air_capture.c), it appears that everything necessary for jamming — as detailed in the AT86RF230 datasheet section on PBRS mode continuous transmission — is implemented there in C. I have manually implemented the necessary parts of the Python code to run those C functions, but (as can be seen through Wireshark) only a single packet is sent, rather than what I assume should be a continuous stream. Is there some additional coding that needs to be done, and that's why the jamming functions are still considered unimplemented? It seems like everything that needs to be implemented is there.

joswr1ght commented 8 years ago

The jammer_on() and off() functions were part of the sample firmware from Atmel, and when I tested them I saw similar results to what you report. I never investigated it further. If you have an AVR Dragon or mkII ICE JTAG debugger, it might be interesting to see what happens in the firmware, and if it can be corrected to update the firmware with jammer functionality.

-Josh

SpencerMichaels commented 8 years ago

I do have an AVR Dragon, but I doubt I have the skill to investigate this in too much depth... I did, however, find that in the data sheet, there's a section (Appendix, A.3) that says

The functionality of the Continuous Transmit Mode is not characterized by Atmel and therefore not guaranteed.

I take this to mean "continuous transmit mode just might not work"..?

Meanwhile, I suppose there is not any other way to get an RZRaven to transmit and ignore CSMA/CA?

rmspeers commented 8 years ago

We generally use other firmware/hardware for jamming, so I’ve never looked at changing it in the Atmel. Other chips like the CC2420 have a flag to disable CSMA/CA, as well as to place it into “test mode” which generally allows jamming transmissions.

On Jun 24, 2016, at 4:47 PM, Spencer Michaels notifications@github.com wrote:

I do have an AVR Dragon, but I doubt I have the skill to investigate this in too much depth... I did, however, find that in the data sheet, there's a section that says

The functionality of the Continuous Transmit Mode is not characterized by Atmel and therefore not guaranteed. I take this to mean "continuous transmit mode just might not work"..?

Meanwhile, I suppose there is not any other way to get an RZRaven to transmit and ignore CSMA/CA?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/riverloopsec/killerbee/issues/69#issuecomment-228457924, or mute the thread https://github.com/notifications/unsubscribe/AJbQCWTjS26OJN9mC1OICaguqcn3mZANks5qPEJdgaJpZM4I-Dtl.

arunmagesh commented 7 years ago

Any pointers in how to implement jammer on rzusb?

SpencerMichaels commented 7 years ago

According to my research at the time, jamming is impossible on the RZUSB, at least by default, because there's no way to disable CSMA/CA, meaning it always waits for a clear channel before sending (see my previous post just above). However, I did not do much investigation on whether or not it's possible to correct the firmware to enable a proper continuous transmit mode. Regardless, Atmel's datasheet seems to suggest that for hardware reasons this may not be possible.

riverloopsec commented 7 years ago

My suggestion here would be to look at the chip, and figure out how to put it into test mode. Most RF chips have a test mode that is required for use during FCC certification. When used, this can also make a jammer, of course that is not the intent, nor is it supposed to be used outside of a test lab. Remember to implement and use legally. Anyways, having said all of that, I think you will have the best success by changing the firmware to allow it to go into this mode in order to do your jamming. I have not looked at the data sheet however, and Spencer may have already found this to not be there for some reason on that chip. On Thu, Feb 9, 2017 at 12:22 AM Spencer Michaels notifications@github.com wrote:

According to my research at the time, jamming is impossible on the RZUSB, at least by default, because there's no way to disable CSMA/CA, meaning it always waits for a clear channel before sending (see my previous post just above). However, I did not do much investigation on whether or not it's possible to correct the firmware to enable a proper continuous transmit mode. Regardless, Atmel's datasheet seems to suggest that for hardware reasons this may not be possible.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/riverloopsec/killerbee/issues/69#issuecomment-278550388, or mute the thread https://github.com/notifications/unsubscribe-auth/AGo9gy2W0K11ana9TdF-4HKjO3kdCBz1ks5raqKqgaJpZM4I-Dtl .

rmspeers commented 6 years ago

@arunmagesh , @sxmichaels , etc - see the new firmware 004 being merged shortly and try that. Please inform if that resolves.

taylorcenters commented 3 years ago

closed - long idle