Sean Van Gorder | 1 Nov 14:40 2010
Picon

Re: scapy - feedback

I agree, Scapy is really not set up to handle relative offsets, especially not
to the degree that Microsoft uses them.  It's also awkward to deal with fields
in one layer causing minor changes to other layers, like the Unicode flag in
SMB.  Another issue I ran into is that packets in a PacketField or
PacketListField have no way of referencing fields in their parent packet.

Better support for offset-based data, cross-layer effects, etc. would probably
require some fundamental changes to the packet dissection process. 
Unfortunately I haven't really had time to look into it.

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

Sean Van Gorder | 5 Nov 15:11 2010
Picon

Re: Endian and bit independent processing

Savory Michael <msavory1 <at> nzbox.com> writes:

>
> Also given a multicast address, how do I set the matching MAC address.
> 
> What is currently implemented  in the old patch is 
> 
>       ipaddr = socket.ntohl(atol(ip.dst)) & 0x007FFFFF
>       macstr = "01:5e:00:%02x:%02x:%02x" %((ipaddr>>16)&0xFF,
(ipaddr>>8)&0xFF, (ipaddr>>0)&0xFF)
> 

There's no reason to use ntohl here.  This should work fine on all systems:

ipaddr = atol(ip.dst) & 0x007FFFFF

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

abouhali mouad | 9 Nov 16:12 2010
Picon

Scapy SSL and IP spoofing


Hello all,

   Porbably i'm telling something illogic however I want to know if is possible to forge HTTPS paquet and chaging each time the IP source -ip spofing- (taking into consideration that the same IP has to acheive the SSL handshake)

thanks in advance.


--

Bill Huba | 9 Nov 16:52 2010
Picon

Encapsulation Control

Hi,

I'm wondering if anyone can tell me how Scapy interacts with the NIC. I've read in the documentation that it bypasses the kernel, so does it hook right into the drivers? The reason I'm asking is that I want to use Scapy on a large project soon but I need to be sure that it gives full control of encapsulation. In other words, if I want to send a packet wirelessly will there be additional 802.11 encapsulation other than what I setup in Scapy?

Thanks,
-Bill

Tobias Mueller | 9 Nov 20:51 2010
Picon

Re: Encapsulation Control

Heya,

On 09.11.2010 16:52, Bill Huba wrote:
> I've read in the documentation that it bypasses the kernel
Where have you read that?

Cheers,
  Tobi

Bill Huba | 9 Nov 20:59 2010
Picon

Re: Encapsulation Control

Just to clarify, I was referring to sent packets only. In the FAQ section of the documentation, it says:

"The kernel is not aware of what Scapy is doing behind his back. If Scapy sends a SYN, the target replies with a SYN-ACK and your kernel sees it, it will reply with a RST. "

Thanks,
-Bill


On Tue, Nov 9, 2010 at 2:51 PM, Tobias Mueller <muelli <at> cryptobitch.de> wrote:
Heya,

On 09.11.2010 16:52, Bill Huba wrote:
> I've read in the documentation that it bypasses the kernel
Where have you read that?

Cheers,
 Tobi


Savory Michael | 9 Nov 21:13 2010

Re: Encapsulation Control

Hi Bill

>>> lsc()
send                : Send packets at layer 3
sendp               : Send packets at layer 2

