Why we can not apply Transparent encryption and decryption in ring3 layer

Dear all:
I’ve been thinking about this idea for a long time, and I want to discuss it with you in the forum.
I am a user of FESF, but in some very special scenarios our customers want to provide an ring3 solution to replace FESF.Because in these scenarios the computer may not be able to install the driver or restart.
I know this is a very old scheme, when transparent encryption and decryption first appeared.Many developer hope to implement this system by hooking functions(zwcreatefile/zwreadfile/zwwritefile …).The biggest difficulty in implementing this system at the ring3 in the how to management of mapped memory(ZwMapViewOfSection etc…) .
My opinion is if progream open encryptfile I will read the file ahead of time and put it in memory after fully decrypting it.After that, all operations of the process on the file can be redirected to the decrypted buffer of the memory.I will regularly re-encrypt the decrypted buffer and write it back to the file.
This is similar to redirecting the process’s file access on disk to file access in memory.
The problem I can think of is that large files may freeze when write back to disk.But I don’t know if there are any other questions, I hope you can discuss with me

Hi, Jehoshua_J! You asked:


in some very special scenarios our customers want to provide an ring3 solution to replace FESF

Many developer hope to implement this system by hooking functions

But I don’t know if there are any other questions, I hope you can discuss with me



One of the biggest problem of API hooking solutions is compatibility with system components and third-party software.
In order to be fully transparent, your encryption engine must be loaded into every process in the system. Unfortunately, this is not 100% possible.
Latest Windows releases have rich set of protected and isolated components: protected processes, UWP-processes (aka AppContainers), low-integrity
processes, restricted services or job objects, processes with certain mitigation policies enabled, HVCI-isolated processes (example: LsaISO), etc.
In general it is quite difficult (or even impossible) to load your dll into such processes or make it work properly.


Moreover, some software including popular products like Microsoft Office also uses API hooking. Double API hooks? Hmm… This often leads to
“strange” problems that are hard to diagnose. And I haven’t even started writing about memory-mapped I/O :slight_smile: