zbscapy calls 'ext_source' and scapy-com calls 'ext_src'

[GoogleCodeExporter]

What steps will reproduce the problem?

0. Install killerbee and scapy-com (used by other tools)
1. Capture encrypted zigbee communications.
2. Display a packet. (the following is modified slightly) Notice that the 
reference for 'ext_src' is used because of scapy-com installation.

>>> p
<Dot15d4FCS  fcf_reserved_1=0 fcf_panidcompress=True fcf_ackreq=False 
fcf_pending=False fcf_security=False fcf_frametype=Data fcf_srcaddrmode=Short 
fcf_framever=0 fcf_destaddrmode=Short fcf_reserved_2=0 seqnum=162 |<Dot15d4Data 
 dest_panid=0x092d dest_addr=0xffff src_addr=0x0 |<ZigbeeNWK  discover_route=0 
proto_version=2 frametype=command flags=security+extended_src 
destination=0xfffc source=0x00 radius=1 seqnum=97 ext_src=xx:xx:xx:xx:xx:xx 
|<ZigbeeSecurityHeader  reserved1= extended_nonce=1 key_type=network_key 
nwk_seclevel=None fc=0x015186 source=xx:xx:xx:xx:xx:xx key_seqnum=95 
data='\x65\x32\xa8\xea\xec\xc0' |>>>>

3. Process the packets and search the packet for 'ext_source' using 
packet.getfield_and_val('ext_source').

>>> cap = PcapReader('join_ch15.pcap')
>>> while 1:
...    try:
...       p = cap.next()
...    except:
...       print "done"
...       break
...    try:
...       p.getfield_and_val('ext_source')
...    except:
...       print str(cnt) + ' ext_source error'
...    cnt += 1
... 
0 ext_source error
1 ext_source error
WARNING: FCS on this packet is invalid or is not present in provided bytes.
2 ext_source error
WARNING: FCS on this packet is invalid or is not present in provided bytes.
3 ext_source error
WARNING: more FCS on this packet is invalid or is not present in provided bytes.
4 ext_source error
5 ext_source error
6 ext_source error

3. Find where 'ext_source' is called in scapy_extensions.py code. Replace 
'ext_source' with 'ext_src' as shown in packet display and within 

Line 421: #nonce = struct.pack('L',f['ext_source'])+struct.pack('I',f['fc']) + 
sec_ctrl_byte
Line 422: nonce = struct.pack('L',f['ext_src'])+struct.pack('I',f['fc']) + 
sec_ctrl_byte

4. Run again but modify 'ext_source' to 'ext_src'.

>>> cap = PcapReader('join_ch15.pcap')
>>> while 1:
...    try:
...       p = cap.next()
...    except:
...       print "done"
...       break
...    try:
...       p.getfield_and_val('ext_src')
...    except:
...       print str(cnt) + 'ext_src error'
...    cnt += 1
... 
(<Field (ZigbeeNWK).ext_src>, xxxxxxxxxxxxxxxx)
(<Field (ZigbeeNWK).ext_src>, xxxxxxxxxxxxxxxx)
WARNING: FCS on this packet is invalid or is not present in provided bytes.
(<Field (ZigbeeNWK).ext_src>, 0)
WARNING: FCS on this packet is invalid or is not present in provided bytes.
(<Field (ZigbeeNWK).ext_src>, 0)
WARNING: more FCS on this packet is invalid or is not present in provided bytes.
(<Field (ZigbeeNWK).ext_src>, 0)
(<Field (ZigbeeNWK).ext_src>, 0)

What is the expected output? What do you see instead?

Not sure if the update should be performed here or in scapy-com code.

https://bitbucket.org/secdev/scapy-com

I figured I would start here.

What version of the product are you using?

Last Changed Rev: 92
Last Changed Date: 2014-07-01 09:30:21 -0500 (Tue, 01 Jul 2014)

On what operating system?

Linux kubuntu_rules 3.11.0-26-generic #45-Ubuntu SMP Tue Jul 15 04:02:06 UTC 
2014 x86_64 x86_64 x86_64 GNU/Linux

With what Python version? (python -V)

Python 2.7.5+ 

Is scapy-com installed?

Yes, yes it is.

Please provide any additional information below.

Original issue reported on code.google.com by cutaways...@gmail.com on 11 Sep 2014 at 7:25

[GoogleCodeExporter]

Have made the suggested change in scapy_extensions revision 93. Please retest 
and confirm fixed :)

