verify currently running software on ram

Mon Jan 13 12:29:46 UTC 2014

dd kmem and see if it's what you'd expect (size of ram+swap). If so you
should be able to look at it

Also see Volatility
On Jan 13, 2014 7:21 AM, "Tassos Chatzithomaoglou" <achatz at forthnet.gr>
wrote:

> Saku Ytti wrote on 13/1/2014 12:51:
> > On (2014-01-13 12:46 +0200), Saku Ytti wrote:
> >> On (2014-01-13 12:26 +0200), Tassos Chatzithomaoglou wrote:
> >>
> >>> I'm looking for ways to verify that the currently running software on
> our Cisco/Juniper boxes is the one that is also in the flash/hd/storage/etc.
> >> IOS: verify /md5 flash:file
> >> JunOS: filechecksum md5|sha-256|sha1 file
> >>
> >> But if your system is owned, maybe the verification reads filename and
> outputs
> >> expected hash instead of correct hash.
> > mea culpa, you were looking to check running to image, I don't think
> this is
> > practical.
> > In IOS its compressed and decompressed upon boot, so no practical way to
> map
> > the two together.
> > Same is true in JunOS, even without compression it wouldn't be possible
> to
> > reasonably map the *.tgz to RAM.
> >
> > I think vendors could take page from XBOX360 etc, and embed public keys
> inside
> > their NPU in modern lithography then sign images, it would be impractical
> > attack vector.
>
> I was assuming the vendors could take a snapshot of the memory and somehow
> "compare" it to a snapshot of the original software.
> Or (i don't know how easy it is) do an auditing of the memory snapshot on
> specific pointers...well, i don't know...just thinking loudly...
> > But changing memory runtime is probably going to very complicated to
> verify,
> > easier to create infrastructure/HW where program memory cannot be changed
> > runtime.
> >
> I agree, and we already do that, but a regulatory authority has brought
> into surface something trickier.
>
> --
> Tassos
>
>
>