hc doesn't work when changing size of pane in tmux about wfuzz HOT 8 CLOSED

This is a known issue. Because the width of the screen, the special characters used to erase the line do not work correctly. I plan to migrate to curses at some point in the future.

from wfuzz.

That would be great. Thank you very much.

from wfuzz.

I look forward to the solution. This also happens when resizing Terminal in Mac OS.

from wfuzz.

I assume this is related, I'm having the same issue once the payload is too large for a single line. As you can see in the screenshot once the payload is 73 characters it doesn't fit and the line is not filtered even though it is 404.

No resizing is needed, so this is unfortunately slightly more annoying. I was trying to crash a server with payloads up to like 100k characters in different parts of the request (this is localhost, don't worry).

Edit: never mind, I'll use a different printer

from wfuzz.

Yes, it is the same bug.

from wfuzz.

This is a known issue. Because the width of the screen, the special characters used to erase the line do not work correctly. I plan to migrate to curses at some point in the future.

This seems to be a common issue with more than one duplicate. Is there anything you can do without migrating everything to curses? I know too little about python and terminal escape codes. Is there a way to not wrap the lines? Or to clear multiple lines if you know they've been wrapped? Maybe by inserting a marker to know how far you have to clear? Or add an option like the opposite of -v which will not show the payload at all. This would also solve another issue for me, because some fuzzing lists will contain escape codes and wfuzz outputs them as-is without proper escaping.

Anyway, a workaround would be to not show the contents of the "payload" column until the request is done and filtering has happened. This way I can still watch progress in real time and only if the payload becomes relevant (e.g. because it is not 404) I can see it.

from wfuzz.

Until this is fixed, you can use another printer as a workaround
ie. wfuzz -o raw -w xxx http:/xxxx

from wfuzz.

Please, check if this issue has been addressed in Wfuzz 2.4.

from wfuzz.