Cause and effect
A forum for reverse engineering, OS internals and malware analysis
Muhaha. No need to "dump", "imprec" and "antidump". Set break on NtResumeThread/NtWriteVirtualMemory - gotcha, all crap will be decrypted in specially allocated memory region by dropper itself. Just dump region, remove trash from the beginning and get fully decrypted ready-to-IDA piece of crap ^^
Ring0 - the source of inspiration
0x16/7ton wrote:http://blog.eset.com/2012/10/18/olmasco ... ion-or-notHello Mr.Matrosov, information stealer from kernelmode.info...
WBR
SWW
-->Virii Cthulhu has you<--
SWW
-->Virii Cthulhu has you<--
Also in case of mysterious "\Device\Inspect" and mysterious IOCTL TDIXX sends to it :D Something points to COMODO. Will be no surprise if this is true and secret IOCTL shutdowns it or does any other fun things (we know about some TDL3 "origin") :D
Ring0 - the source of inspiration
matrosov missed point in case of TDIXX. he posted screenshot with code that creates devices with firewalls related names. now think when maxss loaded. likely before any fw driver. so fw will fail to create it own devices. same about Inspect. if it about comodo then maxss not only do someth with it but also blocks comodo cmdhlp.sys from working (both cmdhlp symlink and device from this driver). havent tried yet with ioctl.
From rkhunter's blog post:
Rootkit device name - \Device\cmdhlp with link \DosDevices\cmdhlp.Anyone have more details about what is going on with this driver?
Last edited by thisisu on Fri Oct 19, 2012 5:35 am, edited 1 time in total.
Inside TDI32/TDI64. It uses several AV FW related names for it own device objects / symbolic links.
\Device\Inspect
\Device\CFPRawFlt
\Device\CFPIpFlt
\Device\CFPUdpFlt
\Device\CFPTcpFlt
\DosDevices\cmdhlp
\Device\cmdhlp
Additionally MaxSS TDI driver does three different calls to Inspect device from the system thread routine right in the beginning of it execution, passing different I/O Control Codes. However all three procedures looks like complete copy-paste of each other, the only difference in Irp->UserBuffer params and in IOCTL code.
\Device\Inspect
\Device\CFPRawFlt
\Device\CFPIpFlt
\Device\CFPUdpFlt
\Device\CFPTcpFlt
\DosDevices\cmdhlp
\Device\cmdhlp
Additionally MaxSS TDI driver does three different calls to Inspect device from the system thread routine right in the beginning of it execution, passing different I/O Control Codes. However all three procedures looks like complete copy-paste of each other, the only difference in Irp->UserBuffer params and in IOCTL code.
Ring0 - the source of inspiration
thisisu wrote:From rkhunter's blog post:cmdhlp device and symbolic link comes from COMODO Internet Security Helper driver. more to say, several part of maxss TDI driver copies from this driver compeltely. Example given: procedure that attachs devices to Ip/Udp/Tcp copied FULLY.Rootkit device name - \Device\cmdhlp with link \DosDevices\cmdhlp.Anyone have more details about what is going on with this driver?
must be a comodo joke, inside of cmdhlp.sys
Note to plagiarists who are attempting to disassemble this code: Be warned!what they do now? will submit a claim on former employees? :lol:
We have patented all of our genuine work and are conducting regular code checks on the market for stolen ideas.
Once we notice the plagiarism, we are going to legally pursue you and your company.
Trust in your abilities and invent yourself!
I always thought comodo as sort of malware :D However we can be wrong of course.
Ring0 - the source of inspiration