search

riverloopsec / killerbee

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

Apimote very unstable and doesn't sniff packets correctly #190

Closed Faeris95 closed 3 years ago

Faeris95 commented 5 years ago

Hello,

I have some issues with the ApiMote v4 beta. Sniffed packets are malformed (bad FCS) which I have not with an other sniffer and tool, it prints also many "#DEBUG Clearing overflow" lines in terminal.

I tried to reflash the firmware (with and without the --speed argument because it failed at first) and it gets even worst as the card recognition failed 3 times out 4: "See the GoodFET FAQ about missing info flash."

We test the sniffer and reflash it under several environments with same results : Fedora 30, Ubuntu 19.04, Ubuntu12.04 (in VM, as someone has suggested to try in an other thread) and Parrot OS (debian based).

Best regards

rmspeers commented 5 years ago

This doesn't seem like an issue that reflashing the same FW will fix. This we believe typically occurs when the laptop/computer is not running data quickly enough, so the packets back up on the ApiMote's internal memory, and it drops them. If you can't read faster, I'd suggest looking at updating the ApiMote firmware (GoodFET project ccspi.c file) to allocate a larger or more efficient ring buffer and read.

Faeris95 commented 5 years ago

I've just tried it on a Macbook with same result as the others laptops. I also tried to recompile the firmware from the GoodFET project and flash it as you recommend, however without modification, and killerbee crashed :

# DEBUG Clearing overflow issue in peeking for a register string index out of range Traceback (most recent call last): File /usr/bin/zbstumbler, line 4, in import('pkg_resources').run_script('killerbee==2.7.1', 'zbstumbler') File /usr/lib/python2.7/site-packages/pkg_resources/init.py, line 666, in run_script self.require(requires)[0].run_script(script_name, ns) File /usr/lib/python2.7/site-packages/pkg_resources/init.py, line 1453, in run_script exec(script_code, namespace, namespace) File /usr/lib64/python2.7/site-packages/killerbee-2.7.1-py2.7-linux-x86_64.egg/EGG-INFO/scripts/zbstumbler, line 199, in

File build/bdist.linux-x86_64/egg/killerbee/init.py, line 358, in pnext File build/bdist.linux-x86_64/egg/killerbee/dev_apimote.py, line 195, in pnext File build/bdist.linux-x86_64/egg/killerbee/GoodFETCCSPI.py, line 183, in RF_getrssi File build/bdist.linux-x86_64/egg/killerbee/GoodFETCCSPI.py, line 84, in peek IndexError: string index out of range

rmspeers commented 5 years ago

I didn't mean just recompile it, I meant that you would likely need to modify the code in the firmware to get it working first.

The crash issue I presume is different and due to a USB difference in macOS vs Linux? Have you debugged where that comes from?

rmspeers commented 4 years ago

Any updates here?

elbrini commented 4 years ago

Hello, I have the same issue here! Any suggestions?

washcroft commented 4 years ago

Same issue here, I believe there are issues in the ApiMote firmware that nobody knows how to fix or has the time to investigate - definitely not a speed/environment issue causing these Bad FCS packets.

I switched over to a CC2531 dongle (everything else the same) and instantly everything started working correctly, every packet fully intact, unfortunately this hardware only supports sniffing.

Pretty sad after stumping up for the "pro" ApiMote hardware that it simply doesn't work.

rmspeers commented 4 years ago

Correct, there are known stability issues as mentioned in the email sent to anyone who orders an ApiMote from RLS, it is beta due to the instability reasons, and thus why RLS offers it at cost of assembly. Also of note, you typically would want an ApiMote if you're doing low-level attacks (PIP, etc) on the PHY/MAC layers or things like reflexive jamming - but general IEEE 802.15.4/ZigBee attacks don't need that level of control.

@washcroft is correct that no one on the team currently has time to investigate the issues - they may be in firmware or in the FTDI chip configuration I'd note.

CC2531s are a great option for many users - and I encourage anyone interested to contribute injection support firmware for it!

