Re: New hexdump() function for nbase/nmap

[David Fifield <david () bamsoftware com>]

On Tue, Aug 25, 2009 at 11:41:20AM +0100, Luis M. wrote:
> Nmap currently uses two functions to dump hex bytes to stdout. One of
> them, hdump(), just prints raw hex bytes (no ASCII equivalents) and the
> other one, lamont_hdump() has a bug when printing buffers where
> bufflen%16==3. I've just implemented a new version from scratch,
> hopefully bug-free, that basically produces the same output as
> Wireshark. Output looks like this:
>
> 0000   e8 60 65 86 d7 86 6d 30  35 97 54 87 ff 67 05 9e  .`e...m05.T..g..
> 0010   07 5a 98 c0 ea ad 50 d2  62 4f 7b ff e1 34 f8 fc  .Z....P.bO{..4..
> 0020   c4 84 0a 6a 39 ad 3c 10  63 b2 22 c4 24 40 f4 b1  ...j9.<.c.".$@..
>
> I attach two patches. One of them includes the new function into nbase
> and the other one replaces calls to the old functions in nmap's code.
> Can some of you guys, please have a look at the patches, so I have a
> second opinion before applying them. Thanks.

Keeping a buffer of a whole line is a good idea. The code looks correct
but to me it's a bit hard to understand. I suggest a loop structure that
mirrors the output: one line at a time, each line of 16 bytes. Like
this:

i = 0;
while (i < length) {
        fill line with spaces
        add line number
        do {
                if (i % 16 == 8)
                        add space
                add hex of cp[i]
                add ascii of cp[i]
                i++
        } while (i < length && i % 16 != 0);
        copy line to output
}

The cp parameter should be const. Why are there 257, not 256, elements
in the asciify array? Nothing is ever stored or read from the final
element.

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org