search

riverloopsec / killerbee

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

Different Dumps: Api-Mote VS. RZUSBstick #98

Closed Krostas closed 3 years ago

Krostas commented 7 years ago

Hi all,

I'm trying to dump some packet to understand the behavior of some electrical plugs. I've been working with Api-Mote most of the time and after I even found the Transport Key using it.

I found strange that after using the Key I keep catching some IEEE802.15.4 encrypted packets with BAD FCS. screenshot_5

After some hours of searching and despair I decided to try it with my «old» RZUSBstick and the result is the expected. screenshot_6

Anyone knows why this happens? Any solution for this?

Note: I gave up of RZ because it just grabs a bunch of packets with zbdump/zbwireshark and then freezes. (If someone found the solution for this, please let know)

Thanks for all help!

rmspeers commented 7 years ago

For ApiMote, I assume that the bad FCS is present regardless of if you use the key or not. Using the key in wireshark should not effect that -- if it does, let me know as that is an important clue to where the issue is.

If not, what do the FCSs captured vs expected look like? Is there other corruption in the packets or is there something wrong with the 2 bytes of FCS themselves?

For RZUSBSTICK, try updating to the new firmware that should fix an issue in the original Atmel firmware.

Krostas commented 7 years ago

I would say that the problem is not the bad FCS but not «translating» to right layer. With Api-Mote I just get ZigBee (Link Status) packets and IEEE802.15.4 data packets (encrypted). I believe that the 802.15.4 Data packets (caught with Api-Mote) on the first picture should be the ZigBee HA packets of the second picture (caught with RZ)

It seems that the RZ handles the packets differently.

The key doesn't affect the bad FCS at all!

rmspeers commented 7 years ago

The packet parsing happens on the software side in the same code.

What is likely happening is that you are getting data corruption in the ApiMote's captures, which leads to wireshark not decoding properly.

This usually happens if you have extremely fast packets coming in and it's buffer gets jammed up on the micro-controller. I suggest looking at the body of the captured packets and trying to see where the raw bytes go wrong, which is then likely what is causing the parsing in wireshark to look different.

If you have two PCAPs of the same sequence of packets, that makes it easiest to debug. If you want me to take a quick look, email them to me and I can flip through and see if I can figure out what the likely issue is. No promises.

Krostas commented 7 years ago

That makes sense!

I was checking my Api-Mote version and it is still the V2. Could this be the problem?

To upgrade it should I use this manual and GoodFET? https://github.com/riverloopsec/apimote/blob/master/docs/apimote_overview_v4beta.pdf I assume chapter 4.3!

Krostas commented 7 years ago

And how can I check which version has the RZUSBstick installed?

Dev | Product String | Serial Number 3:7 | KILLERB001 | F...F

Is this the first version?

Ryan, thanks for your time!

rmspeers commented 7 years ago

I suggest updating your RZUSB to the latest firmware version in the repo, which is 003. I think you are on an older one based on that output, although I do need to check that the new firmwares are showing the updated version number correctly.

What is the version printed on your apimote? It is likely the v4beta. That has updated firmware, even though it enumerates as v2, as every ApiMote after v2 is firmware-compatible (only v1 was different). The issue is likely with it keeping up with the capture, but I can't really tell from the info I have.

Krostas commented 7 years ago

When I installed I am sure that there were only two versions. So it's deffinetly old. Is this the repo? https://github.com/riverloopsec/killerbee/tree/master/firmware There is no 3rd version in it.

It says V2. I bought it in the end of last year!

It will be usefull to you to have some kind of logs to improve something on your side?

Scytmo commented 7 years ago

@Krostas wrote:

Note: I gave up of RZ because it just grabs a bunch of packets with zbdump/zbwireshark and then freezes. (If someone found the solution for this, please let know)

Take a look at issue #86 regarding the RZ USB Stick capture stalling. There is a firmware hex file I posted on that thread, which may be what @rmspeers is referring to as working towards status as official 003 RZ firmware(?). Either way, your feedback on whether or not that fixes the stalling problem would be useful.

Krostas commented 7 years ago

@Scytmo, thanks.

I'll try to upgrade it tonight and I will tell something ASAP.

Krostas commented 7 years ago

@Scytmo the firmware is working as never before! 600 packets at this precise moment... Never done this with the RZUSBstick. Zbid, zbstumbler, zbdump and zbwireshark working perfectly.

@rmspeers, do you want some logs from the Api-Mote to check it for some improvements?

Thanks for all the help!!!

Krostas commented 7 years ago

+9000 packtes... I would say that it's perfect!

Scytmo commented 7 years ago

@Krostas wrote:

+9000 packtes... I would say that it's perfect!

Glad to hear it. Thanks for the confirmation!

RosenZhu commented 7 years ago

@Scytmo I just bought a RZ USB stick a few days before but I cannot flash it with the new firmware, because I don't know how to connect the stick to the bus pirate. The connection from the README is: GND to GND (RZ Raven USB stick to buspirate), TCK to CLK, TDO to MISO, TMS to CS, TDI to MOSI and SRST to AUX. But I cannot find the GND,TCK... on the RZ USB. The RZ USB I bought looks like: http://media.digikey.com/photos/Atmel%20Photos/ATAVRRZUSBSTICK.JPG

So, how can I connect the RZ to bus pirate or any other way to reflash RZ? Thanks.

Scytmo commented 7 years ago

Personally, I use an AVR Dragon to reflash the RZUSB Stick. The AVR Dragon has a 10-pin connector with a pin-out documented here (you just need a 50-mil to 100-mil adapter): http://www.atmel.com/webdoc/avrdragon/avrdragon.using_ocd_physical_jtag.html I believe this is a standard layout. It's also common to the JTAGICE3: http://www.atmel.com/webdoc/jtagice3/jtagice3.using_ocd_physical_jtag.html

rmspeers commented 7 years ago

In the writeup for this, step #4 includes what the submitter logs as the proper connections (see https://github.com/riverloopsec/killerbee/blob/master/firmware/README.md under Buspirate).

RosenZhu commented 7 years ago

Thanks for your reply.

rmspeers commented 6 years ago

Can anyone please confirm that this is all set now and can be closed?