Tiza Posted December 3, 2016 Report Posted December 3, 2016 After a careful examination of turla from this source code https://github.com/hfiref0x/TDL i got to understand that basically, its a loader whos sole responsibiity is to unload the Virtualbox driver and load the vulnerable one but where i got the issue is that i dont get to see how the programmer was able to load the dummy.sys into the x64 system, i started to think if it was the shellcode which was to be built into the dummy.sys so that as soon as it loads the vulnerable virtualbox .sys it loads the dummy.sys as well.... any ideas. I got lost along the line , i understand the vulnerable virtualbox was called from resource and they unloaded the one already installed on the system , and loaded the vulnerable one... then building the exploit.. thats where i got lost. is the exploit meant to be the dummy.sys.. thats what i need to get... a form of clarification Quote
Nytro Posted December 4, 2016 Report Posted December 4, 2016 I checked the code (not really in detail) and it looks like this: - It unloads the VirtualBox driver if it is already running - It loads a vulnerable VirtualBox driver -> WHICH IS SIGNED AND ALLOWED TO RUN (if you Download this https://github.com/hfiref0x/TDL/blob/master/Source/Furutaka/drv/vboxdrv_exploitable.sys and check it's properties you can see this) - Exploit a vulnerability in the vulnerable driver - Execute a shellcode in the kernel-context -> Here you are able to load (minimal) another kernel module This is the bypass of the "Driver Signature Enforcement" avoiding the PatchGuard (as DSEFix would trigger). I am not really sure what I say is true, if I will have some time, I will take a more detailed look. Quote
