Re[2]: News Article: On the Fly Encryption Question

NTFSD
1

> Just to add, I’m kinda thinking if you use bit locker or anything

similar and have EVER
bug checked, your private key could be on disk somewhere unencrypted.

Or, the key might be encrypted somehow. For example Winlogon.exe
does it with passwords.

Ofcourse there is always a little chance that the key will be catched
unencrypted when dump is being written. If you would have full PDB
symbols for any particular encryption product, you probably could
display the decryption key in Windbg even.

But that’s the curse of software security, I don’t think you can do
much about it.

L.

2

Dejan Maksimovic wrote:

PF can be encrypted. In the articles it actually was.

So the page file can be encrypted. Even when a memory dump is being
written to it? From
what I understand, dumps are written to the page file on crash, then on
next reboot they
are extracted and written to your defined system32/memory.dmp location.

From what I understand to be correct, when the system is blue screening
and a dump
is being written to disk, the system uses a separate stack to write
with. Thus bypassing
everything in the original storage stack, filters, volume filters,
etc… Thus, I wouldn’t foresee
any encrypting software being here.

Matt

3

Ladislav Zezula wrote:

> Just to add, I’m kinda thinking if you use bit locker or anything
> similar and have EVER
> bug checked, your private key could be on disk somewhere unencrypted.
>

Or, the key might be encrypted somehow. For example Winlogon.exe
does it with passwords.

Ofcourse there is always a little chance that the key will be catched
unencrypted when dump is being written. If you would have full PDB
symbols for any particular encryption product, you probably could
display the decryption key in Windbg even.

But that’s the curse of software security, I don’t think you can do
much about it.

L.

Well, I’m not trying to do anything about it. Just more curious about
the technique described in the
article and how it relates to dumps being written.

Regarding other post here, I’m still not seeing how physical memory
located in RAM at the time
of crash dump generation could be encrypted as it is being written to
disk since it should be using
a stack that doesn’t have the encryption drivers loaded in it.

I’m missing something or just not expressing my thought correctly…

Matt

4

If you could get an “evil” filter onto the system, you could probably
practically automate the job:

Install the “evil” filter below the encryption filter + userland app.
Userland app sends a plaintext WRITE to a file.
Encryption filter encrypts the plaintext
“evil” filter sees the encrypted WRITE, stashes the encrypted contents,
and bugchecks the system.

Upon reboot, your userland app has the plaintext, the encrypted results,
and some “small” (bounded by the size of memory) number of possible
encryption keys to try to turn one into the other (it’s assumed that the
userland app knows the algorithm). Of course, this is assuming a
symetric cryptosystem (I recall EFS is, are others?).

If it’s a public key system, you might have to attack it on the way up
the stack on a READ. You still know the plaintext (because you wrote it
to the file initially), you get the encrypted information on the way up
the storage stack, and then you’re searching the dump for a private key
to turn encrypted into known plain instead of vice-versa.

Of course, if you can get a filter onto the system, either it’s not very
secure to start with, or you’ve fooled the user into doing something
stupid.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matt
Sent: Friday, February 22, 2008 9:17 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] News Article: On the Fly Encryption Question

Dejan Maksimovic wrote:

PF can be encrypted. In the articles it actually was.

So the page file can be encrypted. Even when a memory dump is being
written to it? From what I understand, dumps are written to the page
file on crash, then on next reboot they are extracted and written to
your defined system32/memory.dmp location.

From what I understand to be correct, when the system is blue screening
and a dump is being written to disk, the system uses a separate stack to
write with. Thus bypassing everything in the original storage stack,
filters, volume filters, etc… Thus, I wouldn’t foresee any encrypting
software being here.

Matt

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

5

Eric Diven wrote:

True, but what I’m thinking is this (re-iterate in a different way)

If the data in RAM holds the key, as the articles I posted claim, then
the key is in a decrypted
state.

