Recover unsaved notepad process ?

Then, i heard about memory scrambling and rumours that this method are not guaranteed to work on DDR3.

But apparently, a new method of the "Cold Boot Attack" was discovered in 2018.
Does this method can bypass memory scrambling to allow a good dump ?
Can someone know how to pull off this method with no special hardware ?

Any help are welcome.

Thanks you.

I remember a paper from 2016
https://www.sciencedirect.com/science/article/pii/S1742287616300032

about descrambling DDR3, that also highlights how data persistence is much lower.

In 2018 there were findings by Olle Segerdahl and Pasi Saarinen
https://blog.f-secure.com/cold-boot-attacks/
possibly working around some of the defensive measures in the meantime implemented by manufacturers.

But all of them are - essentially - laboratory experiments, I doubt that they are replicable in real life, with real data, on *random* hardware.

jaclaz

My PC crashed (BSOD) last week.
I had 40 to 50 unsaved notepad process.
Is it possible to recover them ?

Impossible to say for certain.

At least some older versions of Notepad keeps temporary files in the users …/AppData/Roaming directory. You'll probably need to rely on file content to identify the files – actual file names are temporary also.

With so many process around, you may also find fragments in the pagefile, unless the edited files were small enough to keep in primary memory all the time.

jaclaz

That what i was referring to.
I've sent an email to Olle Segerdahl but didn't receive any response yet.

It should be replicable in real world, why not ?
I've read the manual of the motherboard and i didn't see any mention about memory scrambling, unlike the motherboard of my 2nd PC from 2015 (Asus H97M-Plus) which have "Memory Scrambler" option. (which is enabled by default by the way)
So there is a hope that memory scrambling was not implemented yet in my old PC from 2012.

athulin

This was not implemented in Windows 10 ?
I didn't heard that Notepad keep unsaved instances in temp folder before Windows 10.

The process was not using so much memory, about ~500KB to 1MB for each process.

It should be replicable in real world, why not ?

IMHO because they are essentially POC's. ?

Your actual memory is not - like the one used in most of these experiments a N number of Monna Lisa bitmaps directly loaded to memory at a given interval, interspersed by easily recognizable patterns and the rather narrow temperature interval connected to DDR3 makes it more difficult to actually perform the reboot while keeping the data.

Besides a bitmap is often very recognizable even if partially corrupt, a text file may be not so.

And you have only one chance (as opposed to what - possibly tens or hundreds of tests the various researchers made to refine the procedure they were finally successful with).

So, if you are willing
1) to procure yourself another computer identical to the one you have the issue with
2) reproduce as accurately as possible the situation (40-50 Notepad opened with some text on it and force a BSOD)
3) do a few (possibly tens of) tests refining the way you freeze the RAM (if your 8 GB are a single ram stick it may be easier than if they are 2 x 4 GB sticks)
4) verify that you can recover the texts

Then you will be ready for the single, very likely "all or nothing" recovery attempt on the real machine.

jaclaz

I will go for the "all or nothing" route directly.
In hope that my motherboard will not do any sort of memory scrambling.
But at least, i need the right tool which can capture all the RAM.
I tried the 32 bits version of the bios_memimage scraper and it's working.
But the 64 bits version are not launching, it just reboot the PC.

Here is the official link of the code Cold Boot Attack

In order to compile the 64 bits version, this command is required
make -f Makefile.64

Then, this command is required to write the scraper.bin file on the USB drive
sudo dd if=scraper.bin of=/dev/sd?

*? are the letter of the USB drive, generally b

Someone with little more knowledge than me can maybe try to pull this off and see if the scraper are launching ?

I will go for the "all or nothing" route directly.
In hope that my motherboard will not do any sort of memory scrambling.
But at least, i need the right tool which can capture all the RAM.
I tried the 32 bits version of the bios_memimage scraper and it's working.
But the 64 bits version are not launching, it just reboot the PC.

Here is the official link of the code Cold Boot Attack

In order to compile the 64 bits version, this command is required
make -f Makefile.64

Then, this command is required to write the scraper.bin file on the USB drive
sudo dd if=scraper.bin of=/dev/sd?

*? are the letter of the USB drive, generally b

Someone with little more knowledge than me can maybe try to pull this off and see if the scraper are launching ?

No solution (that I know of) about 64 bit compiling, but there is a (better/easier?) way to make a USB stick (and test it on other hardware)
https://www.rmprepusb.com/tutorials/124
(BTW on there it is specified that noone seemingly was able to compile the 64 bit version)

The issue may lie with the way the BIOS (if it is BIOS) orders disks when booting.
Typically (but not always) the boot disk (the USB stick in this case) might become first disk (hd0) or the internal hard disk may remain first disk (hd0) and the USB stick may be second disk (hd1).

If you have UEFI instead, the above won't help as grub4dos is not UEFI compatible. (while the issue with disk numbering may still be relevant).

jaclaz

I am testing it on very old PC under BIOS so that should not be the problem.
I disabled all booting options in the BIOS prior to connecting the USB drive.
I'm forcing him to boot to the USB drive with the F12 key.

Like i said, 32 bits scraper work.
When i compiled the 64 bits version, it looked like it gonna work.
But when trying to boot on the USB drive, the PC reboot.
Very strange.

Like i said, 32 bits scraper work.
When i compiled the 64 bits version, it looked like it gonna work.
But when trying to boot on the USB drive, the PC reboot.
Very strange.

If you successfully built the 64-bit version, the grub4dos intermediate approach may still help you understand if the issue is in the early booting phase, as - as seen on the linked to howto - it may allow to modify some BIOS parameters and allow booting (if and only if the problem is in the very early stage of booting).

The Author of RMPREPUSB/EASY2BOOT is a member (and often takes parts in discussions) of reboot.pro as Steve6375.

Surely he would be interested in the 64 bit version (as there were issues at time in compiling it) and may possibly test it and/or provide insights in its bootability

http//reboot.pro/

I am testing it on very old PC under BIOS so that should not be the problem.
I disabled all booting options in the BIOS prior to connecting the USB drive.
I'm forcing him to boot to the USB drive with the F12 key.
.

Still this tells you nothing about how it will behave on the "real" machine (and besides you have to take into account the precious seconds needed to change BIOS settings - if needed - on the "real" machine).

jaclaz

Hello,

My PC crashed (BSOD) last week.
I had 40 to 50 unsaved notepad process.
Is it possible to recover them ?

When the computer BSOD'd did it create a crashdump? You may be able to analyse that with windbg