Doh, tired and not reading - the util should help after you get a dump though. On Jan 13, 2014 7:29 AM, "shawn wilson" <ag4ve...@gmail.com> wrote:
> 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" <ach...@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 >> >> >>