If I understand correctly, when a dump is written it include the
contents of the RAM(that is decrypted).

When the crash dump that includes unencrypted data is written to disk,
the system uses a separate
stand-by stack. Therefor, the dump data being written would not pass
threw any encryption filters
on it’s way to disk.

If that is correct, then this unencrypted data will land in the page
file; therefor you should be able to
search the drive and extract info that would be pertinent to an attack.

Everyone here is in disagreement it seems, how is a crash dump with a
secure system encrypted then?

Matt

If you could get an “evil” filter onto the system, you could probably
practically automate the job:

Install the “evil” filter below the encryption filter + userland app.
Userland app sends a plaintext WRITE to a file.
Encryption filter encrypts the plaintext
“evil” filter sees the encrypted WRITE, stashes the encrypted contents,
and bugchecks the system.

Upon reboot, your userland app has the plaintext, the encrypted results,
and some “small” (bounded by the size of memory) number of possible
encryption keys to try to turn one into the other (it’s assumed that the
userland app knows the algorithm). Of course, this is assuming a
symetric cryptosystem (I recall EFS is, are others?).

If it’s a public key system, you might have to attack it on the way up
the stack on a READ. You still know the plaintext (because you wrote it
to the file initially), you get the encrypted information on the way up
the storage stack, and then you’re searching the dump for a private key
to turn encrypted into known plain instead of vice-versa.

Of course, if you can get a filter onto the system, either it’s not very
secure to start with, or you’ve fooled the user into doing something
stupid.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matt
Sent: Friday, February 22, 2008 9:17 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] News Article: On the Fly Encryption Question

Dejan Maksimovic wrote:

> PF can be encrypted. In the articles it actually was.
>
>
So the page file can be encrypted. Even when a memory dump is being
written to it? From what I understand, dumps are written to the page
file on crash, then on next reboot they are extracted and written to
your defined system32/memory.dmp location.

From what I understand to be correct, when the system is blue screening
and a dump is being written to disk, the system uses a separate stack to
write with. Thus bypassing everything in the original storage stack,
filters, volume filters, etc… Thus, I wouldn’t foresee any encrypting
software being here.

Matt

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

> Everyone here is in disagreement it seems, how is a crash dump with a

secure system encrypted then?

Almost all commercial FDE products encrypt the crash dump and hibernation
files (don’t forget about hibernate!). Prior to Vista, filters aren’t
supported in the dump stack so you needed to figure out a way to wedge
yourself into it. I’m not saying it’s pretty, but it can be done.

Vista, however, has an architected solution to support crash dump filters.
It’s entirely undocumented, but BitLicker uses it to encrypt the crash dump
and hibernation files so it’s there.

