Serdar Metin | 21 Oct 09:48 2014
Picon

RE: Fwd: DNS SRV Response fields

As far as I know, DNS for ipv6 is changed compared with DNS for ipv4. Have a look at that.

 

Van: Marco Zunino [mailto:eng.marco.zunino <at> gmail.com]
Verzonden: Tuesday, October 21, 2014 7:43 AM
Aan: scapy.ml
Onderwerp: [scapy.ml] Fwd: DNS SRV Response fields

 

Good evening everyone, first of all thank you for supporting such a nice project.

We were playing around with DNS request and we faced one problem trying to forge a specific DNS SRV Response

(see for example frame #2 of this traces https://www.cloudshark.org/captures/395cd6b88c2e).

The Answers section of this response contains several 'fields':

 

    Answers

        _kerberos._udp.SAMBA.EXAMPLE.COM: type SRV, class IN, priority 0, weight 100, port 88, target localdc.samba.example.com

        Service: _kerberos

        Protocol: _udp

        Name: SAMBA.EXAMPLE.COM

        Type: SRV (Server Selection) (33)

        Class: IN (0x0001)

        Time to live: 900

        Data length: 33

        Priority: 0

        Weight: 100

        Port: 88

        Target: localdc.samba.example.com

 

We created a DNS() packet and assigned to the answer section a DNSRR(), but the available fields for this 

object are only:

 

    >>> DNSRR().show()

    ###[ DNS Resource Record ]###

      rrname= ''

      type= A

      rclass= IN

      ttl= 0

      rdlen= 0

      rdata= ''

 

Are we using the wrong object to populate the answer section? Do you have any suggestion on what would be the best way to create from scratch a packet as #2? 

 

Thank you for your time

 

Marco Zunino | 21 Oct 07:43 2014
Picon

Fwd: DNS SRV Response fields

Good evening everyone, first of all thank you for supporting such a nice project.
We were playing around with DNS request and we faced one problem trying to forge a specific DNS SRV Response
(see for example frame #2 of this traces https://www.cloudshark.org/captures/395cd6b88c2e).
The Answers section of this response contains several 'fields':

    Answers
        _kerberos._udp.SAMBA.EXAMPLE.COM: type SRV, class IN, priority 0, weight 100, port 88, target localdc.samba.example.com
        Service: _kerberos
        Protocol: _udp
        Name: SAMBA.EXAMPLE.COM
        Type: SRV (Server Selection) (33)
        Class: IN (0x0001)
        Time to live: 900
        Data length: 33
        Priority: 0
        Weight: 100
        Port: 88
        Target: localdc.samba.example.com

We created a DNS() packet and assigned to the answer section a DNSRR(), but the available fields for this 
object are only:

    >>> DNSRR().show()
    ###[ DNS Resource Record ]###
      rrname= ''
      type= A
      rclass= IN
      ttl= 0
      rdlen= 0
      rdata= ''

Are we using the wrong object to populate the answer section? Do you have any suggestion on what would be the best way to create from scratch a packet as #2? 

Thank you for your time

Tomino | 11 Oct 18:47 2014
Picon

how to use sniff() to get only inbound


Hello,
I need to code sowftware switch, but I have a problem. When I send a packed
to specific interface, sniffing thread at that port will recieve it as
inbound packed, but that is wrong. It is possible to set sniff() to read
only inbound packets? Here is my code. 

import threading
from scapy.all import *
port1 = "veth1000.0"
port2 = "veth1001.0"
def output(x, interface):
  sendp(x, iface = interface)

def thr1():
  sniff(iface = port1, prn = lambda x : output(x, port2))
def thr2():
  sniff(iface = port2, prn = lambda x : output(x, port1))

t1 = threading.Thread(target = thr1 )
t2 = threading.Thread(target = thr2 )
t1.start()
t2.start()

---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org

Sushant Hiray | 28 Sep 23:16 2014
Picon

Problems in converting SIP object to string

Hi all,

I'm attaching a small tcpdump pcap file. I'm sending a SIP REGISTER request from a client and trying to parse it with scapy.

Here is what I've done till now.

>>> pkts = rdpcap('one.pcap')
>>> type(pkts[0][3])
<class 'sip.SIP'>
>>> str(pkts[0][3])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/scapy/packet.py", line 261, in __str__
    return self.build()
  File "/usr/local/lib/python2.7/dist-packages/scapy/packet.py", line 319, in build
    p = self.do_build()
  File "/usr/local/lib/python2.7/dist-packages/scapy/packet.py", line 307, in do_build
    self = self.__iter__().next()
StopIteration

Can anyone suggest what the issue might be? Since I'm not able to convert it to string, I'm not able to parse the internal fields such as username.
Or is there any better way to do the same?

Thanks,
Sushant Hiray,
Senior Undergrad CSE,
IIT Bombay


Attachment (one.pcap): application/octet-stream, 3141 bytes
---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org
Beede, Michael P | 18 Jul 21:38 2014
Picon

A more focused question about protocol descriptions


I'm still working on adding MPTCP to Scapy and think I have a decent approach.  However, there is a fundamental thing I think I don't understand about ConditionalField. 

Suppose we have a very simple protocol that has one kind of packet.  A FOO packet has 2 bytes of data and an optional two bytes of address, only present if it's a 4-byte packet.  So, it's pretty easy to define:

class FOO(Packet):
    fields_desc = [ ShortField("data",0),
                            ConditionalField(ShortField("addr",None),lambda p:p.addr != None) ]

Now you can specify a packet of either type easily:

>>> a = FOO(data=1234)
>>> b = FOO(data=5678,addr=6666)
>>> a
<FOO  data=1234 |>
>>> b
<FOO  data=5678 addr=6666 |>

But what happens if we dissect the second packet?

>>> c = FOO(str(b))
>>> c
<FOO  data=5678 |<Raw  load='\x1a\n' |>>

Of course, this is just what we described, but i can't figure out how to improve the predicate so it works for a literal packet and for dissection too. We can't refer to the length of the packet, because it hasn't been constructed yet.  So, how do we correctly deal with this simple protocol?  I've come to the conclusion that there must be some simple principle I'm missing entirely.

Thanks for any suggestions.

   Mike Beede

Beede, Michael P | 15 Jul 00:35 2014
Picon

multipath TCP support


I've been thinking of adding MPTCP support to scapy, but I am at a stand as to what it should look like.  I hope to solicit some opinions as to the the scapy-ful way to approach this.

For those that aren't familiar with it, MPTCP is an extension to  TCP with all the "multi-path aware" information carried in TCP option fields.  The problem is that there are a number of different subtypes for the MPTCP option, each with (mostly) different fields.  This would make it awkward to specify a packet, since you'd have to cram things into the option list, and it would make it especially awkward to refer to in code, since (unless I misunderstand things), there's no short way to refer to a specific option field.

Another goal: in order to investigate ill-formed packets, it should be possible to specify packets that have multiple MPTCP options, even ones that the standard doesn't envision occurring together.

To be clear, it would be nice to be able to create a MPTCP packet by saying something like

w = IP(dst="google.com")/TCP(MP_CAPABLE(SenderKey=0x1122334455667788L))

and later refer to the key as

w[TCP].MP_CAPABLE.SenderKey

Or in the ill-formed case say something like

w = IP()/TCP(MP_CAPABLE(SenderKey=0),MP_CAPABLE(SenderKey=0))

Note: I have no idea how you'd distinguish two MP_CAPABLE options when referring to them in code.  Maybe as an array?

It's straightforward to define the various options as Packets (in fact, it's much easier than writing code to parse the options, since parsing packets is  well thought-out in scapy), but it isn't clear to me whether modifying TCP to accept packets as arguments would be contrary to the spirit of things.  I also thought of implementing it as a layer, but that's a bit confusing since it's really contained entirely within the TCP layer.

If anyone has some suggestions for how they think it should look (or even better, how it should work!), I'd appreciate them.

Regards,

    Mike Beede




Harry Trieu | 3 Jul 00:56 2014

Sending IP Fragments Out of 2 Interfaces

Hi guys,

Suppose I have an IP packet that I fragment into 10 fragments using fragment(). Is there a way to send 5 of those fragments out of one interface (let’s say eth0) and the other half out of the other interface (eth1) using sendpfast()?

I think it can be done using sendp() but I’m not sure how it would work using sendpfast() as it spawns tcpreplay.

Any ideas?

Thanks,
Harry
David Imhoff | 27 Jun 10:47 2014
Picon
Picon

Red Hat EL7 RPM download link


Hi,

Are you aware that the link on http://pkgs.repoforge.org/scapy/ to the
Red Hat Enterprise Linux 7 RPM is broken?
It points to:
http://apt.sw.be/redhat/el7/en/i386/rpmforge/RPMS/scapy-2.0.0.10-1.el7.rf.noarch.rpm
but the actual package is on ('i386' vs 'x86_64'):
http://apt.sw.be/redhat/el7/en/x86_64/rpmforge/RPMS/scapy-2.0.0.10-1.el7.rf.noarch.rpm

Kind regards,

David

---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org

Jacek Wielemborek | 22 Jun 14:46 2014
Picon

How to spoof a TCP handshake in scapy?

Hello,

(This post is based on my StackOverflow question, which can be 
found here: http://stackoverflow.com/q/24340455/1091116)

I was recently trying to write a Scapy script that performs a 
full TCP handshake. The idea was that I connect two Qemu VMs 
using `-net socket` userspace interface (which seems to handle 
raw IP/ethernet fine) and instruct machine B to block all input 
from A (to prevent it from sending the RSTs). Then, I used telnet 
to `connect()` from machine A to B and ran the following script 
on machine B:

    #!/usr/bin/python

    import scapy.all as scapy

    filter = "port 31337"
    iface = "eth0"

    def prepare_response(t):
        print("Received: %s" % repr(t))
        t.src, t.dst = t.dst, t.src  # swap ethernet addresses
        ip = t.getlayer("IP")
        ip.src, ip.dst = ip.dst, ip.src
        t.dport, t.sport = t.sport, t.dport
        t.ack = t.seq
        t.ack += 1

    syn = scapy.sniff(filter=filter, count=1, iface=iface)[0]
    print(syn.sprintf('%TCP.flags%'))

    syn_ack = syn
    prepare_response(syn_ack)
    syn_ack.getlayer("TCP").flags |= 0x10  # set the ACK flag
    print(syn_ack.sprintf('%TCP.flags%'))

    print("Sending: %s" % repr(syn_ack))
    scapy.sendp(syn_ack, iface=iface, verbose=False)

    ack = scapy.sniff(filter=filter, count=1, iface=iface)[0]
    assert(ack.flags & 0x10)

The problem is that instead of receiving an ACK from A to B, I 
seem to get a SYN retransmission as if SYN+ACK wasn't interpreted 
correctly:

(A Wireshark screenshot can be found here:  
https://imgur.com/kv7A3Hr )

tcp on machine A confirms that SYN+ACK reached the machine:

    05:47:03.925100 IP 10.0.0.1.39634 > debian.31337: Flags [S], 
seq 2426802888, win 14600, options [mss 
1460,nop,nop,sackOK,nop,wscale 4], length 0
    05:47:03.927515 IP debian.31337 > 10.0.0.1.39634: Flags [S.], 
seq 2426802888, ack 2426802889, win 14600, options [mss 
1460,nop,nop,sackOK,nop,wscale 4], length 0

Here's the PCAP file from machine B's perspective in Base64 form:

1MOyoQIABAAAAAAAAAAAAP//AAABAAAAYlilUwieDgARAQAAEQEAAAEAXgAA+1J
UABI0VggARQABA2UUQAD/ESrYCgAAAuAAAPsU6RTpAO/r/QAAAAAAAwAAAAUAAA
E2ATUBNAEzATIBMQFlAWYBZgFmATABMAE0ATUBMAE1ATABMAEwATABMAEwATABM
AEwATABMAEwATABOAFlAWYDaXA2BGFycGEAAP8AAQtkZWJpYW4tMTA5MwVsb2Nh
bAAA/wABATIBMAEwAjEwB2luLWFkZHLAUAD/AAHAWgANAAEAAAB4AAsESTY4NgV
MSU5VWMBaAAEAAQAAAHgABAoAAALAcQAMAAEAAAB4AALAWsBaABwAAQAAAHgAEP
6AAAAAAAAAUFQA//4SNFbADAAMAAEAAAB4AALAWmJYpVMJoA4AnAAAAJwAAAABA
F4AAPtSVAASNFYIAEUAAI4GlEAA/xGJzgoAAAHgAAD7FOkU6QB6hFgAAIQAAAAA
AQAAAAABNgE1ATQBMwEyATEBZQFmAWYBZgEwATABNAE1ATABNQEwATABMAEwATA
BMAEwATABMAEwATABMAEwATgBZQFmA2lwNgRhcnBhAAAMgAEAAAB4ABIKZGViaW
FuLTQwNwVsb2NhbABnWKVTvIYIAEIAAABCAAAAUlQAEjRWUlQAEjRWCABFAAA0H
dtAAEAGCOcKAAABCgAAAprbemmul/p8AAAAAIACOQhjsAAAAgQFtAEBBAIBAwME
Z1ilU5COCABCAAAAQgAAAFJUABI0VlJUABI0VggARQAANB3bQABABgjnCgAAAgo
AAAF6aZrbrpf6fK6X+n2AEjkIY7AAAAIEBbQBAQQCAQMDBGhYpVPTfggAQgAAAE
IAAABSVAASNFZSVAASNFYIAEUAADQd3EAAQAYI5goAAAEKAAACmtt6aa6X+nwAA
AAAgAI5CGOwAAACBAW0AQEEAgEDAwRqWKVTrI4IAEIAAABCAAAAUlQAEjRWUlQA
EjRWCABFAAA0Hd1AAEAGCOUKAAABCgAAAprbemmul/p8AAAAAIACOQhjsAAAAgQ
FtAEBBAIBAwME

And one from A to B's perspective:

1MOyoQIABAAAAAAAAAAAAP//AAABAAAAVVilU9NXCABCAAAAQgAAAFJUABI0VlJ
UABI0VggARQAANB3bQABABgjnCgAAAQoAAAKa23pprpf6fAAAAACAAjkIFCkAAA
IEBbQBAQQCAQMDBFVYpVPIYAgAQgAAAEIAAABSVAASNFZSVAASNFYIAEUAADQd2
0AAQAYI5woAAAIKAAABemma266X+nyul/p9gBI5CGOwAAACBAW0AQEEAgEDAwRW
WKVT008IAEIAAABCAAAAUlQAEjRWUlQAEjRWCABFAAA0HdxAAEAGCOYKAAABCgA
AAprbemmul/p8AAAAAIACOQgUKQAAAgQFtAEBBAIBAwMEWFilU4FfCABCAAAAQg
AAAFJUABI0VlJUABI0VggARQAANB3dQABABgjlCgAAAQoAAAKa23pprpf6fAAAA
ACAAjkIFCkAAAIEBbQBAQQCAQMDBA==

At first I thought that this is somehow related to some Linux 
TCP/IP quirk, so I experimented with turning off TCP timestamps 
and SYN cookies. I also tried increasing IP ID, which didn't help 
either. Both machines are running Debian 7.5 with linux-
image-3.2.0-4-686-pae under qemu 1.6.2. 

What am I missing?

Yours,
Jacek Wielemborek
Sushrut Mair | 10 Jun 07:14 2014
Picon

Problems while sending a string as tcp payload

Hi,

I am trying to send out an EICAR string via scapy. It gets sent out but it seems like scapy maybe 
modifying the string. Here is my code:

.
.
.
actualdata="X5O!P% <at> AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*"
ip=IP(src=ipsrc,dst=ipdst)
tcp=TCP(sport=srcp,dport=dstp,flags="PA",seq=last_packets_seqnum,ack=last_packets_acknum)
raw=Raw(actualdata.encode('utf-8','strict'))
data=ip/tcp/raw
print ls(data)        ---> #1
print actualdata   ---> #2
ACK=sr1(data)
.
.
.


#1 prints out he packet and the payload string. the string is printed out as,
"'X5O!P% <at> AP[4\\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'". Note the extra 
'\'. I have tried to escape the \ and tried other recommended stuff but to no avail.

#2 prints out the correct string as provided in actualdata.

The only difference between both, afaik, are that ls(data) is controlled by scapy while actualdata is a 
python string.

Can anyone help me with the same? The issue is that while the destination receives the string, it is 
unable to detect it as an eicar string.

Rgds,
Sushrut.

James Woolley | 5 Jun 17:58 2014

Missing payload

Hello,

I'm having some trouble getting a full UDP payload to be sent over a network.

I'm running on 1 machine the following:

send(IP(dst='192.168.66.1')/UDP(dport=2600)/'12345678901234567890')

And on the other machine:

receivedData = sniff(filter='udp and port 2600', iface='wlan1', count = 1)
receivedData[0]

and it returns:

<Ether  dst=00:0f:55:a2:3d:b5 src=00:0f:55:a2:38:c5 type=0x800 |<IP  version=4L ihl=5L tos=0x0 len=48 id=1 flags= frag=0L ttl=64 proto=udp chksum=0x7564 src=192.168.66.6 dst=192.168.66.1 options=[] |<UDP  sport=domain dport=2600 len=28 chksum=0xdbf6 |<DNS  id=12594 qr=0L opcode=6L aa=0L tc=1L rd=1L ra=0L z=3L rcode=not-implemented qdcount=13622 ancount=14136 nscount=14640 arcount=12594 qd='' an='' ns='' ar='' |<Raw  load='34567890' |>>>>>

As you can see the payload received is just the end section of the original payload. Is there something i am doing incorrectly.

The communication is done over a wireless network and it has at one point worked correctly. It must have been something i have changed to have it stop working.

Thank you in advance for your help.

Gmane