So the send function uses the kernel routing table normally (and so can't spoof packets)
the sendp function uses the raw sockets interface and hence the kernel IP stack is unaware (but it does allow
you to spoof packets) http://www.linuxchix.org/content/courses/security/raw_sockets

Mike

On Nov 9, 2010, at 11:59 AM, Bill Huba wrote:

> Just to clarify, I was referring to sent packets only. In the FAQ section of the documentation, it says:
> 
> "The kernel is not aware of what Scapy is doing behind his back. If Scapy sends a SYN, the target replies with
a SYN-ACK and your kernel sees it, it will reply with a RST. "

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

Philippe Biondi | 9 Nov 22:51 2010

Re: Encapsulation Control

On Tue, 9 Nov 2010, Savory Michael wrote:

> Hi Bill
>
>>>> lsc()
> send                : Send packets at layer 3
> sendp               : Send packets at layer 2
>
> So the send function uses the kernel routing table normally (and so 
> can't spoof packets) the sendp function uses the raw sockets interface 
> and hence the kernel IP stack is unaware (but it does allow you to spoof 
> packets) http://www.linuxchix.org/content/courses/security/raw_sockets

Not exactly.

> On Nov 9, 2010, at 11:59 AM, Bill Huba wrote:
>
>> Just to clarify, I was referring to sent packets only. In the FAQ 
>> section of the documentation, it says:
>>
>> "The kernel is not aware of what Scapy is doing behind his back. If 
>> Scapy sends a SYN, the target replies with a SYN-ACK and your kernel 
>> sees it, it will reply with a RST. "

Sorry for the synecdoche. By kernel, I meant kernel's TCP/IP stack.

First scapy uses an abstraction to send packets, which I called 
supersockets, because they provide a higher service than normal sockets.

There are two kinds of supersockets: those which provide a layer 3 socket 
abstraction and those which provide a layer 2 abstaction.

Layer 2 supersockets can use libpcap/libdnet, linux's PF_PACKET sockets 
and there are some patches to use BSD's bpf. These enable a direct access 
to the link layer (Ethernet, 802.11, etc.), which sendp() for instance can 
access through the supersocket.

Layer 3 supersockets provide a layer 3 abstraction. By default they 
also use PF_PACKET on Linux and libpcap/libdnet on other systems. Thus the 
routing service must be provided. Scapy uses its own routing table (see 
conf.route), make its own ARP requests, etc. Another supersocket can 
use PF_INET/SOCK_RAW (a.k.a raw sockets).

Using PF_PACKET or libpcap/libdnet means kernel's TCP/IP stack is not 
aware about, for instance, sent SYN packets, and thus will answer 
unsollicited SYN-ACK with RST.

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

Sean Van Gorder | 9 Nov 23:45 2010
Picon

Re: scapy - feedback

I had time to really read through this today, so here's a more detailed
response.

> ->  Offsets
>
> Actually I want to get Value_A and Value_B, but the 'value' of both is
> 'hidden' in "Data", at a specific offset with a length and there is
> even some padding data of unspecified length in there.

I just added OffsetPacketListField to the community repository, it takes a
list of tuples containing the name of the field with the offset and the data
structure (layer class) at that offset.  Any data outside of the defined
packets is included in the list as Raw packets. It doesn't support a length
value yet, though.

You can pull the latest community-contributed code from
http://hg.secdev.org/scapy-com/

> -> Size ...
> Due to the liberal use of relative offsets as well as implicit and
> explicit padding, getting the length of a Field or Packet was required
> in many situations, I ended up adding Packet.size() and Field.size().

len(pkt) gives you the size of a packet, and fields have the i2len method.
Also, I came up with Packet.getfieldlen("field") for convenience, it uses
i2len on the value stored in the packet.  That's in the community repository.

> For fields, I've had problems with Field definition consistency,
> class TestPacket(Packet):
> 	name="Test Packet"
> 	fields_desc= [
> 		BitField("Reserved",0x00,7),
> 		BitField("Length",0,17)
> 	]
> length of this Packet should be 3 bytes, but I got 4 bytes initally,
> so now I count the bitlength, divide by 8, and round. As the total of
> all BitFields in a layer is likely a multiple of eight, this gives
> proper integers as a result.

I fixed that in the community repository, BitField.i2len now returns a float.

> It would have been great if there was a documented way to use h2i and
> friends to convert the input data to defined valid data types for
> i/m/h, to catch type & content errors in time.

Basically you want to separate them out like:
h = human = the clearest/easiest way for the user to input data
i = internal = the most convenient way to store the data for editing
m = machine = the data in byte string form (with minimal extra processing)

Usually i and h are the same thing and you can ignore h2i and i2h.  Special
processing/encoding/etc. goes in the addfield/getfield, for example adding
the null byte at the end of StrNullField, or the way bits in consecutive
BitFields are combined.  The line between those and i2m/m2i isn't really well-
defined, subclasses tend to inherit one and do their thing in the other based
on convenience.

> x.foobar = "special value"
> I forgot the \0, it is not a valid *NullField any longer.
> I could look for a \0 or \0\0 in case of unicode in addfield and add
> if not required, *but* then len(self.foobar) is off by one, as it
> misses the terminating \0, for unicode it would be off-by-two.

If you want the length of the field as it will appear over the wire, you need
to use Field.i2len(value) or Packet.getfieldlen("field").  When you access the
field value directly, you're getting the "h" or "i" form of the data, which
can't be guaranteed to be the same length as the final byte stream.

> Content error, the string is not null terminated in internal storage.
> Of course a proper h2i for StrNullField would have solved this, but
> obviously thats not 'the default'.
> 
> I'm about to fix this for all basic Fields I use, once I got an
> overview which parts of the logic are affected by the changes - I got
> burned by this more than once.

This shouldn't be necessary, following what I said above.

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

Bill Huba | 9 Nov 23:46 2010
Picon

Re: Encapsulation Control

Hi,

Thank you for your response, it's exactly what I needed to know. It sounds like Scapy is doing precisely what I wanted to use it for.

Thanks again,
-Bill


On Tue, Nov 9, 2010 at 4:51 PM, Philippe Biondi <phil <at> secdev.org> wrote:
On Tue, 9 Nov 2010, Savory Michael wrote:

Hi Bill

lsc()
send                : Send packets at layer 3
sendp               : Send packets at layer 2

So the send function uses the kernel routing table normally (and so can't spoof packets) the sendp function uses the raw sockets interface and hence the kernel IP stack is unaware (but it does allow you to spoof packets) http://www.linuxchix.org/content/courses/security/raw_sockets

Not exactly.


On Nov 9, 2010, at 11:59 AM, Bill Huba wrote:

Just to clarify, I was referring to sent packets only. In the FAQ section of the documentation, it says:

"The kernel is not aware of what Scapy is doing behind his back. If Scapy sends a SYN, the target replies with a SYN-ACK and your kernel sees it, it will reply with a RST. "

Sorry for the synecdoche. By kernel, I meant kernel's TCP/IP stack.

First scapy uses an abstraction to send packets, which I called supersockets, because they provide a higher service than normal sockets.

There are two kinds of supersockets: those which provide a layer 3 socket abstraction and those which provide a layer 2 abstaction.

Layer 2 supersockets can use libpcap/libdnet, linux's PF_PACKET sockets and there are some patches to use BSD's bpf. These enable a direct access to the link layer (Ethernet, 802.11, etc.), which sendp() for instance can access through the supersocket.

Layer 3 supersockets provide a layer 3 abstraction. By default they also use PF_PACKET on Linux and libpcap/libdnet on other systems. Thus the routing service must be provided. Scapy uses its own routing table (see conf.route), make its own ARP requests, etc. Another supersocket can use PF_INET/SOCK_RAW (a.k.a raw sockets).


Using PF_PACKET or libpcap/libdnet means kernel's TCP/IP stack is not aware about, for instance, sent SYN packets, and thus will answer unsollicited SYN-ACK with RST.


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



Gmane