-scott

Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Matt” wrote in message news:xxxxx@ntfsd…
> Eric Diven wrote:
>
> True, but what I’m thinking is this (re-iterate in a different way)
>
> If the data in RAM holds the key, as the articles I posted claim, then the
> key is in a decrypted
> state.
>
> If I understand correctly, when a dump is written it include the contents
> of the RAM(that is decrypted).
>
> When the crash dump that includes unencrypted data is written to disk, the
> system uses a separate
> stand-by stack. Therefor, the dump data being written would not pass threw
> any encryption filters
> on it’s way to disk.
>
> If that is correct, then this unencrypted data will land in the page file;
> therefor you should be able to
> search the drive and extract info that would be pertinent to an attack.
>
> Everyone here is in disagreement it seems, how is a crash dump with a
> secure system encrypted then?
>
> Matt
>
>> If you could get an “evil” filter onto the system, you could probably
>> practically automate the job:
>>
>> Install the “evil” filter below the encryption filter + userland app.
>> Userland app sends a plaintext WRITE to a file.
>> Encryption filter encrypts the plaintext
>> “evil” filter sees the encrypted WRITE, stashes the encrypted contents,
>> and bugchecks the system.
>>
>> Upon reboot, your userland app has the plaintext, the encrypted results,
>> and some “small” (bounded by the size of memory) number of possible
>> encryption keys to try to turn one into the other (it’s assumed that the
>> userland app knows the algorithm). Of course, this is assuming a
>> symetric cryptosystem (I recall EFS is, are others?).
>>
>> If it’s a public key system, you might have to attack it on the way up
>> the stack on a READ. You still know the plaintext (because you wrote it
>> to the file initially), you get the encrypted information on the way up
>> the storage stack, and then you’re searching the dump for a private key
>> to turn encrypted into known plain instead of vice-versa.
>>
>> Of course, if you can get a filter onto the system, either it’s not very
>> secure to start with, or you’ve fooled the user into doing something
>> stupid.
>>
>> ~Eric
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Matt
>> Sent: Friday, February 22, 2008 9:17 AM
>> To: Windows File Systems Devs Interest List
>> Subject: Re: [ntfsd] News Article: On the Fly Encryption Question
>>
>> Dejan Maksimovic wrote:
>>
>>> PF can be encrypted. In the articles it actually was.
>>>
>> So the page file can be encrypted. Even when a memory dump is being
>> written to it? From what I understand, dumps are written to the page
>> file on crash, then on next reboot they are extracted and written to
>> your defined system32/memory.dmp location.
>>
>> From what I understand to be correct, when the system is blue screening
>> and a dump is being written to disk, the system uses a separate stack to
>> write with. Thus bypassing everything in the original storage stack,
>> filters, volume filters, etc… Thus, I wouldn’t foresee any encrypting
>> software being here.
>>
>> Matt
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule debugging and file system seminars (including our new
>> fs mini-filter seminar) visit: http://www.osr.com/seminars
>>
>> You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
>> unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule debugging and file system seminars
>> (including our new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
>>
>> You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
>> ‘’
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>

7

I’m suggesting this under the assumption that the key *isn’t* encrypted.
I’m just saying you could automate searching for the key in the dump
entirely on the target computer. If you’re looking for a 128 bit AES
key in 4 gigs of memory, and you don’t have any other knowledge about
where it might be or what it “looks like” (i.e. what kinds of structures
it’s stored in), it would probably be helpful to have a known plaintext
and its encrypted counterpart to start trying candidate keys against.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matt
Sent: Friday, February 22, 2008 9:54 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] News Article: On the Fly Encryption Question

Eric Diven wrote:

True, but what I’m thinking is this (re-iterate in a different way)

If the data in RAM holds the key, as the articles I posted claim, then
the key is in a decrypted state.

If I understand correctly, when a dump is written it include the
contents of the RAM(that is decrypted).

When the crash dump that includes unencrypted data is written to disk,
the system uses a separate stand-by stack. Therefor, the dump data being
written would not pass threw any encryption filters on it’s way to disk.

If that is correct, then this unencrypted data will land in the page
file; therefor you should be able to search the drive and extract info
that would be pertinent to an attack.

Everyone here is in disagreement it seems, how is a crash dump with a
secure system encrypted then?

Matt

8

If the dump file is encrypted, is it encrypted with the same key as the
user’s data? And can it be read by that user? It seems like all you
would have to do is read the dump file under normal operating conditions
on the target computer with your target user logged in.

Sorry if these are stupid questions; I’ve never tried an encryption
project.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Friday, February 22, 2008 10:00 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] News Article: On the Fly Encryption Question

Everyone here is in disagreement it seems, how is a crash dump with a
secure system encrypted then?

Almost all commercial FDE products encrypt the crash dump and
hibernation files (don’t forget about hibernate!). Prior to Vista,
filters aren’t supported in the dump stack so you needed to figure out a
way to wedge yourself into it. I’m not saying it’s pretty, but it can be
done.

Vista, however, has an architected solution to support crash dump
filters.
It’s entirely undocumented, but BitLicker uses it to encrypt the crash
dump and hibernation files so it’s there.

