Ethical Hacker Community Forums

04/25/2008:

I love having time to update tools.

I got around to adding 64-bit support to pwdump (1.7.0) and cachedump (technically referring to it as 2.0), which means I needed to build a new version of fgdump. At the same time, I rolled out a few new features which I've either been sitting on, or have been talking about for awhile. And of course, as is typical with new releases, most AV is blind at least for a bit. :) Here's a list of things that have changed:


- fgdump will now detect 64-bit targets and report them as such
- 64-bit pwdump and cachedump will be used when the target is detected as 64-bit
- Fixed a problem when connecting to some Samba servers where RegQueryValueEx would not behave as expected
- fgdump will now generate a session ID during each run - used to correlate failed logs and regular logs
- Added command line to log file
- Added session ID to log file
- Created a new file with the format (session-id).failed which contains greppable data on failed hosts
- A log file is always generated of the format (session-id).fgdump-log
- -l will now override the default log name (see above)
- Added -a option to prevent tampering with AV. This is useful if you know AV is not picking it up, you want to tamper with the target as little as possible

A couple of notes about the log files. First off, a log file will ALWAYS be generated now, and will contain the date and time of the run. You can override this using -l if you want it to be named something specific. fgdump will now also generate a .failed file, which will contain a list of hosts that were unsuccessful. This file contains greppable records so you can quickly identify what hosts failed, why, and if there are still processes running on the host. This should help during the cleanup phase. The fields in this file are as follows (all separated by "|" characters):

1. Host IP/name
2. Windows error number (e.g. 5 for access denied)
3. 1 if processes are still (possibly) running on the target, 0 if everything should be cleaned up
4. Text of the error, if available

Additionally, the command line used to invoke fgdump is stored in the log file now. This means, if you pass the password on the command line, IT WILL BE RECORDED IN THE LOG FILE! If this bothers you, please omit the -p parameter and simply provide the password when fgdump asks for it. Please also note that this version has quite a number of changes in it and, while I'm releasing it as non-beta, there is a higher-than-normal chance for bugginess. As usual, please report any issues you find.