Thank you for the --sql-file update, it does exactly what I wanted! I think the default original format was only friendly if/when stacked queries is supported.
Also as an FYI, the length restriction on xpath functions (extractvalue/updatexml) are limited to 26 chars due to the fact that it is expecting a floating point result and thus the value is trimmed to 26 chars as this is limit on the default precision value returned for floating point values. Maybe just add a check to which method is used and reduce the chunk size from 50 to 26 when using either of these methods. I will try to dive into source later and see if I can't provide some code snippets to help out a bit more... Always appreciate your quick responses and updates! Thanks, HR On Sun, Aug 23, 2015 at 3:54 PM, Miroslav Stampar < miroslav.stam...@gmail.com> wrote: > p.s. with the latest commit you can use --sql-file with the content you > presented (one query per line) > > On Sun, Aug 23, 2015 at 10:34 PM, Miroslav Stampar < > miroslav.stam...@gmail.com> wrote: > >> Hi. >> >> Currently sqlmap "chunks" error-based query results into 50-char parts. >> This work(ed) pretty well (in FLOOR(RAND) case). >> >> Now you say that same "chunk" limit in your case goes way down. >> >> I've tested your claim this moment and it happens that you were right. >> Limit for EXTRACTVALUE is lower than used 50. >> >> Will think about it and do necessary "patching". Will let you know. >> >> Bye >> >> p.s. I really don't like the idea of one new switch. I'll patch this one >> and you won't need one (new switch). >> >> On Sat, Aug 22, 2015 at 6:59 PM, Johnathon Doe <hood3dro...@gmail.com> >> wrote: >> >>> I was trying to leverage sqlmap for an error based injection which >>> requires using extractvalue technique. Seems to work fine for basic info, >>> however there is a character limitation to the results with this xpath >>> methods typically limiting result to 26 chars due to nature of floating >>> point values it expects or something. Anyways, when dumping password >>> column, which is MD5 (32 char hex), SQLMAP fails to get the full values. >>> Now this can easily be accomplished manually via checking length of result >>> prior to query, then leveraging mid() to extract the chunks of the result. >>> >>> like so: >>> sElEct mid(user_pass, 1,26) from adm_users limit 0,1 >>> sElEct mid(user_pass, 27,32) from adm_users limit 0,1 >>> >>> I can do this from the --sql-shell or via --sql-query, but its taking >>> forever as I have a number of rows to fetch (150+). Any chance you could >>> look into adding some length checking to extractvalue attacks and >>> leveraging mid or substr where needed to get full results? >>> >>> Additionally, it would be great if I could load a file with one query >>> per line to run embedded. I thought the --sql-file option might accomplish >>> this task but it seems to be looking for a full .sql file to load and run. >>> I can't find anything in the docs or on the wiki on how to use this option. >>> Any chance you could shed some light on this option? How should I format >>> this .sql file for attack payload to be used? >>> >>> Can you look into adding a simpler option like a --sql-query-file=FILE >>> to load one query per line from FILE to embed and run, similar to the >>> --sql-query option that exists, just allowing for more bulk queries to be >>> run in a sequential order from file instead of typing them all in manually >>> for these weird edge case scenarios. >>> >>> i.e. cat queries.txt >>> sElEct mid(user_pass, 1,26) from adm_users limit 0,1 >>> sElEct mid(user_pass, 27,32) from adm_users limit 0,1 >>> sElEct mid(user_pass, 1,26) from adm_users limit 1,1 >>> sElEct mid(user_pass, 27,32) from adm_users limit 1,1 >>> sElEct mid(user_pass, 1,26) from adm_users limit 2,1 >>> sElEct mid(user_pass, 27,32) from adm_users limit 2,1 >>> ... >>> sElEct mid(user_pass, 1,26) from adm_users limit 150,1 >>> sElEct mid(user_pass, 27,32) from adm_users limit 150,1 >>> >>> Thoughts? >>> >>> Thanks, >>> HR >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> sqlmap-users mailing list >>> sqlmap-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/sqlmap-users >>> >>> >> >> >> -- >> Miroslav Stampar >> http://about.me/stamparm >> > > > > -- > Miroslav Stampar > http://about.me/stamparm >
------------------------------------------------------------------------------
_______________________________________________ sqlmap-users mailing list sqlmap-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlmap-users
