[colug-432] Necropsy: Virus?: objdump -d; size

[Matthew W. Miller]

On Tue, May 03, 2011 at 07:14:21PM -0400, jep200404 at columbus.rr.com wrote:
> On Tue, 3 May 2011 18:07:32 -0400, Jeff Frontz <jeff.frontz at gmail.com> wrote in another order:
> > On Tue, May 3, 2011 at 5:59 PM,  <jep200404 at columbus.rr.com> wrote:
> > > What non-malicious reasons can there be for a new version of a
> > > program to have the same size and timestamp as an old version,
> > > yet have different md5sums?
> > You can use objdump to see if the parts that
> > matter (.bss, .data, .rodata and code -- the last via -d) have
> > actually changed.
> [root at localhost backup]# diff <(objdump -d 20110322/bin/cp) <(objdump -d 20110324bad/bin/cp)
> 2c2
> < 20110322/bin/cp:     file format elf32-i386
> ---
> > 20110324bad/bin/cp:     file format elf32-i386
> [root at localhost backup]# diff <(objdump -d 20110322/bin/rpm) <(objdump -d 20110324bad/bin/rpm)
> 2c2
> < 20110322/bin/rpm:     file format elf32-i386
> ---
> > 20110324bad/bin/rpm:     file format elf32-i386
> [root at localhost backup]#

Try specifying -x to objdump as well so it dumps all sections, not just
'the parts that matter'.

>
> > Also, even if "ls" says the files are the same size, things may have
> > been rounded up to some nice round value; a better quick check is to
> > use "size" to see if the important parts have actually changed size.
>
> [root at localhost backup]# size 201103*/bin/cp
>    text    data     bss     dec     hex filename
>   64846    1792       0   66638   1044e 20110322/bin/cp
>   64846    1792       0   66638   1044e 20110324bad/bin/cp
> [root at localhost backup]# size 201103*/bin/rpm
>    text    data     bss     dec     hex filename
>   79068    4684   42268  126020   1ec44 20110322/bin/rpm
>   79068    4684   42268  126020   1ec44 20110324bad/bin/rpm
> [root at localhost backup]#
>
> Even if the parts that changed do not matter, what non-malicious
> causes for those differences are there? That there is any change
> at all is suspect.

It's possible some filler bytes were filled by different values in
different compiles.
	Spotting binary differences the quick-'n'-dirty way:

$ cmp -lb thisbinary thatbinary | less

shows all differences between bytes at the same offsets of thisbinary
and thatbinary, both in octal and ASCII.
	Spotting binary differences the somewhat slower and more
intelligible way:

$ diff <(hd thisbinary) <(hd thatbinary)

shows differences between bytes in the context of preceding and
following data.  You can substitute your favorite hex dumper for hd, of
course.  And personally I prefer to specify at least '-u' to diff
because I find unified diffs easier to manually parse, but your mileage
may vary.
	Oh, and I didn't know that <(stdin from command output) trick
before.  Neat!
-- 
Matthew W. Miller <mwmiller at columbus.rr.com>