Original comment by rmspe...@gmail.com on 14 Sep 2014 at 5:33

[GoogleCodeExporter]

I applied the updated and even installed on a different system (without 
scapy-com).  I'm not sure what this broke. I don't recall this happening when I 
tested it before. Here is what I'm seeing. 

First, I captured a file on the system that has a default version of scapy 
using zbdump. Then I tried parsing the file using the updated version of 
zbscapy.

System with the normal scapy installation (via apt-get) does not parse 
generated pcap properly.

=========================================
cutaway@sys_w_orig_scapy:~$ zbscapy 
WARNING: Most KillerBee functionality requires root privileges.
Welcome to Scapy (2.2.0)
KillerBee Extension v0.6
>>> cnt = 0 
>>> cap = PcapReader('/tmp/zb_test.pcap')                                       

WARNING: PcapReader: unknown LL type [195]/[0xc3]. Using Raw packets
=========================================

System with scapy-com installation does parse pcap file properly.

=========================================
cutaway@sys_w_scapy-com> zbscapy 
WARNING: Most KillerBee functionality requires root privileges.
Welcome to Scapy (2.2.0-dev)
KillerBee Extension v0.6
>>> cap = PcapReader('/tmp/zb_test.pcap')
>>> 
=========================================

Any ideas?

cutaway

Original comment by cutaways...@gmail.com on 15 Sep 2014 at 3:31

[GoogleCodeExporter]

Hmm. I could believe that the normal scapy (not scapy-com) doesn't recognize 
the 802.15.4 link-layer type and that's why it fails. It looks like scapy-com 
works now, using the update you suggested (can you verify in that I patched 
what you thought should be the change?). Is this last comment saying that 
something else changed now that you've updated? I'd expect that the normal 
scapy installation never parsed the packets correctly...? If not, I'll look 
into it but I'm surprised. If that is the case (that the normal scapy never 
parsed 802.15.4 PCAP correctly), what broke in this KillerBee version?

Original comment by rmspe...@gmail.com on 16 Sep 2014 at 1:00

• Changed state: Accepted

[GoogleCodeExporter]

I'm obviously using zbscapy incorrectly. I'm trying to figure it out so I can 
test it properly. Personal email sent. I'll post my update when I figure out 
how to implement zbscapy properly.

cutaway

Original comment by cutaways...@gmail.com on 16 Sep 2014 at 7:32

[GoogleCodeExporter]

I believe this is working properly and can be closed. The other things I'm 
seeing are not related to this issue.

cutaway

Original comment by cutaways...@gmail.com on 16 Sep 2014 at 9:31

[GoogleCodeExporter]

Actually, and I apologize, I believe I referred to the wrong field in my 
original recommendation. I made that without fully understanding what kbdecrypt 
was doing. My current testing shows that 'ext_src' should actually be 'source'.

For example:
======================================
Out[36]: <Dot15d4FCS  fcf_reserved_1=0 fcf_panidcompress=True fcf_ackreq=False 
fcf_pending=False fcf_security=False fcf_frametype=Data fcf_srcaddrmode=Short 
fcf_framever=0 fcf_destaddrmode=Short fcf_reserved_2=0 seqnum=121 |<Dot15d4Data 
 dest_panid=0x0a36 dest_addr=0xffff src_addr=0x0 |<ZigbeeNWK  discover_route=0 
proto_version=2 frametype=command flags=security+extended_src 
destination=0xfffc source=0x00 radius=1 seqnum=110 ext_src=xx:xx:xx:xx:xx:xx 
|<ZigbeeSecurityHeader  reserved1= extended_nonce=1 key_type=network_key 
nwk_seclevel=ENC-MIC-32 fc=0xc073 source=xx:xx:xx:xx:xx:xx key_seqnum=43 
data='\x83sF\x3fe\t\x95W\x17' |>>>>
======================================

Note that this packet has the field ZigbeeSecurityHeader.source. I assumed, 
incorrectly, that the 'ext_src' field in the ZigbeeNWK layer was what 
'ext_source' was referring to.

So, a fix was still required. It just needs to be updated again. My current 
testing shows that by making this modification the kbdecrypt function runs 
without error.

Thank you,
cutaway

Original comment by cutaways...@gmail.com on 16 Sep 2014 at 11:46

[GoogleCodeExporter]

Commit #94 has updated per your request. See if that works.

Original comment by rmspe...@gmail.com on 28 Sep 2014 at 8:47

• Changed state: Fixed