x86asm.net

[feryno]

Hi guys,

more than 1 year ago, I was thinking about this new kind of antidebug based on virtualization
I didn't develop it further because I had to break and solve different problems, but I did a working sample and some screenshots of such protection in action

http://feryno.host.sk/virtadbg0000.html

I would like to read/hear your criticism, opinions, thoughts which are necessary to improve this new kind of antidebug.
- whether it is viable, the performace looked OK, but I didn't exact measuring by e.g. CPU tick counters, I approximate every hypervisor "intervention" (that is vm exit from guest OS into host hypervisor + memory encryption/decryption + vm entry from host hypervisor into guest OS) at about 5000 CPU cycles at my developping CPU
- whether you can imagine another possible attacks to break this protection

I can't post the code either binaries (deed of confidentiality), but I can freely share this idea (company wasn't interested in that usage of hypervisor)

screenshots show 2 protected memory pages - 1 page holding code and 1 page holding data
when memory page holding code (instructions to execute) is protected, any alien process may see only encrypted data so then debugger (as example of alien process) is able to single step through such code correctly, but is not able to correctly disassemble instructions - which is suitable as antidebug

[tomtobias]

[feryno]

I'm also critical for every type of antidebug because everything may be broken/defeated at the end.
I have only some kind of entusiasm because I have never heard about antidebugs based on virtualization. Perhaps there are already available, but I don't know anything about such antidebug.
The article describes a method of encrypting/decrypting memory pages using virtualization as guest OS switches tasks. Alien task is loaded - pages are encrypted by hypervisor. The task owning protected pages is loaded - pages are decrypted by hypervisor.
Typical multitasking OS-es use CR3 register for isolating processes virtual memory. The article describes points in microsof windows AMD64 kernel where to intercept CR3 changes and what to do at instructions changing the CR3 register during switching tasks and during reading/writing memory pages of a process from an alien process.
So if you are e.g. using debugger to inspect protected pages, you see them only in encrypted state. Instruction pointer changes normally if you single step code in such page but you can't read the instructions because they are encrytpted when debugger reads protected page. Instructions are decrypted only when owner process executes the code (normal execution or also single stepping).
I'll prepare some practical live interactive presentation showing how does it look. Perhaps it is good topic for next FASM tech conference (I forgot to demonstrate that at FASM con 2009, because I was playing with that half a year before FASM con 2009 and my mind was full of another problems to solve, I remembered that 1-2 months ago thanks to one of my friends who asked me for some antidebugs).
The method doesn't require (U)EFI, it requires only AMD64 / Intel EM64T CPU with virtualization + running close source operating system (as amd64 version of ms windows).
Under open source OS you can implement that method by editing source code and recompiling kernel (like Linux kernel). For a close source OS you can comfortable use CPU virtualization technique to implementing that.

P.S.
The article is not so well written, only bare thoughts, no details at some steps. Perhaps it is necessary to read it more times or to ask me questions about some 'dark parts'.

[feryno]

I added some pictures to the article so now it may be easier to understand and imagine the protection
the protection is based on switching tasks and hypervisor in the very first and simplified approach watches only CR3 of processes whether the CR3 matches (CR3 update in SwapContext in MS windows OS) or not and then decrypts/encrypts protected memory of the process according the matching/mismatching CR3 of the process
so the memory is decrypted only when any thread of the process owning the virtual memory and having the matchnig CR3 is executing
the memory is encrypted when any thread of alien process is executing (mismatching CR3 detected by hypervisor in SwapContext)
it is possible to protect memory containing code / data / stack
if code is protected, you can't see correct instructions, even the first instruction to execute is encrypted, you can although normally single step through that code, RIP changes normally, the only invisible things are instructions

the very first and simplified approach required further improvement because of attack vulnerability running in SMP - everything is described in the updated article including some pictures

I had to upload the article to the new location (unable to reach the previously uploaded from current net because of strong filtering applied here on firewall)
http://feryno.host.sk/virtadbg0000.html
I edited the link in the first post in this thread also

[tomtobias]

Thank you very much Feryno.

Your chart is well written, and well designed. It serves as an excellent introduction.

[feryno]

thread is fully in context when instructions of thread are executed at CPU

thread usually leaves context at an external interrupt (e.g. timer interrupt), an INT instruction, SYSCALL instruction

OS kernel then saves all registers of thread and CR3 of the process owning the thread

then OS decides whether there is a time to load new thread into context or whether resume the old thread

when loading new thread into context, OS kernel (ring0) loads at first CR3 of process where the new thread belongs, then registers of the new thread and then passes CPU execution to the thread so thread starts to run

the final instruction which leaves kernel and passes control to ring3 thread is usually IRETQ or SYSRETQ (OS running in long mode)
the IRETQ is executed from ring0 when the ring3 thread was interrupted by an external interrupt or when it executed the INT instruction (OS in long mode)
the SYSRETQ is executed from ring0 when the ring3 thread called a kernel by the SYSCALL instruction (OS running in long mode)

for passing control from kernel to ring0 thread it is enough to do e.g. the RET instruction

yes, context is verified by matching CR3 in the first design
for protecting against RemoteThread attack, other matching sign is required - "something" specific for thread because CR3 of more threads of one process have the same CR3 as they share the same virtual memory space

but verifying only CR3 at any place is not enough, it is valid only when verifying CR3 when loading it in SwapContext (windows kernel)
CR3 is also loaded in clones of AttachProcess (windows kernel) like a result of ring3 calling of kernel32.ReadProcessMemory / kernel32.WriteProcessMemory - in this situation, there is an alien thread in context, CR3 is loaded only temporary to read/write from/into virtual memory of another process into/from kernel memory buffer and then the CR3 is unloaded and orignal CR3 is restored - DetachProcess clones under windows kernel - in this scenario, CR3 may temporary match, but there is an alien thread in context, this is the reason that exactly SwapContext (windows kernel) procedure must be detected by hypervisor



I still don't know whether such protection is viable, I expect that somebody may post some attack against which there is no protection. I posted some ideas of attacks but I was still able to find a way how to protect against them so the designed protection of virtual memory appears still viable for me.

[feryno]

I made a video about this protection
http://img441.imageshack.us/img441/4774/hypervisormemoryprotect.mp4

in the first debugger session the protection is not active, the demo application calculates factorial of 4 using stack and puts the result as thread exit code 18h

in the second debugger session, the protection by hypervisor is active and 1 page of stack and and 1 page of code is protected

sorry, cannot made the video better yet (quality is very poor although the size is almost 8 MB)

I'll plane to demonstrate that protection live at the feature FASM conference 2010, September, Myjava, Slovak republic. I'll plane to demonstrate also 2 another tasks of hypervisor - memory analysis tool (virt. mem as well physical mem dumping after stopping necessary threads using pure hypervisor techniques - without windows APIs) + ring 3 executables debugger based on hypervisor (it looks like fdbg but calls purely hypervisor instead of windows debug / memory APIs)[/url]

[tomtobias]

Thanks, Feryno, very promising!

Looking forward to your presentation at FASMcon10


tom