Fake "proxy" driver to be able to sandbox HKLM\SYS

[a_Lex]

Having kernell drivers is crucial for TrueCrypt.
So feature suggestions that would enable sandboxie to "trap" and contain kernel drivers and HKLM\SYSTEM entries are now discussed in TC's forum.

Me and David Xanathos have an idea:

A sandboxie kernell-level "proxy driver" that would plug itself between the sandboxed program's driver and the host OS, so that the sandboxed program would communicate with sandbox "believing" it to be the system (the captive program's HKLM\SYSTEM are also contained whithin sandbox), while the "proxy" driver would do what the sandboxed driver would normaly do so that the sandboxed program can operate normaly, thus acting as a sort of "kernell level representative" of the sandboxed driver.

[street011]

would be lovely!

[tzuk]

Will not happen. Sorry I have to be the rain on your parade, a_lex.

[OwenBurnett]

@tzuk
Is such a feature even possible, I mean Technically?
Or is this just to much afford for to less benefits?

@a_Lex
I'm using TC to and I know what you want achieve but don't you think an Adversary may find the storage device on what the TC binary's are stored?
You also would have to have an excuse why you have unformatted junk partition or suspect 100 GB large trash files.
Or are you planing to have your TC Volumes on the same media as the binary's? But than you are safe off having TC on your system some semilegal volume with you MP3's (you know mp3's are Illegal ), any your real volume on a device that you destroys when someone knocks on the door.

Anyway using TC's hidden volumes gives in my opinion the better deniability.


Owen

[tzuk]

It may be technically possible but it doesn't fit the design of Sandboxie anymore.

In other words it is no longer possible for Sandboxie to redirect the kernel mode access to the registry, which happens as part of the NtLoadDriver call to load a driver.

But it should be possible for someone to write such a "proxy" driver that hooks registry access through SSDT (which Sandboxie no longer does) and thus be able to redirect the kernel mode access to some "made up" (possibly RAM only) key that describes TrueCrypt or any other driver.

[a_lex]

tzuk

Will not happen. Sorry I have to be the rain on your parade, a_lex.

Well, so be it.

In other words it is no longer possible for Sandboxie to redirect the kernel mode access to the registry, which happens as part of the NtLoadDriver call to load a driver.

No longer... and what was the last version which had this feature? Just curious.

OwenBurnett

You also would have to have an excuse why you have unformatted junk partition

Eraser. DBAN.

[OwenBurnett]

Doesn't DBAN have an pass with "0" on the end that cant be turned of in the regular build?

Owen

[a_Lex]

Well, as far as I remember, the latest version can fill the volume with "good" random data only.

[tzuk]

No longer... and what was the last version which had this feature? Just curious.

2.64. But even that version would not try to "sandbox" (redirect, isolate, whatever) access initiated by system code, and furthermore, it blocks calls to NtLoadDriver. So it's a dead end for you, I'm afraid.

By the way, have you considered just deleting the TrueCrypt driver registry key?

[a_lex]

2.64. But even that version would not try to "sandbox" (redirect, isolate, whatever) access initiated by system code, and furthermore, it blocks calls to NtLoadDriver. So it's a dead end for you, I'm afraid.

Okay.

By the way, have you considered just deleting the TrueCrypt driver registry key?

Well, in paranoid scenarios that involve concealing the very use of True Crypt (and that registry key too), you must not only delete the registry key, but also make sure it is not recoverable through typical disk-analysis suites, and, as far as I understand registry keys, to make pretty sure no trace of a deleted key is left, you have to defragment the registry and do a "free space erase" (Eraser).

Paranoia is a sweet game

[tzuk]

The spy who would find themselves in such a scenario, should get a self-encrypting USB drive, preferably from someone nicknamed Q.

[gogoland2002]

In other words it is no longer possible for Sandboxie to redirect the kernel mode access to the registry, which happens as part of the NtLoadDriver call to load a driver.

sorry, i'm a newb to this kernel-stuff. could someone explain to me in a few words what this means to me as a user? does this mean sandboxie-run programs now leave traces on my system-registry? if so, what kinda programs? thank you!

[OwenBurnett]

It means that programs whitch needs to install drivers would leav traces in your system, but note that by default installing of drivers is prochibited to sandboxed programs.

Owen

[gogoland2002]

thanks, OwenBurnett.