Re: Inverse Mapping Layout Through Scapy

From: Aditya K Sood (zeroknock@metaeye.org)
Date: Fri Mar 02 2007 - 12:45:01 EST


Hi cid

 Thanks a lot.
I have no intention to tell you how scapy is working and hope from your
side too.Actually i have to lay stress on the Padding and raw data exactly.
I know the point you are making.The things should be in full.

Regards
Adi

Cedric Blancher wrote:
> Le vendredi 02 mars 2007 à 09:48 -0500, Aditya K Sood a écrit :
>
>> 0xa] First of all the inverse mapping , acc to standard is a
>> technique to check the host is alive or running services.This
>> is accomplished by sending a Reset flag to the destination.
>>
>
> OK, then reverse mapping = RST scan. What a complicated denomination for
> such a simple thing :)
>
>
>> Look at this:
>>
> [...]
>
> You don't need to detail me how Scapy is working. Philippe is seating
> less than one meter from me right now, and I use Scapy pretty often[1].
>
>
> So basicly you're trying to evaluate padding impact on reverse mapping
> and end up with the conclusion it has no effect. Am I right ?
>
>
>> 0xc] The question of padding is i used it in just a raw data to be
>> attached and to check it has some implications or not or whether
>> it is changing the output stats.
>>
>
> There's a clear difference between *raw data* and *padding*. Padding is
> something you add behind a datagram to have it fit some constraints, but
> without being part of it. See ethernet padding when there's not enough
> data to reach 64 bytes, IP header and TCP header padding to get 32 bits
> aligned. You can also artificialy add non expected padding.
>
> If I take the example of UDP, here's the difference. Say we have a UDP
> datagram with 4 bytes of data. We'll add "XXXX" behind this datagram. If
> we do it as raw data, we will have:
> . IP header length: 20 bytes
> . IP length: 36 bytes
> . UDP length: 8 bytes
>
> If we add "XXXX" as padding to this UDP datagram, than they're no more
> part of the UDP datagram. Thus, we have:
> . IP header length: 20 bytes
> . IP length: 36 bytes
> . UDP length: 4 Bytes
>
> We end up ion a situation where IP_length - IHL > UDP_length, and we
> "lose" 4 bytes of data between IP and UDP.
>
> So, when you speak of adding padding to TCP, it does not make much
> sense, because it would mean either you try to pad TCP header or the
> whole TCP datagram, which is, unlike this UDP situation, is not
> possible.
>
>
> That's where I lost you, as I don't see what padding has to do with it.
> I know it's a dumb question of vocabulary, but sometimes, words have a
> meaning that can make your point very unclear if not used properly.
>
>
> So, as a reader suggestion to your post, I think you should announce
> what you intend to do more clearly, and definitly choose between padding
> and raw data once and for all, as three other people around me didn't
> get your point either and were disturbed by this padding thing.
>
>
> My 0,02¤...
>
>
>
> [1] and also wrote a tool based on it:
> http://sid.rstack.org/index.php/Wifitap_EN
>
>

------------------------------------------------------------------------
This List Sponsored by: Cenzic

Need to secure your web apps?
Cenzic Hailstorm finds vulnerabilities fast.
Click the link to buy it, try it or download Hailstorm for FREE.

http://www.cenzic.com/products_services/download_hailstorm.php?camp=701600000008bOW
------------------------------------------------------------------------



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:57:37 EDT