-scott

Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Matt” wrote in message news:xxxxx@ntfsd…
> Eric Diven wrote:
>
> True, but what I’m thinking is this (re-iterate in a different way)
>
> If the data in RAM holds the key, as the articles I posted claim, then

> the key is in a decrypted state.
>
> If I understand correctly, when a dump is written it include the
> contents of the RAM(that is decrypted).
>
> When the crash dump that includes unencrypted data is written to disk,

> the system uses a separate stand-by stack. Therefor, the dump data
> being written would not pass threw any encryption filters on it’s way
> to disk.
>
> If that is correct, then this unencrypted data will land in the page
> file; therefor you should be able to search the drive and extract info

> that would be pertinent to an attack.
>
> Everyone here is in disagreement it seems, how is a crash dump with a
> secure system encrypted then?
>
> Matt
>
>> If you could get an “evil” filter onto the system, you could probably

>> practically automate the job:
>>
>> Install the “evil” filter below the encryption filter + userland app.
>> Userland app sends a plaintext WRITE to a file.
>> Encryption filter encrypts the plaintext “evil” filter sees the
>> encrypted WRITE, stashes the encrypted contents, and bugchecks the
>> system.
>>
>> Upon reboot, your userland app has the plaintext, the encrypted
>> results, and some “small” (bounded by the size of memory) number of
>> possible encryption keys to try to turn one into the other (it’s
>> assumed that the userland app knows the algorithm). Of course, this
>> is assuming a symetric cryptosystem (I recall EFS is, are others?).
>>
>> If it’s a public key system, you might have to attack it on the way
>> up the stack on a READ. You still know the plaintext (because you
>> wrote it to the file initially), you get the encrypted information on

>> the way up the storage stack, and then you’re searching the dump for
>> a private key to turn encrypted into known plain instead of
vice-versa.
>>
>> Of course, if you can get a filter onto the system, either it’s not
>> very secure to start with, or you’ve fooled the user into doing
>> something stupid.
>>
>> ~Eric
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Matt
>> Sent: Friday, February 22, 2008 9:17 AM
>> To: Windows File Systems Devs Interest List
>> Subject: Re: [ntfsd] News Article: On the Fly Encryption Question
>>
>> Dejan Maksimovic wrote:
>>
>>> PF can be encrypted. In the articles it actually was.
>>>
>> So the page file can be encrypted. Even when a memory dump is being
>> written to it? From what I understand, dumps are written to the page
>> file on crash, then on next reboot they are extracted and written to
>> your defined system32/memory.dmp location.
>>
>> From what I understand to be correct, when the system is blue
>> screening and a dump is being written to disk, the system uses a
>> separate stack to write with. Thus bypassing everything in the
>> original storage stack, filters, volume filters, etc… Thus, I
>> wouldn’t foresee any encrypting software being here.
>>
>> Matt
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule debugging and file system seminars (including our
>> new fs mini-filter seminar) visit: http://www.osr.com/seminars
>>
>> You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
>> unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule debugging and file system seminars (including our
>> new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
>>
>> You are currently subscribed to ntfsd as: unknown lmsubst tag
argument:
>> ‘’
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>>
>>
>
>

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

9

Scott Noone wrote:

> Everyone here is in disagreement it seems, how is a crash dump with a
> secure system encrypted then?
>

Almost all commercial FDE products encrypt the crash dump and hibernation
files (don’t forget about hibernate!). Prior to Vista, filters aren’t
supported in the dump stack so you needed to figure out a way to wedge
yourself into it. I’m not saying it’s pretty, but it can be done.

Well, I learn something new everyday. I didn’t know Vista would allow
this, however, on older systems
you say this is possible - I assume the only way possible is
hooking/patching…

Vista, however, has an architected solution to support crash dump filters.
It’s entirely undocumented, but BitLicker uses it to encrypt the crash dump
and hibernation files so it’s there.

I see, Bit Locker uses it but it’s undocumented. Should I assume all
other encryption drivers are vulnerable
then?

-scott
Thanks for your response, yours is the first that has made sense.

Matt

10

I think that only administrators and system get access to memory.dmp by
default, so if you’re properly utilizing the security mechanisms built into
Windows you should be OK (and people who want their data encrypted are
usually paranoid enough to follow best practices (we hope)).

But, of course, if you can coerce a privileged user into running arbitrary
code on the system there are much easier ways to scan memory than getting
the system to crash and then reading the dump file.

-scott

Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Eric Diven” wrote in message news:xxxxx@ntfsd…
If the dump file is encrypted, is it encrypted with the same key as the
user’s data? And can it be read by that user? It seems like all you
would have to do is read the dump file under normal operating conditions
on the target computer with your target user logged in.

Sorry if these are stupid questions; I’ve never tried an encryption
project.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Friday, February 22, 2008 10:00 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] News Article: On the Fly Encryption Question

