sqlmap-users

[sqlmap-users] [Bug] 1 bug and 2 optimizations

[Kasper F. <th...@ma...>]

Hello Sqlmap.

Bug:
When using sqlmap with --threads option, sqlmap first fetches the length 
of the thing to fetch, and afterwards starts some threads to fetch it.
Lets say it found a length 5 output, then it will write:

_ _ _ _ _
Then, when sqlmap finds the first of these, it will write this:

- - - - - (1/5 20%)
But, notice that it DID NOT write the letter it found. When the next 
letter is found it will write

x _ _ _ _ (2/5 40%)
It seems that it is "one-character behind" in displaying it to the user.

Optimization 1:
As just mentioned, when using --threads sqlmap first fetches the length 
of the output. It seems to me that no special fetching method is used 
for this, just one thread that fetches the number like any other output. 
But we know it is a number, and therefore we should be able to decrease 
the binary-searching to only search in the range of these numbers. A 
smart way to implement this might be to first check if the character we 
are trying to find is larger or equal to 0, and then check if it is 
smaller than or equal to 9. This should decrease the range, but still be 
able to find non-number outputs.

Optimization 2:
I have notized, that when having a rather large session file, sqlmap is 
crunching on this for a very long time - I don't know what it is doing, 
but my guess is that it is building some datastructure over the file. If 
I have a 4MB session file, sqlmap will use 100% of the CPU for about ½-1 
minute. I have no concrete idea to decrease this time, but I feel that 
it is an awfully long time, especially if a connection is lost, and I 
have to restart multiple times.

/Kasper

Re: [sqlmap-users] [Bug] 1 bug and 2 optimizations

[Miroslav S. <mir...@gm...>]

Hi.

You can checkout the latest development version from SVN repository and have
that bug fixed.

We will checkout that optimization suggestions you've proposed and let you
know afterwards.

Kind regards.

On Tue, May 11, 2010 at 11:53 AM, Kasper Føns <th...@ma...> wrote:

> Hello Sqlmap.
>
> Bug:
> When using sqlmap with --threads option, sqlmap first fetches the length
> of the thing to fetch, and afterwards starts some threads to fetch it.
> Lets say it found a length 5 output, then it will write:
>
> _ _ _ _ _
> Then, when sqlmap finds the first of these, it will write this:
>
> - - - - - (1/5 20%)
> But, notice that it DID NOT write the letter it found. When the next
> letter is found it will write
>
> x _ _ _ _ (2/5 40%)
> It seems that it is "one-character behind" in displaying it to the user.
>
> Optimization 1:
> As just mentioned, when using --threads sqlmap first fetches the length
> of the output. It seems to me that no special fetching method is used
> for this, just one thread that fetches the number like any other output.
> But we know it is a number, and therefore we should be able to decrease
> the binary-searching to only search in the range of these numbers. A
> smart way to implement this might be to first check if the character we
> are trying to find is larger or equal to 0, and then check if it is
> smaller than or equal to 9. This should decrease the range, but still be
> able to find non-number outputs.
>
> Optimization 2:
> I have notized, that when having a rather large session file, sqlmap is
> crunching on this for a very long time - I don't know what it is doing,
> but my guess is that it is building some datastructure over the file. If
> I have a 4MB session file, sqlmap will use 100% of the CPU for about ½-1
> minute. I have no concrete idea to decrease this time, but I feel that
> it is an awfully long time, especially if a connection is lost, and I
> have to restart multiple times.
>
> /Kasper
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> sqlmap-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlmap-users
>



-- 
Miroslav Stampar

E-mail / Jabber: miroslav.stampar (at) gmail.com
Mobile: +385921010204 (HR 0921010204)
PGP Key ID: 0xB5397B1B

Re: [sqlmap-users] [Bug] 1 bug and 2 optimizations

[Miroslav S. <mir...@gm...>]

Hi.

Bug is fixed, and those speed optimizations are implemented :)

Thank you for your report(s) Kasper and keep up the good work.

Bye.

On Tue, May 11, 2010 at 11:53 AM, Kasper Føns <th...@ma...> wrote:

