Can't actually require FILENAME or REMOTE_FILENAME because I don't know
if you're going to upload or download. However, there shouldn't be a
stacktrace when you just try to go with neither.
See #5291. Adds an option to mess with the block size in case someone
wants to write a fuzzer or exploit that leverages that. Adds a cleanup
method to the module (pretty much required, it turns out). Looking
nearly final, just need to rename the module and I think we're good to
push to master.
Commenting the tricksy parts a little better for general usage.
Adding the ability to set FILEDATA instead of FILENAME, in case
only short bits of data are desired and the user doesn't want
to go to the trouble of creating a source file to upload.
Still need to deal with the use case of not passing a block; blocks
should not be required, it should be okay to invoke and just wait for
the complete attribute to be true. You'll miss out on error messages but
eh, maybe those should be return values.
Adds error checking and some helpful messaging in the event of an error.
In the event of a failed transfer the module exits immediately, but in
success, I'm still hanging around for several seconds after. Not a deal
breaker but can be annoying.
Also, need to implement a read as well as a write and store it as loot,
to be actually useful for most TFTP checking.
Tod Beardsley
Tab Assassin
Tod Beardsley
sinn3r
HD Moore