> Everyone here is in disagreement it seems, how is a crash dump with a
> secure system encrypted then?

Almost all commercial FDE products encrypt the crash dump and
hibernation files (don’t forget about hibernate!). Prior to Vista,
filters aren’t supported in the dump stack so you needed to figure out a
way to wedge yourself into it. I’m not saying it’s pretty, but it can be
done.

Vista, however, has an architected solution to support crash dump
filters.
It’s entirely undocumented, but BitLicker uses it to encrypt the crash
dump and hibernation files so it’s there.

-scott

Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Matt” wrote in message news:xxxxx@ntfsd…
> Eric Diven wrote:
>
> True, but what I’m thinking is this (re-iterate in a different way)
>
> If the data in RAM holds the key, as the articles I posted claim, then

> the key is in a decrypted state.
>
> If I understand correctly, when a dump is written it include the
> contents of the RAM(that is decrypted).
>
> When the crash dump that includes unencrypted data is written to disk,

> the system uses a separate stand-by stack. Therefor, the dump data
> being written would not pass threw any encryption filters on it’s way
> to disk.
>
> If that is correct, then this unencrypted data will land in the page
> file; therefor you should be able to search the drive and extract info

> that would be pertinent to an attack.
>
> Everyone here is in disagreement it seems, how is a crash dump with a
> secure system encrypted then?
>
> Matt
>
>> If you could get an “evil” filter onto the system, you could probably

>> practically automate the job:
>>
>> Install the “evil” filter below the encryption filter + userland app.
>> Userland app sends a plaintext WRITE to a file.
>> Encryption filter encrypts the plaintext “evil” filter sees the
>> encrypted WRITE, stashes the encrypted contents, and bugchecks the
>> system.
>>
>> Upon reboot, your userland app has the plaintext, the encrypted
>> results, and some “small” (bounded by the size of memory) number of
>> possible encryption keys to try to turn one into the other (it’s
>> assumed that the userland app knows the algorithm). Of course, this
>> is assuming a symetric cryptosystem (I recall EFS is, are others?).
>>
>> If it’s a public key system, you might have to attack it on the way
>> up the stack on a READ. You still know the plaintext (because you
>> wrote it to the file initially), you get the encrypted information on

