Home page logo

pen-test logo Penetration Testing mailing list archives

Re: Inverse Mapping Layout Through Scapy
From: Aditya K Sood <zeroknock () metaeye org>
Date: Fri, 02 Mar 2007 23:15:01 +0530

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.


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

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:

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.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]