inode- commented 4 years ago

Workaround at: https://github.com/riverloopsec/killerbee/issues/215#issuecomment-729582886

washcroft commented 4 years ago

Workaround at: #215 (comment)

I don't see how that fixes the issue discussed here? The issue here is once you have ApiMote detected and running packet capture, most of the captured packets are actually garbage.

inode- commented 4 years ago

Workaround at: #215 (comment)

I don't see how that fixes the issue discussed here? The issue here is once you have ApiMote detected and running packet capture, most of the captured packets are actually garbage.

It fix the:

I tried to reflash the firmware (with and without the --speed argument because it failed at first) and it gets even worst as the card recognition failed 3 times out 4: "See the GoodFET FAQ about missing info flash."

I will execute some better test in the next days and I will let you know.

rmspeers commented 4 years ago

Packet corruption coming in @washcroft is likely due to it not keeping up with incoming packets fast enough, and thus having buffer overruns in the CC2420. I've suggested to people before that in these situations, if you do need to use the ApiMote v4beta, then a change to:

inode- commented 4 years ago

Ok, I found the problem, but I didn't know how to fix it...

@rmspeers the problem is not related to buffer overruns or python code

The problem is the packet generated from apimote contains two different packets, the data + the ack.

Here an example. This image is the data dumped with apimote.

zigbee_data_apimote

Here same packet dumped with a CC2531.

zigbee_data_cc22_packet1

zigbee_data_cc22_packet2

I highlighted the same data transferred (without the CRC) and as you can see it's corrected. The rest of the data shown in the CC2531 are some added data by the sniffer.

All packet without an ack (for example the link status packets) are parsed correctly.

The same data can be also be viewed using the GoodFET tools with:

goodfet/client$ sudo ./goodfet.ccspi sniff 11

Any idea?

federicodotta commented 4 years ago

I have the same identical issue. The apimote collapse packets and ACKs. I tried with different XBee and Zigbee and on different operating systems. With the CC2531 I correctly sniff packets and ACKs, with the ApiMote I sniff wrong big packets, each of them composed by a packet plus a ACK. I didn't find a solution on this problem. :(

Any idea?

inode- commented 4 years ago

@washcroft I just created a pull request to manage the problem. If you can execute some test and tell me if it work in your situation will be useful.

inode- commented 4 years ago

@rmspeers I think that I found the problem. It can be related to: https://github.com/travisgoodspeed/goodfet/blob/30a7e7673f88c741bcfaf57846b8018e0ec21d30/firmware/apps/radios/ccspi.c#L170

I need to go deeper but I tried to compile the GoodFET from the Travis repository, but it seem not compatible with apiMote hardware. Using killerbee firmware it's possible to sniff with the command line:

inode@ubuntu:~/goodfet/client$ sudo ./goodfet.ccspi sniff 11

Using the same command with the Travis firmware I get nothing, so I suppose that you changed something in the firmware to get it compatible with apiMote hardware (maybe some pins or similar).

Can you share the source code from which you created the "apimotev4_gf.hex" file?

inode- commented 4 years ago

@washcroft a modified pull request has been sent with the new version of GoodFET which should resolve the problem of Bad FCS (caused by ACK concatenation). A new firmware is avaiable with name "apimotev4_202011.hex" and I updated also the client library.

@rmspeers the latest goodfet wasn't working with apimote because an error https://github.com/travisgoodspeed/goodfet/pull/51 I resolved the problem and now everything work correctly also the ACK. I also changed the "attemptlimit" to get the sync correctly in every system. The workaround of "./goodfet.monitor listapps full" should not be necessary anymore.

rmspeers commented 4 years ago

@taylorcenters or I will take a look at the FW after discussing the update with @travisgoodspeed to get his thoughts. Really appreciate the update to it and interested to hear @washcroft if it helps for you as well.

taylorcenters commented 3 years ago

Hi, we believe that the apimote instability issues have been fixed with the latest PRs. Please try the latest software and reopen the issue if this is still a problem. Thanks