>> the way up the storage stack, and then you’re searching the dump for
>> a private key to turn encrypted into known plain instead of
vice-versa.
>>
>> Of course, if you can get a filter onto the system, either it’s not
>> very secure to start with, or you’ve fooled the user into doing
>> something stupid.
>>
>> ~Eric
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Matt
>> Sent: Friday, February 22, 2008 9:17 AM
>> To: Windows File Systems Devs Interest List
>> Subject: Re: [ntfsd] News Article: On the Fly Encryption Question
>>
>> Dejan Maksimovic wrote:
>>
>>> PF can be encrypted. In the articles it actually was.
>>>
>> So the page file can be encrypted. Even when a memory dump is being
>> written to it? From what I understand, dumps are written to the page
>> file on crash, then on next reboot they are extracted and written to
>> your defined system32/memory.dmp location.
>>
>> From what I understand to be correct, when the system is blue
>> screening and a dump is being written to disk, the system uses a
>> separate stack to write with. Thus bypassing everything in the
>> original storage stack, filters, volume filters, etc… Thus, I
>> wouldn’t foresee any encrypting software being here.
>>
>> Matt
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule debugging and file system seminars (including our
>> new fs mini-filter seminar) visit: http://www.osr.com/seminars
>>
>> You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
>> unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule debugging and file system seminars (including our
>> new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
>>
>> You are currently subscribed to ntfsd as: unknown lmsubst tag
argument:
>> ‘’
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>>
>>
>
>

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

11

> I assume the only way possible is hooking/patching…

You got it.

I see, Bit Locker uses it but it’s undocumented. Should I assume all other
encryption drivers are vulnerable
then?

I would seriously doubt that to be the case. They figured out a way to do it
pre-Vista and they’ll figure out a way to do it in Vista, either by using
the old techniques or leveraging the built in support.

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Matt” wrote in message news:xxxxx@ntfsd…
> Scott Noone wrote:
>>> Everyone here is in disagreement it seems, how is a crash dump with a
>>> secure system encrypted then?
>>>
>>
>> Almost all commercial FDE products encrypt the crash dump and hibernation
>> files (don’t forget about hibernate!). Prior to Vista, filters aren’t
>> supported in the dump stack so you needed to figure out a way to wedge
>> yourself into it. I’m not saying it’s pretty, but it can be done.
>>
> Well, I learn something new everyday. I didn’t know Vista would allow
> this, however, on older systems
> you say this is possible - I assume the only way possible is
> hooking/patching…
>> Vista, however, has an architected solution to support crash dump
>> filters. It’s entirely undocumented, but BitLicker uses it to encrypt the
>> crash dump and hibernation files so it’s there.
>>
> I see, Bit Locker uses it but it’s undocumented. Should I assume all other
> encryption drivers are vulnerable
> then?
>> -scott
> Thanks for your response, yours is the first that has made sense.
>
> Matt
>

12

Since I don’t work for them, I will add a plug for the Seagate FDE drives
where the encryption is done in the drive’s chipset. No key in main
computer memory to obtain access via the memory and freon trick.

“Scott Noone” wrote in message news:xxxxx@ntfsd…
>I think that only administrators and system get access to memory.dmp by
>default, so if you’re properly utilizing the security mechanisms built into
>Windows you should be OK (and people who want their data encrypted are
>usually paranoid enough to follow best practices (we hope)).
>
> But, of course, if you can coerce a privileged user into running arbitrary
> code on the system there are much easier ways to scan memory than getting
> the system to crash and then reading the dump file.
>
> -scott
>
> Scott Noone
> Software Engineer
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
> “Eric Diven” wrote in message
> news:xxxxx@ntfsd…
> If the dump file is encrypted, is it encrypted with the same key as the
> user’s data? And can it be read by that user? It seems like all you
> would have to do is read the dump file under normal operating conditions
> on the target computer with your target user logged in.
>
> Sorry if these are stupid questions; I’ve never tried an encryption
> project.
>
> ~Eric
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
> Sent: Friday, February 22, 2008 10:00 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] News Article: On the Fly Encryption Question
>
>> Everyone here is in disagreement it seems, how is a crash dump with a
>> secure system encrypted then?
>
> Almost all commercial FDE products encrypt the crash dump and
> hibernation files (don’t forget about hibernate!). Prior to Vista,
> filters aren’t supported in the dump stack so you needed to figure out a
> way to wedge yourself into it. I’m not saying it’s pretty, but it can be
> done.
>
> Vista, however, has an architected solution to support crash dump
> filters.
> It’s entirely undocumented, but BitLicker uses it to encrypt the crash
> dump and hibernation files so it’s there.
>
> -scott
>
> Scott Noone
> Software Engineer
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
> “Matt” wrote in message news:xxxxx@ntfsd…
>> Eric Diven wrote:
>>
>> True, but what I’m thinking is this (re-iterate in a different way)
>>
>> If the data in RAM holds the key, as the articles I posted claim, then
>
>> the key is in a decrypted state.
>>
>> If I understand correctly, when a dump is written it include the
>> contents of the RAM(that is decrypted).
>>
>> When the crash dump that includes unencrypted data is written to disk,
>
>> the system uses a separate stand-by stack. Therefor, the dump data
>> being written would not pass threw any encryption filters on it’s way
>> to disk.
>>
>> If that is correct, then this unencrypted data will land in the page
>> file; therefor you should be able to search the drive and extract info
>
>> that would be pertinent to an attack.
>>
>> Everyone here is in disagreement it seems, how is a crash dump with a
>> secure system encrypted then?
>>
>> Matt
>>
>>> If you could get an “evil” filter onto the system, you could probably
>
>>> practically automate the job:
>>>
>>> Install the “evil” filter below the encryption filter + userland app.
>>> Userland app sends a plaintext WRITE to a file.
>>> Encryption filter encrypts the plaintext “evil” filter sees the
>>> encrypted WRITE, stashes the encrypted contents, and bugchecks the
>>> system.
>>>
>>> Upon reboot, your userland app has the plaintext, the encrypted
>>> results, and some “small” (bounded by the size of memory) number of
>>> possible encryption keys to try to turn one into the other (it’s
>>> assumed that the userland app knows the algorithm). Of course, this
>>> is assuming a symetric cryptosystem (I recall EFS is, are others?).
>>>
>>> If it’s a public key system, you might have to attack it on the way
>>> up the stack on a READ. You still know the plaintext (because you
>>> wrote it to the file initially), you get the encrypted information on
>
>>> the way up the storage stack, and then you’re searching the dump for
>>> a private key to turn encrypted into known plain instead of
> vice-versa.
>>>
>>> Of course, if you can get a filter onto the system, either it’s not
>>> very secure to start with, or you’ve fooled the user into doing
>>> something stupid.
>>>
>>> ~Eric
>>>
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of Matt
>>> Sent: Friday, February 22, 2008 9:17 AM
>>> To: Windows File Systems Devs Interest List
>>> Subject: Re: [ntfsd] News Article: On the Fly Encryption Question
>>>
>>> Dejan Maksimovic wrote:
>>>
>>>> PF can be encrypted. In the articles it actually was.
>>>>
>>> So the page file can be encrypted. Even when a memory dump is being
>>> written to it? From what I understand, dumps are written to the page
>>> file on crash, then on next reboot they are extracted and written to
>>> your defined system32/memory.dmp location.
>>>
>>> From what I understand to be correct, when the system is blue
>>> screening and a dump is being written to disk, the system uses a
>>> separate stack to write with. Thus bypassing everything in the
>>> original storage stack, filters, volume filters, etc… Thus, I
>>> wouldn’t foresee any encrypting software being here.
>>>
>>> Matt
>>>
>>>
>>> —
>>> NTFSD is sponsored by OSR
>>>
>>> For our schedule debugging and file system seminars (including our
>>> new fs mini-filter seminar) visit: http://www.osr.com/seminars
>>>
>>> You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
>>> unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>> —
>>> NTFSD is sponsored by OSR
>>>
>>> For our schedule debugging and file system seminars (including our
>>> new fs mini-filter seminar) visit:
>>> http://www.osr.com/seminars
>>>
>>> You are currently subscribed to ntfsd as: unknown lmsubst tag
> argument:
>>> ‘’
>>> To unsubscribe send a blank email to
>>> xxxxx@lists.osr.com
>>>
>>>
>>
>>
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars (including our new
> fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>