before) each group of tab.add, and there is no tab.nextrow before or
after tab.addrow. Also remove manual indenting that was accomplished by
padding the first column with spaces; this is done by
stdnse.format_output now.
indent and prefix before each line, not just at the beginning. If the
indent was ">>>>", then formatting the line "AB\nCD" would result in
| >>>> AB
|_CD
Now it will be
| >>>> AB
|_>>>> CD
Some script were working around this by relying on an invisible blank
first line and manually indenting following lines.
nothing in the current row yet. This allows using #t or ipairs to get
the number of rows that have been filled by the user. t.rows is the
index number of the next row that will be filled in, or the one that is
currently being filled in if something has already been entered.
t.rows == #t + 1 means that we've finished with the previous row, but we
don't want to count a new (blank) row until we've started filling
something in.
This should be handled by the generic case, and I don't think it was
used anyway because the logic was wrong:
if(indent == nil and #data == 1 and type(data) == 'string' and not(data['name']) and not(data['warning'])) then
return data[1]
end
This seems to be checking for a one-element table whose single element
is a string. But the test "#data == 1 and type(data) == 'string'" is
actually testing for a one-byte string. I think this is supposed to be
"type(data[1]) == 'string'", but anyway it should be handled by the
generic case.
sending the magic shell string but before sending a shell command.
Michael Meyer reported that the script would sometimes fail to report a
backdoor; I tracked this down to the sends happening in too-close
succession. The ProFTPD process could receive both sends
("HELP ACIDBITCHEZ\r\nid;\r\n"), read the first line, and execute the
shell, but then the shell would get no input because the "id;\r\n" had
already been read.
This causes a delay up to the timeout when there is a backdoor, but it
still returns right away when there is no backdoor.
General:
- Added support for Pre and Post scan NSE output. Index links at top only appear if
the sections exist.
- Host that are offline are now in a collapsible div element and collapsed by default.
- Added HTML Doctype of HTML 4.01 Strict, tidies up parsing
- The display for closed and filtered ports has been changed. By default the information
for closed and filtered ports is filtered from the tables if JavaScript is enabled.
The column header now has clickable links that will display each. The links indicate
the counts of each type (closed vs filtered) in the current table so that the user
can see at a glance if there is anything hidden. When printing the document the
printout will reflect the current status (hidden vs unhidden) of the ports. The
clickable links themselves are also not output when printing.
- There is also a floating box in the lower right hand corner of the display that contains
links that will toggle showing and hiding of ports in these states for the entire
document. This floating box contains a link to the top of the document as well.
- Traceroute - rearranged output, now uses a collapsible div element that is collapsed
by default.
- Host / Ping results section has been moved to a collapsible div element named Misc
Results. This element is collapsed by default.
- Remote OS Detection OS match wording is now more like Nmap normal output -
OS type (accuracy) instead of separate lines for os match and accuracy
- Changed how host index HTML anchors are created in order to deal with a warning about
the name attribute being deprecated
- Fixed a bug in the port script output that caused it to only span 5 columns instead of
6. Tested this with various levels of debug, verbosity, etc to make sure that the
number of columns does not change.
- Changed nmap_xsl_version variable from 9b to 9c, Changed the last updated date in the
header to be today's date (2010.12.28)
- Added Nmap version number to Scan summary section
- Wording of verbosity/debug levels changed/simplified.
- HTML title and first header wording changed.
- Added MAC vendor to host address section
- Changed host index to the format of hostname (IP) where preference is given to the
user supplied hostname.
General Style Changes:
- Changed color of script output cells in port table as well as hostscript and prescan
result tables slightly to make visual parsing easier
- First header (Nmap Scan Report..) color changed to use Nmap purple
- Closed and Filters ports - background color is now grey
- Down hosts are now denoted with a grey background in both the host index (top) and
body of results
OS Fingerprint:
- Fingerprint block now uses a collapsible div element. The block is collapsed by
default if the OS fingerprint is only present due to increased verbosity or debugging.
- Removed referenced fingerprint data ( reference fingerprint line number: 1000 )
- Reworded some sections of text for flow and readability.
Removed elements:
- Scan info Section - code was in place but has not been visible for some time. After
testing a few arrangements it was decided to just remove the data and code altogether.
- Runstats section, replaced by standard nmap completion string in the Scan Summary section
Open items:
1. Device types - currently have issues with output data consistency and formatting when
pulling a distinct list.
2. What criteria / counts should be used in situations described below? For example,
how many fingerprints are too many? How do we know if the fingerprint is high enough
quality to submit given that it may just be present due to the use of -v or -d?
> o It would be great to describe the OS detection results better.
> For example, if there are no exact matches, normal Nmap says "No
> exact OS matches for host ", followed up with "(test conditions
> non-ideal)" if that is the case. I think we should give a warning
> like this. Also, in the case that there are too many matches,
> normal Nmap says "Too many fingerprints match this host to give
> specific OS details"
> o If there are no exact matches, and Nmap feels that the quality is
> high enough for a submission, it would be great if the OS
> detection section would encourage the user to submit, just like
> normal Nmap does.
3. Does the OS fingerprint need to be printed (to paper/PDF) at all? The only scenario
that I could think of where this would be useful would be if the file was 'printed'
to digital media such as PDF.
4. Does the table of ports need to be changed so that closed and and filtered ports
are always printed (to paper/PDF) as opposed to printing in the format that is
currently displayed? My concern here is processes that automatically convert
documents, for example to PDF format.
