Tag Info

Yes, sure. $ dd if=/dev/sda of=mbr bs=512 count=1 1+0 records in 1+0 records out 512 bytes (512 B) copied, 0.000188571 s, 2.7 MB/s $ ls -l mbr -rw-r--r-- 1 max max 512 2011-02-12 18:25 mbr $ hd mbr 00000000 eb 48 90 d0 bc 00 7c 8e c0 8e d8 be 00 7c bf 00 |.H....|......|..| 00000010 06 b9 00 02 fc f3 a4 50 68 1c 06 cb fb b9 04 00 |.......Ph.......| ...

Having expended far too much time with dump, it is probably best relegated to history. Its primary design goal was to be as efficient as possible with slow filesystems and the constraints of magnetic tape. Those design criteria no longer obtain and I cannot imagine a situation (aside from legacy systems) where dump would provide any advantage.

dump is traditionally used in cases where you need to image an entire device once, and not keep backing it up incrementally. Since it was created in a time where magnetic tapes were popular, random disk writes were not all that possible, making incremental backups nearly impossible. rsync is a more robust tool that doesn't try to account for those obsolete ...

One solution from over on ServerFault direct quote: I've made a script that accomplishes this task. The idea commes from James Lawrie's answer and this post: http://www.linuxforums.org/forum/programming-scripting/52375-reading-memory-other-processes.html#post287195 #!/bin/bash grep rw-p /proc/$1/maps | sed -n 's/^\([0-9a-f]*\)-\([0-9a-f]*\) .*$/\1 ...

Use fmem You used to be able to simply dd /dev/mem back in the day, but no longer for security reasons (since kernel 2.6, IIRC). The alternative is to either build the kernel yourself wih the option to let root do that (will edit with name later, on phone now) OR better, use fmem, a kernel module which creates a /dev/fmem device pretty much meant for easy ...

You probably can't dd your memory in modern kernels cause they've been reducing direct access, which is mostly used for dodgy things. The forensics wiki links a few tools that might be of interest, but there's nothing that's really been updated in the past few years. LiME seems updated though I haven't tested it yet.

I did the same command and that cause me a kernel panic. So decide to google it and find some interesting information. We are causing a kernel test crash when we execute this command echo c | sudo tee /proc/sysrq-trigger According to the ubuntu documentation If everything works, there should be some delay (depending on the memory size). Then the ...

That's what it's supposed to do. It could take a very long time for a server to dump ram, and depend on your host they may "catch" it and do something odd with it. My advise, "quit messin' with it". The command triggers a kernel panic. Nothing more. All that extra stuff, is configurable and not really reliable. Your hosting provider may catch it ...

In addition to the proposed answer I would also suggest to use simply hd: sudo hd /dev/sda -n 512 -s 0x0 00000000 eb 48 90 d7 bc 00 7a bb a0 07 8e db 8e c3 be 00 |.H....z.........| 00000010 02 8b ce fc f3 a4 ea a3 00 a0 07 b9 04 00 8b fd |................| 00000020 80 3d 80 74 05 83 c7 10 e2 f6 c3 b9 04 00 8b f5 |.=.t............| 00000030 88 2c ...