42 replies to this topic

[joakim]

Here is my version of a low level file copier (commandline) with source included; http://mft2csv.googl...py_v1.0.0.5.zip

 

On a second thought, I will make it available here too.

 

Edit: It now is.

[Wonko the Sane]

Revamping this thread because seemingly both erwan.l's and joakims' tools, included the updated versions on github:

https://github.com/jschicht

seemingly do not work with a subset of "in use" files (namely pagefile.sys and hiberfil.sys, possibly on new stupid Windows OS's also the stupid swapfile.sys ).

Some reference:

http://www.forensicf...wtopic/t=13653/

 

and some previous discussion in an unrelated thread (just to keep everything as together as possible), starting from here:

http://reboot.pro/to...mpreg/?p=196561

 

Wonko

[Wonko the Sane]

You can always copy the file, regardless whether it is in use or not, but of course their hashes may not match. Moving is a different story, you generally can't move any file if it's in use.

 

The best copy softwares for Windows are UltraCopier/SuperCopier. I used to use TeraCopy but it crashes too much.

Well, I would already be happy to have the extents for the file. (then with direct disk access I would have no issues, at least up to XP)

 

Did you actually tried using Ultracopier or Supercopier to specifically copy pagefile.sys?

 

Or, even better, did you ever try to copy (not move) the file pagefile.sys (not another file, in use, locked or whatever, specifically pagefile.sys)?

 

And if you did, did you copy it successfully (even if the hashes did not match, was a file of the right size created on the target)?

 

And if you had succesfully copied it, which tool did you use?

 

And is this tool 1. Command Line, 2. Open Source ?

 

Wonko

[Wonko the Sane]

@ Wonko: You make no sense. Why *THE FUCKING HELL* would I want to copy my own page file on my running Windows system?! There is no data in it that I care about, and of course it will be locked/in use. I can understand a hacker want to inspect it, maybe to retrieve passwords/encryption keys etc, which is which I always run without a page file if RAM is plentiful, and keep all my volumes encrypted. An attacker could only gain access via some kind of snooping that doesn't involve wires, a keylogger, perhaps direct PC access (to extract contents of RAM etc).

So - as expected BTW - you posted:
 

You can always copy the file, regardless whether it is in use or not, but of course their hashes may not match.

incorrect information about something that you have no idea, nor experience about, and that you cannot even imagine a reason for, without actually reading what I had just posted and the (given) references.
 
The whole thread started in 2009 and revolves around "in house" and "simple" alternatives to the very few tools (WinHex, FTKIMager, DMDE, etc.) that can actually do what is asked.

Since 2013 and till now everyone thought that erwan.l's and joakims tools were valid answers, now it seems like both fail with pagefile.sys (while WinHex, FTKImager, DMDE can actually copy this file fine).


Wonko

[erwan.l]

Hi Wonko,

 

To me, no conventional way will manage to read the file.

You need to "attack" the system using unconvential ways.

 

Currently looking at injecting code into "system" process : from there I should be able to retrieve either a pagefile handle which I can then use to retrieve the file extents or even dump the extents straight from the process itself.

 

Very aggressive approach thus

Regards,

Erwan

[erwan.l]

Actually.......I had already read the entire topic before posting. I can understand why someone would want to copy locked files, but I have no interest in my pagefile's contents. You asked if I had tried to copy it, I provided a rebuttal. Maybe you can conjure up a logical reason for me to bother wasting my time doing such a thing? Benefits?

 

Hey, this forum is about fun and about being curious.

 

Does it always need to be a "why"?

 

Many of the tools I have delivered over here started with pure fun and curiosity.

If it happens to be useful for someone by the end of the day, even better

[erwan.l]

@ erwan.l: We have a limited time in life before death,so YES, absolutely, I definitely need a good, logical reason to do something before expending my time.

 

Then dont

But dont spoil the fun for others

[Wonko the Sane]

Actually.......I had already read the entire topic before posting.

Really ? , and then you ignored what you had read and posted first thing that crossed your mind?

I was not trying to have you do anything, let alone waste your precious time, I was actually trying to make you understand how you were already wasting your time by posting something unrelated or incorrect (or both).

Hi Wonko,
 
To me, no conventional way will manage to read the file.
You need to "attack" the system using unconvential ways.

I don't see it as particularly aggressive, I am pretty much convinced that your original approach is/was too much "along the MS guidelines" to have any probability of success, but i thought that the nice thingy by joakim was "beyond" that.

After all if you can access or get a copy of the $MFT and analyze the cluster runs you should be able to get the list of the extents.

As a matter of fact I had understood that your tool was "conventional" whilst joakim's one was already "unconventional", it is possible that using one or more of his other NTFS related tools in some "specific" way the issue at hand can be easily solved, but I did a few tests and I wasn't able to make any progress worth of note.

I would rather put the blame on myself than on the tools as in some cases they are a tadbit complex to use and it is entirely possible that the tests I did were "conceptually" wrong.


Wonko

[erwan.l]

I did not look at Joakim's code but I am pretty convinced we use the same "classic" approach.

 

I could be wrong thus and if Joakim might actually be reading the MFT directly (rather than getting a handle the target file) then indeed he has more chances to succeed.

 

My approach currently is to stick to windows api but "impersonate" the system process to do the job from there.

By agressive, I mean that this approach is more likely to give one a nice BSOD

[erwan.l]

Some explanations about the why given here.

Main drive is forensic.

[Wonko the Sane]

To clarify, I can understand why someone would want to copy a locked file, but not the pagefile in particular. Is it special in this regard (for the purposes of this thread)? What about hiberfil.sys or other special system files?

Good, and to further clarify, this is EXACTLY why I doubted you had read the thread, here:
http://reboot.pro/to...sible/?p=196573
 

Revamping this thread because seemingly both erwan.l's and joakims' tools, included the updated versions on github:
https://github.com/jschicht
seemingly do not work with a subset of "in use" files (namely pagefile.sys and hiberfil.sys, possibly on new stupid Windows OS's also the stupid swapfile.sys ).
Some reference:
http://www.forensicf...wtopic/t=13653/
 
and so

[joakim]

Fix a bug in RawCopy that should let it copy pagefile's etc too. Find latest version on GitHub; https://github.com/jschicht/RawCopy

[Wonko the Sane]

Fix a bug in RawCopy that should let it copy pagefile's etc too. Find latest version on GitHub; https://github.com/jschicht/RawCopy

Just to confirm that it works fine on XP SP2/3:

C:\dummy2>rawcopy C:\pagefile.sys D:\2xOS
RawCopy v1.0.0.11

Error: NtOpenFile returned: 0xC0000043
Record number: 5 found at disk offset: 3221230592 -> 0x00000000C0001400
Record number: 86667 found at disk offset: 241425136640 -> 0x00000038360F3C00
Writing: pagefile.sys

Job took 11.93 seconds

Nice work!

 

Wonko