I am using the latest Ubuntu Linux with a custom kernel (4.2.0-36-generic), in which I have disabled the CONFIG_STRICT_DEVNEM, because I need to dump and search some terms in memory during a project.

However, when using:

  • dd if=/dev/mem to print it on screen,
  • dd if=/dev/mem of=/home/user/Documents/file.dump to save it as a file, or
  • dd if=/dev/mem | hexdump -C | grep 'term' to directly find what I'm looking for,

the system freezes and reboots while in the process.

I have checked with df -h and my disc has plenty of free space. Also, the process always stops after writing a 2.1Gb to 2.5Gb, out of a 8Gb RAM and before reaching addresses that start with 4 (if these make any difference). In addition, checking /var/log/syslog and /var/log/kern.log shows nothing relevant before the freezing.

Also, using parameters bs=1G count=2 successfully copies the first 2GB of the memory but then trying bs=1G count=2 skip=2 to get then next 2GB again freezes the system.

Would you suggest any solution so it is possible to dump the full memory or some other way to directly search terms in memory?

  • Why did you use the forensics tag? – user147505 Sep 24 '16 at 17:29
  • What, exactly do you mean with "addresses that start with a 4"? If 2 GB means 2147483648 bytes, it starts with a 2 in decimal, an 8 in hexadecimal and a 2 in octal? – ilkkachu Sep 24 '16 at 17:39
  • @ilkkachu Regarding the addresses, trying dd if=/dev/mem | hexdump -C, in the output I get the addresses ascending from 0. When it almost reaches addresses starting from 4, the system freezes. – Alexander Lattas Sep 24 '16 at 17:47

I think you may run into some memory area used by PCI/ACPI or some such hardware. There might be a memory mapped device that doesn't like being accessed. I can't tell what address exactly causes the problem, but it's usual for some special areas to be located just under the 4 GB limit.

On one machine with 4 GB memory, the kernel prints the following on boot:

BIOS-e820: 0000000000000000 - 000000000009e400 (usable)
BIOS-e820: 000000000009e400 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000cf690000 (usable)
BIOS-e820: 00000000cf690000 - 00000000cf6e0000 (reserved)
BIOS-e820: 00000000cf6e0000 - 00000000cf6e3000 (ACPI NVS)
BIOS-e820: 00000000cf6e3000 - 00000000cf6f0000 (ACPI data)
BIOS-e820: 00000000cf6f0000 - 00000000cf700000 (reserved)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000130000000 (usable)

Part of the usable memory is above the 4 GB limit at 0x100000000 and there seems to be holes between 0xcf700000 and 0xfec00000.

The areas corresponding to "usable" memory are also shown in /proc/iomem, marked as "System RAM". (the file also contains information about the other memory areas.) You might be safer just reading from those areas.

$ grep "System RAM" /proc/iomem 
00001000-0009e3ff : System RAM
00100000-cf68ffff : System RAM
100000000-12fffffff : System RAM
| improve this answer | |
  • Thank you. This actually helped me to resolve my issue. Looking in /var/log/kern.log I also found memory area used by PCI/ACPI. Then using only the System RAM area found in grep "System RAM /proc/iomem I could get as much as 3.5Gb out of an 8Gb RAM. I used a command similar to: sudo dd if=/dev/mem of=Filename bs=10924030 count=1 skip=1 ibs=3390349312 for every System RAM memory area. Now I am looking which other memory areas I could dd without any problem and I will update. – Alexander Lattas Sep 25 '16 at 9:14
  • Update: In total, I can safely dd memory areas set as "System RAM", "RAM buffer" and "reserved". – Alexander Lattas Sep 25 '16 at 16:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.