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@forthnet.gr> wrote:
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
Saku Ytti wrote on 13/1/2014 12:51: 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