A forum for reverse engineering, OS internals and malware analysis 

Forum for announcements and questions about tools and software.
 #552  by lilxam
 Sun Apr 04, 2010 6:24 pm
Yes Alex you're right, the technique I show is a bit "hardcore", by erasing the pointers to the VAD of my dll I erase from the VAD Tree all the others VAD depending (the "chidlren") of it. So it's very unstable yes. But my purpose was only to show how we can manipulate the VAD Tree. And I didn't have the time and the motivation to do this safely.
But now I realize that it would have been so cleaner (and easy) to just erase the fields containing informations about the Dll (File Object, Control Area, ...). I imagine it's what you've done with your Invisible Dll, don't you ?

Lilxam.
 #553  by Alex
 Sun Apr 04, 2010 7:31 pm
Hi Lilxam,

I used to erase some fields in the first version of Invisible Dll, but now I'm changing some fields of VAD (v1.1) and related structures (v1.2) instead of erasing them. It is safer and more stable, since such fields as ControlArea shouldn't be erased.

Alex
 #6429  by Flopik
 Thu May 19, 2011 8:42 pm
Are you going to post the Invisible DLL soft one day? I would like to test my antirootkit againts it
Alex wrote:Hi Lilxam,

I used to erase some fields in the first version of Invisible Dll, but now I'm changing some fields of VAD (v1.1) and related structures (v1.2) instead of erasing them. It is safer and more stable, since such fields as ControlArea shouldn't be erased.

Alex
 #6431  by Alex
 Fri May 20, 2011 6:24 am
There is no sense to publish such testing tools, because more and more malware follows TDL concept and loads its DLLs manually from kernel mode. If your tool distinguishes executable memory regions than it will be able to detect something like Invisible DLL 1.1.
 #6445  by Flopik
 Fri May 20, 2011 7:37 pm
I think the PE header, IAT should be wiped also , a memory search pattern can detect the DLL this way (I know this is only a poc)
!address 0x003d006c
Usage: <unclassified>
Allocation Base: 003d0000
Base Address: 003d0000
End Address: 003d1000
Region Size: 00001000
Type: 01000000 MEM_IMAGE
State: 00001000 MEM_COMMIT
Protect: 00000002 PAGE_READONLY

0:001> s -[1]a 0 0FFFFFFF "DOS mode"
- > 0x003d006c
0x0040006c
0:001> db 0x003d006c
003d006c 44 4f 53 20 6d 6f 64 65-2e 0d 0d 0a 24 00 00 00 DOS mode....$...
003d007c 00 00 00 00 7d d3 5b d8-39 b2 35 8b 39 b2 35 8b ....}.[.9.5.9.5.
003d008c 39 b2 35 8b fa bd 69 8b-38 b2 35 8b fa bd 6a 8b 9.5...i.8.5...j.
003d009c 38 b2 35 8b fa bd 6b 8b-38 b2 35 8b fa bd 6f 8b 8.5...k.8.5...o.
003d00ac 38 b2 35 8b 52 69 63 68-39 b2 35 8b 00 00 00 00 8.5.Rich9.5.....
003d00bc 00 00 00 00 50 45 00 00-4c 01 03 00 74 26 95 4b ....PE..L...t&.K
003d00cc 00 00 00 00 00 00 00 00-e0 00 0e 21 0b 01 07 0a ...........!....
003d00dc 00 02 00 00 00 06 00 00-00 00 00 00 05 10 00 00 ................

lkd> dt _CONTROL_AREA 0x81ff2008
nt!_CONTROL_AREA
+0x000 Segment : 0xe1b8d9f0 _SEGMENT
+0x004 DereferenceList : _LIST_ENTRY [ 0x0 - 0x0 ]
+0x00c NumberOfSectionReferences : 0
+0x010 NumberOfPfnReferences : 4
+0x014 NumberOfMappedViews : 1
+0x018 NumberOfSubsections : 4
+0x01a FlushInProgressCount : 0
+0x01c NumberOfUserReferences : 1
+0x020 u : __unnamed
+0x024 FilePointer : (null) <----