Info
Changelog
DocumentationDownload
Git
0.8.2b
Release - Thu Oct 12 10:56:27 CDT 2006
Changes:
- Removed dependance on "tempfile" command, which apparently is Debian/Debian derivative specific. SQLIer should now work on most GNU/UNIX platforms.
- Fixed a bug where "~/.sqlier" didn't exist, the script would break.
0.8.1b
Release - Thu Aug 17 02:09:40 CDT 2006
Changes:
- Added non-blind injection support. This means that brute force isn't required if the hole isn't blind, and speeds the exploit up a lot.
- Before determining "UNION SELECT" exploits aren't possible, sqlier now attempts to bypass some common filtering mechanisms before giving up.
- Added support for subquery based exploits. This allows sqlier to fall back on a feature in MySQL 4+ that is harder to filter for the brute forcing.
- Altered detection engine a lot, fixing a bunch of injection issues.
- Changed the format of the saved exploits, putting the exploit URL in with the encoded part so that one string can represent the whole exploit.
- wget options in the saved exploits are now encoded, fixing a bug where the wget option has a colon in it.
- Fixed a bug on how the strings were encoded, creating spaces in the string which were problematic.
- Various other bug fixes and engine tweaks.
0.8b
Release - Sun Aug 06 15:07:29 CDT 2006
Changes:
- Now attempts to determine table, username field, and password field names.
- Automatic building of SQL Injection statement.
- Accepts multiple usernames.
- Saves status so that the script doesn't have to perform the same operations over and over again.
- New option based interface, rather than argument based.
- Changed to beta status since previous "Planned" goal reached.
- Instead of assuming blind SQL Injection, script should also figure out if working with a non-blind hole and take a shortcut to the final query.
0.1.1a
Release - Wed Aug 02 05:55:11 CDT 2006
Changes:
- Had some debug code left in it which caused it to exit prematurely.
0.1a
Release - Tue Aug 01 15:35:19 CDT 2006
Changes:
Planned:
- Detection of SQL Injection hole type, query length, database name, and field names to build the SQL Injection exploit itself, then exploit it. The only downside of me doing this is that between VulnDetector and this, script kiddies would no longer even have to know what SQL stands for.
