> > Well, BG 1.0 Free Demo (http://www.immunitysec.com/bodyguard.html) does > do the dereference. E.G. It checks the system call code itself, not the > sysent32 table. So theoretically adding exece to BodyGuard's checksum > table _would_ catch this method, at least for the moment. :> (I'll try > this later today to make sure.) Did you check to see if you could do the > same trick to stat64? yes, you are right. I have a misunderstanding on the checksum issue and it makes a lot of sense and is a good idea to do checksum on the function level. Still the fundamental problem is bodyguard is also trusting a subverted kernel, this means that any internal kernel function is being used by bodyguard could be changed in a way that it will detect bodyguards existence and feed false information or even change bodyguard itself ... for example ddi_enter_critical or mod_install can be hooked in away that it will do a kobj_getsymvalue() one or more exported symbols of bodyguard (myverify, md5_XXXXXX, verify_syscalls...) and if the symbol/s resolve it will patch that function with a "return TRUE" instruction ... ;-) ofcourse patching must be done at the entry point somewhere, most likely the first instruction .... primary_inhouse_kernel_function_used_by_bodyguard() { ..... if(kobj_getsymvalue(verify_syscalls,1)){ do page protection manipulation patch the proper place with "return TRUE" of the verify_syscalls() !! this will make verify_syscalls return TRUE meaning no problems } .... do the realstuff ... } this will render any kernel integrity level checker useless. solution is simple integrity checkers have to be stealh to like their counterparts (backdoors) > spend in the game - something they didn't have until Monday :>. yes, this is indeed a good product but needs stealthness like the kernel level backdoors. > 2. slightly different executables for each customer sounds promissing, this must be the main motive! later, noir
