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 > > >