Up-to-date OLSR module

Hi everyone !

First thing I have to introduce myself, I am a french IT (network,
security and so on...) student and I am currently studying security
concerning the OLSR routing protocol.
I have found on the official Scapy website a

--

-- 
Cédric
"Soyons désinvoltes, n'ayons l'air de rien..."

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

Re: Up-to-date OLSR module

On Wed, Jul 9, 2008 at 10:14 AM, Cédric Canitrot
<cedric.canitrot <at> gmail.com> wrote:
> Hi everyone !
>
> First thing I have to introduce myself, I am a french IT (network,
> security and so on...) student and I am currently studying security
> concerning the OLSR routing protocol.
> I have found on the official Scapy website a
>

Ooops... Sorry...
So I have found a OLSR module for Scapy on the Scapy homepage but this
module doesn't seem to work because it is too old to work with current
Scapy version.
Here is my question : does someone have updated this module to make it
work with the latest version of Scapy ?

--

-- 
Cédric
"Soyons désinvoltes, n'ayons l'air de rien..."

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

Re: Re: Up-to-date OLSR module

Hi Cedric,

there were some API changes [1] introduced in the last couple of month.
That's why it doesn't work anymore. 

I tried to fix the bugs, but I can't verify if the olsr implementation
works now, because I don't have any pcap file with olsr packets. You can
find an updated scapy-olsr.py attached to this mail.

best regards,

jochen

1.) http://trac.secdev.org/scapy/wiki/LengthFields

Re: Re: Up-to-date OLSR module

On Wed, Jul 9, 2008 at 4:40 PM, lobo <lobo <at> c3a.de> wrote:
> Hi Cedric,
>
> there were some API changes [1] introduced in the last couple of month.
> That's why it doesn't work anymore.
>
> I tried to fix the bugs, but I can't verify if the olsr implementation
> works now, because I don't have any pcap file with olsr packets. You can
> find an updated scapy-olsr.py attached to this mail.
>

Hi Jochen,

It does work with the last version of Scapy !
I only get one warning while sending a packet telling me that
post-build() now takes 2 arguments and that the compatibility is only
assured for a short transition time but it seems to work anyway :)

I'll keep you in touch if I discover any issue or if I can propose any
improvements for your great work ;)

Again, thank you for your unvaluable help !

--

-- 
Cédric
"Soyons désinvoltes, n'ayons l'air de rien..."

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

WinCE?

How to decrypt a wep key using unwep()

what is the correct way to decrypt a wep key using Dot11.unwep()

I am having a hard time figuring it out for some reason

any ideas

Cheers

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

Re: How to decrypt a wep key using unwep()

Andrew schrieb:
> what is the correct way to decrypt a wep key using Dot11.unwep()

I'm not sure what you mean by "decrypt a wep key".
You cannot use Scapy to find out an unknown key (at least not easily).
But if you supply the correct key yourself, you can decrypt the packets.

I think the easiest way is to use the toEthernet() method on 
Dot11PacketLists. This uses unwep() internally (after some filtering) 
and returns the results as Ethernet frames:

 >>> enc=rdpcap("weplab-64bit-AA-managed.pcap")
 >>> enc.show()
 >>> enc[0]
 >>> conf.wepkey="AA\x00\x00\x00"
 >>> dec=Dot11PacketList(enc).toEthernet()
 >>> dec.show()
 >>> dec[0]

Regards
Dirk

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

High Level Checksum "fix" solution?

I've written a dinky syslog replay program that creates a PcapReader
and shoves the UDP payload in a new IP packet to redirect to a new
host.

My first cut at this involved:

1) Read Pkt
2) Change Macs
3) Change IPs
4) scapy.sendp(pkt)

That broke the chksums on all the packets.   I worked around my
problem by creating Ether() and IP() from scratch.  Is there a
high-level idiom for fixing those chksums or is that left an an
exercise for the reader? I'm just trying to make sure next time I
spend my time on the right parts of the problem.

Thanks,
Chris
--

-- 
Chris Green <greencm <at> gmail.com>

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

Pretty big bug in FloatField found/fixed

I found a fairly serious set of bugs that prevented packets which
include a FloatField (e.g. NTP packets) from being correctly dissected
and from being written out. The details (along with a patch) are all in
the trac ticket page at http://trac.secdev.org/scapy/ticket/119

  -- William

P.S. I found another set of bugs which I'll introduce in another thread.

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

Bugs in TimeStampField(), and an appeal for an API change...

Related to the bug I filed at http://trac.secdev.org/scapy/ticket/119 ,
I have discovered that TimeStampField has some serious problems. The
following three issues have been identified so far:

     1. There are possible values that are returned from getfield() that
        are not handled addfield() method (thus raising exception
        whenever  build(), str(), wrpcap(), etc are called on the
        packet). A good example of this is that 'None' (odly enough,
        which is returned as the string "None" and not the value None.
     2. Inconsistent handling of time zone information between getfield
        and addfield occurs. In particular, getfield() calls gmtime
        (which normalizes to UTC and always sets daylight savings to 0 )
        and addfield() utilizes mktime() (which is relative to local
        time zone)
     3. The getfield() method ignores fractional seconds from the read
        in data. This means, any field value that gets handled by
        TimeStampField truncates the time resolution to a full second
        and that the packet data that gets written out to a pcap file
        may *NOT* be the packet data that was actually sent.

I set about to write a patch for these issues and the first 2 bugs were
pretty easily fixed. Fixing the 3rd one became problematic though, since
the dissected python value returned from a TimeStampField is a string
containing a date stamp of the format "%a, %d %b %Y %H:%M:%S +0000"
(e.g. 'Fri, 25 Jul 2008 17:11:16 +0000'). When the packet goes to get
written, this string is fed to time.strptime() (which doesn't have a
format field for fractional seconds) to get the seconds since epoch to
convert into binary. This conversion of 64 bit binary field into a
string and back again using the time module is a very lossey process
(effectively zeroing out least significant 32 bits of the field).

Ideally, I'd like to change the behavior of the TimeStampField to return
(and accept) a datetime.datetime() object which supports microsecond
resolution. This is a pretty major API change though. I'm not even 100%
it's feasible for the dissector to return a datetime.datetime object (I
don't see why it wouldn't be, but it's been ages since I tinkered with
the internals of scapy). Anyway, if returning the datetime object itself
is too big of a change, then I'd like to at least change the date string
format from the current format (which doesn't handle fractional seconds)
to the ISO 8601 format (e.g. '2008-07-25T20:48:26.076754'). This way,
the fractional seconds could at least be represented within the return
value. As things are now, scapy is severely limited when it deals with
NTP.

  -- William

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