> Hello Sqlmap.
>
> Bug:
> When using sqlmap with --threads option, sqlmap first fetches the length
> of the thing to fetch, and afterwards starts some threads to fetch it.
> Lets say it found a length 5 output, then it will write:
>
> _ _ _ _ _
> Then, when sqlmap finds the first of these, it will write this:
>
> - - - - - (1/5 20%)
> But, notice that it DID NOT write the letter it found. When the next
> letter is found it will write
>
> x _ _ _ _ (2/5 40%)
> It seems that it is "one-character behind" in displaying it to the user.
>
> Optimization 1:
> As just mentioned, when using --threads sqlmap first fetches the length
> of the output. It seems to me that no special fetching method is used
> for this, just one thread that fetches the number like any other output.
> But we know it is a number, and therefore we should be able to decrease
> the binary-searching to only search in the range of these numbers. A
> smart way to implement this might be to first check if the character we
> are trying to find is larger or equal to 0, and then check if it is
> smaller than or equal to 9. This should decrease the range, but still be
> able to find non-number outputs.
>
> Optimization 2:
> I have notized, that when having a rather large session file, sqlmap is
> crunching on this for a very long time - I don't know what it is doing,
> but my guess is that it is building some datastructure over the file. If
> I have a 4MB session file, sqlmap will use 100% of the CPU for about ½-1
> minute. I have no concrete idea to decrease this time, but I feel that
> it is an awfully long time, especially if a connection is lost, and I
> have to restart multiple times.
>
> /Kasper
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> sqlmap-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlmap-users
>



-- 
Miroslav Stampar

E-mail / Jabber: miroslav.stampar (at) gmail.com
Mobile: +385921010204 (HR 0921010204)
PGP Key ID: 0xB5397B1B

Re: [sqlmap-users] [Bug] 1 bug and 2 optimizations

[Kasper F. <th...@ma...>]

Hi Miroslav

That did a great thing! Length output is fetched amazingly fast now, and 
not much time is spent reading the sessionfile.

Great job! Nicely done.

On 11-05-2010 15:42, Miroslav Stampar wrote:
> Hi.
>
> Bug is fixed, and those speed optimizations are implemented :)
>
> Thank you for your report(s) Kasper and keep up the good work.
>
> Bye.
>
> On Tue, May 11, 2010 at 11:53 AM, Kasper Føns <th...@ma... 
> <mailto:th...@ma...>> wrote:
>
>     Hello Sqlmap.
>
>     Bug:
>     When using sqlmap with --threads option, sqlmap first fetches the
>     length
>     of the thing to fetch, and afterwards starts some threads to fetch it.
>     Lets say it found a length 5 output, then it will write:
>
>     _ _ _ _ _
>     Then, when sqlmap finds the first of these, it will write this:
>
>     - - - - - (1/5 20%)
>     But, notice that it DID NOT write the letter it found. When the next
>     letter is found it will write
>
>     x _ _ _ _ (2/5 40%)
>     It seems that it is "one-character behind" in displaying it to the
>     user.
>
>     Optimization 1:
>     As just mentioned, when using --threads sqlmap first fetches the
>     length
>     of the output. It seems to me that no special fetching method is used
>     for this, just one thread that fetches the number like any other
>     output.
>     But we know it is a number, and therefore we should be able to
>     decrease
>     the binary-searching to only search in the range of these numbers. A
>     smart way to implement this might be to first check if the
>     character we
>     are trying to find is larger or equal to 0, and then check if it is
>     smaller than or equal to 9. This should decrease the range, but
>     still be
>     able to find non-number outputs.
>
>     Optimization 2:
>     I have notized, that when having a rather large session file,
>     sqlmap is
>     crunching on this for a very long time - I don't know what it is
>     doing,
>     but my guess is that it is building some datastructure over the
>     file. If
>     I have a 4MB session file, sqlmap will use 100% of the CPU for
>     about ½-1
>     minute. I have no concrete idea to decrease this time, but I feel that
>     it is an awfully long time, especially if a connection is lost, and I
>     have to restart multiple times.
>
>     /Kasper
>
>     ------------------------------------------------------------------------------
>
>     _______________________________________________
>     sqlmap-users mailing list
>     sql...@li...
>     <mailto:sql...@li...>
>     https://lists.sourceforge.net/lists/listinfo/sqlmap-users
>
>
>
>
> -- 
> Miroslav Stampar
>
> E-mail / Jabber: miroslav.stampar (at) gmail.com <http://gmail.com>
> Mobile: +385921010204 (HR 0921010204)
> PGP Key ID: 0xB5397B1B
>