I am trying to debug kernel in remote debugging using vmware and windbg.I have connected to target machine .My driver name is comint32.I have started the service of my driver in target machine .I want to view the dbgprint of my driver.Whenever I try to use break point I got an error “couldn’t resolve error at ‘comint32!DriverEntry’”.This is the current status windbg output:
kd> x*!
start end module name
80bd1000 80bd9000 kdcom (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\kdcom.pdb\F48BD9BC030C43D89689518F892586901\kdcom.pdb
82812000 82849000 hal (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\halmacpi.pdb\AE605D6C59454802AE1D485E0B089A571\halmacpi.pdb
82849000 82c5b000 nt (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\ntkrpamp.pdb\684DA42A30CC450F81C535B4D18944B12\ntkrpamp.pdb
82e09000 82e8e000 mcupdate_GenuineIntel (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\mcupdate_GenuineIntel.pdb\26689A9400E04CF6AD63DC2E608DAA9C1\mcupdate_GenuineIntel.pdb
82e8e000 82e9f000 PSHED (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\pshed.pdb\5ACEAFD8AD3A46FEAD083AFDF675DA391\pshed.pdb
82e9f000 82ea7000 BOOTVID (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\bootvid.pdb\10C3ABD4165D4ED3A9493BB094B44AEA1\bootvid.pdb
82ea7000 82ee9000 CLFS (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\clfs.pdb\04F22EAC7BD04A1BA81A6FB5D319649F1\clfs.pdb
82ee9000 82f94000 CI (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\ci.pdb\3358E6E48A5245F6AB97EA05356E020F1\ci.pdb
82f94000 82fdf000 volmgrx (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\volmgrx.pdb\433F00DD3CC34DE8BC3F9E4BDDACA5EE1\volmgrx.pdb
82fdf000 82fed000 PCIIDEX (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\pciidex.pdb\8B7BC6201128486CB5B03916EBD5FF8E1\pciidex.pdb
83800000 83807000 intelide (no symbols)
8380a000 8387cd00 dsfksvcs (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\dsfksvcs.pdb\EE67C173CB4C4B31BA3806038D42B3C01\dsfksvcs.pdb
8387d000 838b8500 DSFOleaut32 (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\DSFOleaut32.pdb\F02C6A23966243E1B10F05EB634A88331\DSFOleaut32.pdb
838b9000 8392a000 Wdf01000 (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\Wdf01000.pdb\A9E46808F4F748178D3071AA9EE76FB71\Wdf01000.pdb
8392a000 83938000 WDFLDR (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\wdfldr.pdb\95D9DB57778548E6B6774520468479891\wdfldr.pdb
83938000 83980000 ACPI (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\acpi.pdb\E7300A0CC3524834A4E1E55773C1901E1\acpi.pdb
83980000 83989000 WMILIB (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\wmilib.pdb\F52B38A4800849D48BFFD48715A446A51\wmilib.pdb
83989000 83991000 msisadrv (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\msisadrv.pdb\5D6926DA4AD1474BAE8CBDA5909F68201\msisadrv.pdb
83991000 839bb000 pci (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\pci.pdb\2E2A912260694615A7E97AFBA3FA934E1\pci.pdb
839bb000 839c6000 vdrvroot (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\vdrvroot.pdb\3C9D6939EF564015B8D0728611C88C221\vdrvroot.pdb
839c6000 839d7000 partmgr (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\partmgr.pdb\7CA861FF7879483ABA38CE28186F293E2\partmgr.pdb
839d7000 839df000 compbatt (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\compbatt.pdb\EE14F03B54BF49B4B62A0EF912A59C8F1\compbatt.pdb
839df000 839ea000 BATTC (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\battc.pdb\53C47BEA2F08470BB58DFD1566285EC71\battc.pdb
839ea000 839fa000 volmgr (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\volmgr.pdb\4AF04B598C494297B1C69F95823AA9F81\volmgr.pdb
83a24000 83a3a000 mountmgr (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\mountmgr.pdb\356DDF9839E040638E034EEA956C28F81\mountmgr.pdb
83a3a000 83a43000 atapi (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\atapi.pdb\EF544461A5D5482980C2CA01640A6D621\atapi.pdb
83a43000 83a66000 ataport (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\ataport.pdb\C9AF9FE9166548FD86EFAC017F6023011\ataport.pdb
83a66000 83a7e000 lsi_sas (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\lsi_sas.pdb\FCC2DAF36299423A9765B62D750A97461\lsi_sas.pdb
83a7e000 83ac6000 storport (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\storport.pdb\E19FF676062D46A69EB1BB6A916896172\storport.pdb
83ac6000 83acf000 amdxata (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\amdxata.pdb\5E66F230920844408A1EE389D50B6B4A1\amdxata.pdb
83acf000 83b03000 fltmgr (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\fltMgr.pdb\E6CA9E082E70438988788CB58DB340B01\fltMgr.pdb
83b03000 83b14000 fileinfo (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\fileinfo.pdb\EBD1E885413A4242AA515F1B06BB564F1\fileinfo.pdb
83b14000 83bcb000 ndis (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\ndis.pdb\4DAAA54E2C26455DB2471D696BC8E6A62\ndis.pdb
83bcb000 83bfc000 fwpkclnt (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\fwpkclnt.pdb\FDE8223F22C54AEA8061EE56EA16A0251\fwpkclnt.pdb
88c00000 88c0e000 pcw (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\pcw.pdb\D368300F340A423EBBA32FBDDDEC24B91\pcw.pdb
88c0e000 88c17000 Fs_Rec (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\fs_rec.pdb\3465ED05A901452FAD07E77351F094591\fs_rec.pdb
88c2b000 88d5a000 Ntfs (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\ntfs.pdb\04B176C327B240F7A576F3417A7B95032\ntfs.pdb
88d5a000 88d85000 msrpc (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\msrpc.pdb\B4C428CFD1024C43BD3E2B10D1A8F0711\msrpc.pdb
88d85000 88d98000 ksecdd (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\ksecdd.pdb\E84CBB7448354030A32188581CC8B37A1\ksecdd.pdb
88d98000 88df5000 cng (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\cng.pdb\3F94705B83A0481DA755FA6A70729BDE1\cng.pdb
88df5000 88dfb000 comint32 (no symbols)
88e25000 88e63000 NETIO (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\netio.pdb\7A33726ABE884384BFDFB951F05D13AC2\netio.pdb
88e63000 88e88000 ksecpkg (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\ksecpkg.pdb\3D42090DFF4E4D55985F577277A3B1E91\ksecpkg.pdb
88e88000 88fd2000 tcpip (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\tcpip.pdb\0FD6F17209C1481C9008CCDB468746392\tcpip.pdb
88fd2000 88fd7580 dsfroot (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\dsfroot.pdb\95EE5096213948909946E4333289A97F1\dsfroot.pdb
88fd8000 88fe0380 vmstorfl (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\vmstorfl.pdb\D7FD176CC0134139B2EE4BEAF352AEE41\vmstorfl.pdb
89032000 89071000 volsnap (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\volsnap.pdb\1F66E7165E8F4BD982A34A9DFA1BBFD31\volsnap.pdb
89071000 89079000 spldr (no symbols)
89079000 890a6000 rdyboost (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\rdyboost.pdb\53BB42ABE1404332962CA2AEA8301D331\rdyboost.pdb
890a6000 890b6000 mup (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\mup.pdb\E96F69551E2447289250F71FB5AB6E0C2\mup.pdb
890b6000 890be000 hwpolicy (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\hwpolicy.pdb\0F041CEBADCA48F4BC65F68463272F1D1\hwpolicy.pdb
890be000 890f0000 fvevol (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\fvevol.pdb\DC4549C710EE425F8956C7D82BFE83651\fvevol.pdb
890f0000 89101000 disk (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\disk.pdb\D2AD04F7F4BF45C8A8F0E2BF689326F11\disk.pdb
89101000 89126000 CLASSPNP (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\classpnp.pdb\64A86A6AD27D4730A78ECC25166E13562\classpnp.pdb
89126000 89136000 agp440 (pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\agp440.pdb\BDB51BE7BF024CCF893C1E44B0C266C71\agp440.pdb
kd> .reload /f comint32
“comint32” was not found in the image list.
Debugger will attempt to load “comint32” at given base 00000000.
Please provide the full image name, including the extension (i.e. kernel32.dll)
for more reliable results.Base address and size overrides can be given as
.reload <image.ext>=,. DBGENG: comint32 - Partial symbol image load missing image info DBGHELP: No header for comint32. Searching for dbg file DBGHELP: c:\chapter03ghost\src\objchk_win7_x86\i386\comint32.dbg - file not found DBGHELP: .\comint32.dbg - file not found DBGHELP: comint32 missing debug info. Searching for pdb anyway DBGHELP: Can’t use symbol server for comint32.pdb - no header information available DBGHELP: C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\comint32.pdb\5E9D372C84174583B2DD476990BF10BA1\comint32.pdb already cached DBGHELP: comint32_0 - private symbols & lines C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\comint32.pdb\5E9D372C84174583B2DD476990BF10BA1\comint32.pdb - unmatched Unable to add module at 00000000
I am trying to debug kernel in remote debugging using vmware and windbg.I have connected to target machine .My driver name is comint32.I have started the service of my driver in target machine .I want to view the dbgprint of my driver.Whenever I try to use break point I got an error “couldn’t resolve error at ‘comint32!DriverEntry’”.This is the current status windbg output:
…
kd> .sympath
Symbol search path is: srv*;C:\Chapter03Ghost\bin
Did you actually copy the .pdb file to this “bin” directory? Remember
that you have to recopy the .pdb file there every single time you
rebuild it. The timestamps have to match.
And I assume you realize that you can’t break on “DriverEntry” one the
driver is loaded. That only runs at load time. If you want to catch
DriverEntry, it might be easier to embed a call to DbgBreakPoint in
DriverEntry. Just remember that will blue screen if the kernel debugger
is not attached.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I have try this whether it is right or not how can i view the dbgprint?
kd> bu comint32!DriverEntry
kd> ed nt!Kd_DEFAULT_Mask 0x8
kd> bu comint32!DriverEntry
breakpoint 0 redefined
kd> .bpcmds
bu0 comint32!DriverEntry;
OK, so this is preparing things, but what do you see when you then load
the driver? After the driver is loaded, if you break in, if you do “u
comint32!DriverEntry”, do you see the code?
I usually set Kd_default_mask to “f” to enable everything, although 8
should be enough to catch unadorned DbgPrint.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
if i use this command i get ouput like
kd> bu comint32!DriverEntry
breakpoint 0 redefined
That’s not what I asked you. That command would produce that exact same
output on MY computer, even though I don’t have your driver at all. I
asked you if you are able to see your driver in memory, by disassembling
the code:
u comint32!DriverEntry
Note “u”, not “bu”.
I have used .reg file to install my drivers so it wil start its service whenever it boots.still i can’t get dbgprint any of msg
If the driver is loading at boot, then you shouldn’t need to use “bu”.
You could use “bp”, because the driver should already be present.
However, as I have already said, if your driver is loaded, then
DriverEntry has already run, so you will never hit your breakpoint.
You might consider changing your driver to be demand start instead of
boot start. Then, you can use “net start” and “net stop” to load and
unload it.
If you have set kd_default_mask, then you should be seeing the driver’s
debug output. What output are you expecting to see?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> if i use this command i get ouput like
> kd> bu comint32!DriverEntry
> breakpoint 0 redefined
That’s not what I asked you. That command would produce that exact same
output on MY computer, even though I don’t have your driver at all. I
asked you if you are able to see your driver in memory, by disassembling
the code:
u comint32!DriverEntry
Note “u”, not “bu”.
> I have used .reg file to install my drivers so it wil start its service
> whenever it boots.still i can’t get dbgprint any of msg
***
Using a .reg file has nothing to do with when it starts. Setting its
start property to start at boot time, no matter how you do it, is what
controls this. I have no idea what you mean by “start its service”. What
happens a boot time is your driver (which is not actually a “service”)
loads.
***
If the driver is loading at boot, then you shouldn’t need to use “bu”.
You could use “bp”, because the driver should already be present.
However, as I have already said, if your driver is loaded, then
DriverEntry has already run, so you will never hit your breakpoint.
You might consider changing your driver to be demand start instead of
boot start. Then, you can use “net start” and “net stop” to load and
unload it.
If you have set kd_default_mask, then you should be seeing the driver’s
debug output. What output are you expecting to see?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
shall i use osrloader to load my driver?.It will start its service on demand.I have seen active services of osrloader its say my driver service running so only i have mentioned “start its service” at boot time.
OK, good – this means your driver is loaded, and it has the correct
symbols, because it’s showing you source file and line number. Of
course, that also means you’ll never hit your breakpoint, because
DriverEntry is not touched after the driver is loaded.
shall i use osrloader to load my driver?.It will start its service on demand.I have seen active services of osrloader its say my driver service running so only i have mentioned “start its service” at boot time.
Why would you change anything about this? Your driver is already being
loaded. You have achieved success.
What are you actually trying to do here? What kind of a driver is
this? If you want to see debug messages, you have to do something that
sends a request to the driver. Are you doing that?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thank you tim. This is the kernel mode driver .I want to see whether my driver call every functions correctly which are written in my driver .I have written some my own api handlers instead of existing one .I have written some functions to retrieve name of the process call this api like that …so i need dbgprint to view the working of driver.I didn’t send request to driver.How can i accomplish this?This is KMDF
More importantly this source code is from the book “Professional Rootkits”.
I have a feeling I know what kind of driver this is.
Ben Lewis
On 12/04/2013 17:36, “Tim Roberts” wrote:
>xxxxx@gmail.com wrote: >> This is the output of >> u comint32!driverEnrtry >> >> kd> u comint32!DriverEntry >> comint32!DriverEntry [c:\chapter03ghost\src\ghost.c @ 124]: >> 88daa5b0 8bff mov edi,edi > >OK, good – this means your driver is loaded, and it has the correct >symbols, because it’s showing you source file and line number. Of >course, that also means you’ll never hit your breakpoint, because >DriverEntry is not touched after the driver is loaded. > > >> shall i use osrloader to load my driver?.It will start its service on >>demand.I have seen active services of osrloader its say my driver >>service running so only i have mentioned “start its service” at boot >>time. > >Why would you change anything about this? Your driver is already being >loaded. You have achieved success. > >What are you actually trying to do here? What kind of a driver is >this? If you want to see debug messages, you have to do something that >sends a request to the driver. Are you doing that? > >– >Tim Roberts, xxxxx@probo.com >Providenza & Boekelheide, Inc. > > >— >WINDBG is sponsored by OSR > >OSR is hiring!! Info at http://www.osr.com/careers > >For our schedule of WDF, WDM, debugging and other seminars visit: >http://www.osr.com/seminars > >To unsubscribe, visit the List Server section of OSR Online at >http://www.osronline.com/page.cfm?name=ListServer
Ya It is a kernel mode driver for SSDT hooking only.I am using the way of “professional Rootkit” .I am going to prevent the virus from terminate the anti virus software .because TR/spy.gen,W32/Signature,TR/ATRAPS.Gen, BDS/Agent.bdz TR/XORER.DE …etc virus using below ways
? Null debugger method: An antivirus terminator can use API DebugActiveProcess to attach itself to an
antivirus process as a debugger to control it. Then right after invoking DebugActiveProcess, the antivirus terminator exits. Because the controller of the antivirus process does not exist, the process will crash immediately.
? Dll unloading method: An antivirus terminator can use API ZwUnmapViewOfSection to unload some important dll files, such as ntdll.dll, from an antivirus process to erase some portions of the virtual address space of the antivirus process. ntdll.dll defines many common used windows Native APIs, hence, once the dll file is unloaded from the antivirus process and an API in the dll file is invoked, the process will crash.
? Process termination method: An antivirus terminator gets the handle of an antivirus process by calling API OpenProcess with the process ID of the antivirus process. Then the antivirus terminator can use APIs NtTerminateProcessor ZwTerminateProcess to terminate the antivirus process in the kernel level.
? Close message method: An antivirus terminator can use API FindWindow to search all windows running on the system to find the window matching the name of an antivirus software window (e.g. avguard of antivir or kavsvc of kaspersky). Then the antivirus terminator continues sending messages, such as WM_CLOSE, WM_CLOSE, or WM_QUIT, to the related antivirus process by APIs SendMessage or PostMessage until the process is terminated. The difference between SendMessage and PostMessage is that SendMessage will return the result right after sending the message, but PostMessage just puts the message into the message queue and a programmer cannot know when the message will be handled.
? Mouse simulator method: An antivirus terminator can use API SendInput to counterfeit a series of mouse events which lead to the suspension of an antivirus process. (E.g. An antivirus terminator may find the icon of an antivirus process first. Then it forges a series of mouse events to move the cursor to the right lower corner of the screen, press the right button to expand a work menu, and then chose to suspend an antivirus process). This approach was designed by us. Hence, we have not found an antivirus terminator in the wild utilizing this approach to terminate antivirus software.
? Registry modification method: An antivirus terminator can modify the registry [6] so that a NULL debugger will be attached to an antivirus process when the antivirus process begins its execution. The above steps will stop the execution of the antivirus process. Besides, an antivirus terminator can also modify the registry to delete antivirus related processes from the startup process list; hence, the system will be booted without the protection of an antivirus process. API ZwOpenKey can be used to open a registry key. And API ZwSetValueKey can be used to modify a registry key value.
? Thread termination method: An antivirus terminator can use API TerminateThread to terminate the threads of an antivirus process one by one till the antivirus process stops.
to terminate the anti virus software…The avira,avast,kaspersky,norton,NOD32 software can able to detect some of the anti virus terminators only.SO only I am trying to create one sfotware which is prevent from anti virus software terminate .These virus directly use SSDT table without hooking SSDT i don’t know the possible of create this software.I take the way of malware writers to prevent from malwares
After this also if any one feel i am doing wrong work or something bad.U may say.
First, understand that everything you described can actually be perverted
to a DOS attack, or to build a piece of malware, so don’t expect to find
much help here.
Second, what makes you think that AV companies have not already done these
things?
Third, what makes you think virus writers have not already built
countermeasures to these techniques?
Fourth, does the name “Robert Tappan Morris” ring any bells? Try google.
He was just a college student trying to do something different, and look
what it got him. If your code does part of its job right, but has bugs in
it, and escapes from your control, you will find the blowback to be well
beyond anything you have seen before, although you might get a decade or
so to relax in computer-free surroundings (the courts have been less
inclined to show mercy).
joe
I am not a genius or professional.I am just a college student who trying
to do something different from others.
If that code came from “PROFESSIONAL Rootkits”, I shudder to think of what
AMATEUR rootkits must look like!
joe
More importantly this source code is from the book “Professional
Rootkits”.
I have a feeling I know what kind of driver this is.
Ben Lewis
On 12/04/2013 17:36, “Tim Roberts” wrote: > >>xxxxx@gmail.com wrote: >>> This is the output of >>> u comint32!driverEnrtry >>> >>> kd> u comint32!DriverEntry >>> comint32!DriverEntry [c:\chapter03ghost\src\ghost.c @ 124]: >>> 88daa5b0 8bff mov edi,edi >> >>OK, good – this means your driver is loaded, and it has the correct >>symbols, because it’s showing you source file and line number. Of >>course, that also means you’ll never hit your breakpoint, because >>DriverEntry is not touched after the driver is loaded. >> >> >>> shall i use osrloader to load my driver?.It will start its service on >>>demand.I have seen active services of osrloader its say my driver >>>service running so only i have mentioned “start its service” at boot >>>time. >> >>Why would you change anything about this? Your driver is already being >>loaded. You have achieved success. >> >>What are you actually trying to do here? What kind of a driver is >>this? If you want to see debug messages, you have to do something that >>sends a request to the driver. Are you doing that? >> >>– >>Tim Roberts, xxxxx@probo.com >>Providenza & Boekelheide, Inc. >> >> >>— >>WINDBG is sponsored by OSR >> >>OSR is hiring!! Info at http://www.osr.com/careers >> >>For our schedule of WDF, WDM, debugging and other seminars visit: >>http://www.osr.com/seminars >> >>To unsubscribe, visit the List Server section of OSR Online at >>http://www.osronline.com/page.cfm?name=ListServer > > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
Ya It is a kernel mode driver for SSDT hooking only.I am using the way of “professional Rootkit” .I am going to prevent the virus from terminate the anti virus software .
You can’t do this. I don’t care how smart you are, the virus writers
are smarter. They already know how to work around the SSDT to unhook
whatever hooking you have already done.
As has been said many times on this forum, once you have malicious code
running in kernel mode, the game is over. You have lost. There is
nothing you can do, short of reformatting and reinstalling.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> There is nothing you can do, short of reformatting and reinstalling.
Damn, I did not know that, you better tell Norton, McAffee, Microsoft and
a whole lotta other companies that.
On Mon, Apr 15, 2013 at 12:50 PM, Tim Roberts wrote:
> xxxxx@gmail.com wrote: > > Ya It is a kernel mode driver for SSDT hooking only.I am using the way > of “professional Rootkit” .I am going to prevent the virus from terminate > the anti virus software . > > You can’t do this. I don’t care how smart you are, the virus writers > are smarter. They already know how to work around the SSDT to unhook > whatever hooking you have already done. > > As has been said many times on this forum, once you have malicious code > running in kernel mode, the game is over. You have lost. There is > nothing you can do, short of reformatting and reinstalling. > > – > Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
> There is nothing you can do, short of reformatting and reinstalling.
Damn, I did not know that, you better tell Norton, McAffee, Microsoft
and a whole lotta other companies that.
Your sarcasm is unwarranted. They all know it. The purpose of their
tools is to prevent the code from starting in the first place. Once it
is running in the kernel, all of those tools are hosed.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.