load address of ntdll

Chandra · November 26, 2008, 9:29pm

I noticed in XP-SP3 machine the base address of ntdll (bfc43000) is
different than its preferred load address 0x7c900000.

I usually don’t see this on other XP-SP3 machines. I saw this in a dump file
from a customer’s XP-SP3 machine.

What can possibly cause this?

kd> lm v m ntdll
start end module name
bfc43000 bfcf2000 ntdll
Loaded symbol image file: ntdll.dll
Mapped memory image file: c:\symbols\ntdll.dll\4802A12Caf000\ntdll.dll
Image path: ntdll.dll

Thanks
Chandra

OSR_Community_User · November 26, 2008, 9:53pm

One way a rootkit-style attack can succeed is that it knows the addresses of
various pieces of code that it wants to get its fingers into.

Therefore, the modern OS approach is to randomize the load addresses of
various components. I don't know if XP SP3 has introduced this, but from
your description, it sounds like it has. The technique is to randomize the
address of various modules on each boot so that a rootkit cannot easily
detect where code is and patch it effectively.
joe

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of chandra97 97
Sent: Wednesday, November 26, 2008 9:29 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] load address of ntdll

I noticed in XP-SP3 machine the base address of ntdll (bfc43000) is
different than its preferred load address 0x7c900000.

I usually don't see this on other XP-SP3 machines. I saw this in a dump file
from a customer's XP-SP3 machine.

What can possibly cause this?

kd> lm v m ntdll
start end module name
bfc43000 bfcf2000 ntdll
Loaded symbol image file: ntdll.dll
Mapped memory image file: c:\symbols\ntdll.dll\
4802A12Caf000\ntdll.dll
Image path: ntdll.dll

Thanks
Chandra
--- NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: OSR Seminars – OSR To unsubscribe, visit the
List Server section of OSR Online at
ListServer/Forum

This message has been scanned for viruses and
dangerous content by http:</http:> MailScanner, and is
believed to be clean.

Ken_Johnson · November 26, 2008, 11:22pm

Was the machine booted /3GB?

Are you depending on ntdll being at a particular base? Doing so makes your code fairly brittle.

Note that parsing exported system call thunks of a user mode copy of ntdll to find system call ordinals is dangerous.

S

From: chandra97 97
Sent: Wednesday, November 26, 2008 20:30
To: Windows System Software Devs Interest List
Subject: [ntdev] load address of ntdll

I noticed in XP-SP3 machine the base address of ntdll (bfc43000) is different than its preferred load address 0x7c900000.

I usually don’t see this on other XP-SP3 machines. I saw this in a dump file from a customer’s XP-SP3 machine.

What can possibly cause this?

kd> lm v m ntdll
start end module name
bfc43000 bfcf2000 ntdll
Loaded symbol image file: ntdll.dll
Mapped memory image file: c:\symbols\ntdll.dll 4802A12Caf000\ntdll.dll
Image path: ntdll.dll

Thanks
Chandra
— NTDEV is sponsored by OSR 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

Ken_Johnson · November 26, 2008, 11:27pm

As far as I know, the breaks are that there’s no plans to backport ASLR to XP/SP3 or earlier platforms. Vista is the first to have a Microsoft-supplied ASLR solution built-in. It is of course possible that one may encounter third party ASLR implementations on downlevel (pre-Vista) platforms.

In either case, however, if the OP is writing driver code that assumes a base address of ntdll, that’s invalid. (Not for sure that the OP is actually doing that due to a lack of information.)

S

From: Joseph M. Newcomer
Sent: Wednesday, November 26, 2008 20:53
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] load address of ntdll

One way a rootkit-style attack can succeed is that it knows the addresses of various pieces of code that it wants to get its fingers into.

Therefore, the modern OS approach is to randomize the load addresses of various components. I don?t know if XP SP3 has introduced this, but from your description, it sounds like it has. The technique is to randomize the address of various modules on each boot so that a rootkit cannot easily detect where code is and patch it effectively.
joe

________________________________
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of chandra97 97
Sent: Wednesday, November 26, 2008 9:29 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] load address of ntdll

I noticed in XP-SP3 machine the base address of ntdll (bfc43000) is different than its preferred load address 0x7c900000.

I usually don’t see this on other XP-SP3 machines. I saw this in a dump file from a customer’s XP-SP3 machine.

What can possibly cause this?

kd> lm v m ntdll
start end module name
bfc43000 bfcf2000 ntdll
Loaded symbol image file: ntdll.dll
Mapped memory image file: c:\symbols\ntdll.dll 4802A12Caf000\ntdll.dll
Image path: ntdll.dll

Thanks
Chandra
— NTDEV is sponsored by OSR 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
–
This message has been scanned for viruses and
dangerous content by MailScannerhttp:</http:>, and is
believed to be clean.

—
NTDEV is sponsored by OSR

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

Chandra · November 27, 2008, 12:46pm

My driver code does not assume a fixed based address of ntdll. I do lookup
into export table of ntdll for address for location of a named function
address to check for any hooks.

I got this bug check

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by
try-except,
it must be protected by a Probe. Typically the address is just plain bad or
it
is pointing at freed memory.
Arguments:
Arg1: bfc4303c, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: b09009da, If non-zero, the instruction address which referenced the
bad memory
address.
Arg4: 00000002, (reserved)

READ_ADDRESS: bfc4303c

FAULTING_IP:
b09009da 8b423c mov eax,dword ptr [edx+3Ch]

kd> r
eax=f78dab18 ebx=8a296447 ecx=0000bb40 edx=bfc43000 esi=b090b220
edi=00000000
eip=b09009da esp=f78daae8 ebp=f78dab28 iopl=0 nv up ei ng nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282

Note edx has base address ntdll (which I posted earlier in lm command). The
expression [edx+3Ch] actually is reading RVA of beginning of PE signature.
It seems from the bug check code, a read was attempted from invalid address.
Buf, the puzzling part is when I use db and !dh commands on the base address
in the crash dump, they both displays the memory content fine as below.

kd> db bfc43000
bfc43000 4d 5a 90 00 03 00 00 00-04 00 00 00 ff ff 00 00 MZ…
bfc43010 b8 00 00 00 00 00 00 00-40 00 00 00 00 00 00 00 …@…
bfc43020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …
bfc43030 00 00 00 00 00 00 00 00-00 00 00 00 e0 00 00 00 …
bfc43040 0e 1f ba 0e 00 b4 09 cd-21 b8 01 4c cd 21 54 68 …!..L.!Th
bfc43050 69 73 20 70 72 6f 67 72-61 6d 20 63 61 6e 6e 6f is program canno
bfc43060 74 20 62 65 20 72 75 6e-20 69 6e 20 44 4f 53 20 t be run in DOS
bfc43070 6d 6f 64 65 2e 0d 0d 0a-24 00 00 00 00 00 00 00 mode…$…

kd> !dh bfc43000

File Type: DLL
FILE HEADER VALUES
14C machine (i386)
4 number of sections
4802A12C time date stamp Sun Apr 13 20:11:24 2008

0 file pointer to symbol table
0 number of symbols
E0 size of optional header
210E characteristics
Executable
Line numbers stripped
Symbols stripped
32 bit word machine
DLL

OPTIONAL HEADER VALUES
10B magic #
7.10 linker version
7A000 size of code
33A00 size of initialized data
0 size of uninitialized data
12C28 address of entry point
1000 base of code
----- new -----
7c900000 image base
1000 section alignment
200 file alignment
3 subsystem (Windows CUI)
5.01 operating system version
5.01 image version
4.10 subsystem version
AF000 size of image
400 size of headers
B62BC checksum
00040000 size of stack reserve
00001000 size of stack commit
00100000 size of heap reserve
00001000 size of heap commit
3400 [9A40] address [size] of Export Directory
0 [0] address [size] of Import Directory
80000 [2BE68] address [size] of Resource Directory
0 [0] address [size] of Exception Directory
0 [0] address [size] of Security Directory
AC000 [2E84] address [size] of Base Relocation Directory
7AF58 [38] address [size] of Debug Directory
0 [0] address [size] of Description Directory
0 [0] address [size] of Special Directory
0 [0] address [size] of Thread Storage Directory
4F370 [40] address [size] of Load Configuration Directory
0 [0] address [size] of Bound Import Directory
0 [0] address [size] of Import Address Table Directory
0 [0] address [size] of Delay Import Directory
0 [0] address [size] of COR20 Header Directory
0 [0] address [size] of Reserved Directory

SECTION HEADER #1
.text name
79FB6 virtual size
1000 virtual address
7A000 size of raw data
400 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
60000020 flags
Code
(no align specified)
Execute Read

Debug Directories(2)
Type Size Address Pointer
cv 22 7af94 7a394 Format: RSDS, guid, 2, ntdll.pdb
( 10) 4 7af90 7a390

SECTION HEADER #2
.data name
4A00 virtual size
7B000 virtual address
3200 size of raw data
7A400 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0000040 flags
Initialized Data
(no align specified)
Read Write

SECTION HEADER #3
.rsrc name
2BE68 virtual size
80000 virtual address
2C000 size of raw data
7D600 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40000040 flags
Initialized Data
(no align specified)
Read Only

SECTION HEADER #4
.reloc name
2E84 virtual size
AC000 virtual address
3000 size of raw data
A9600 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
42000040 flags
Initialized Data
Discardable
(no align specified)
Read Only

To summarize my questions are:

How come the ntdll was loaded at a base address different than its
preferred load address 0x7c9000000 on XP-SP3. I’m aware of ASLR on Vista
onwards.
2.Why does the crash dump address 0xbfc4303c was a bad read address when db
and !dh display memory content OK.

I can ask the client if they have 3GB switch. But that does not explain why
ntdll was not loaded at its preferred load address on XP-SP3 and the
bugcheck.

Thanks
Chandra

On Wed, Nov 26, 2008 at 11:26 PM, Skywing wrote:

> As far as I know, the breaks are that there’s no plans to backport ASLR
> to XP/SP3 or earlier platforms. Vista is the first to have a
> Microsoft-supplied ASLR solution built-in. It is of course possible that one
> may encounter third party ASLR implementations on downlevel (pre-Vista)
> platforms.
>
> In either case, however, if the OP is writing driver code that assumes a
> base address of ntdll, that’s invalid. (Not for sure that the OP is actually
> doing that due to a lack of information.)
>
> - S
>
> ------------------------------
> From: Joseph M. Newcomer
> Sent: Wednesday, November 26, 2008 20:53
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] load address of ntdll
>
> One way a rootkit-style attack can succeed is that it knows the
> addresses of various pieces of code that it wants to get its fingers into.
>
>
>
> Therefore, the modern OS approach is to randomize the load addresses of
> various components. I don’t know if XP SP3 has introduced this, but from
> your description, it sounds like it has. The technique is to randomize
> the address of various modules on each boot so that a rootkit cannot easily
> detect where code is and patch it effectively.
>
>
> joe
>
>
> ------------------------------
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On* Behalf Of *chandra97 97
> Sent: Wednesday, November 26, 2008 9:29 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] load address of ntdll
>
>
>
> I noticed in XP-SP3 machine the base address of ntdll (bfc43000) is
> different than its preferred load address 0x7c900000.
>
> I usually don’t see this on other XP-SP3 machines. I saw this in a dump
> file from a customer’s XP-SP3 machine.
>
> What can possibly cause this?
>
> kd> lm v m ntdll
> start end module name
> bfc43000 bfcf2000 ntdll
> Loaded symbol image file: ntdll.dll
> Mapped memory image file: c:\symbols\ntdll.dll >
> 4802A12Caf000\ntdll.dll
> Image path: ntdll.dll
>
> Thanks
> Chandra
>
> — NTDEV is sponsored by OSR 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
> –
> This message has been scanned for viruses and
> dangerous content by MailScanner http:</http:>, and is
> believed to be clean.
>
> —
> NTDEV is sponsored by OSR
>
> 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
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

Ken_Johnson · November 27, 2008, 12:57pm

Unless /3GB is used, that?s a kernel address and not a user address. If it was a PAGE_FAULT_IN_NONPAGED_AREA bugcheck, though, that would tend to mean that it?s not being mapped as a user address.

If you are debugging a minidump, the debugger will substitute images from the symbol path for the actual image contents and may show valid image data when it would be paged out or nonexistent in the target. A full dump or live debugging won?t exhibit this behavior. (This is done for minidumps as to save space, they do not include image memory in general.)

What you are doing seems quite dangerous, however, given the available information. How are you finding the load address of NTDLL anyway in this case? Are you traversing the loaded module list off of the PEB? Doing so is certainly not safe to do from kernel mode.

You should also be aware that if you are trying to check for hooks, it?s possible that code can be modified after you run your check. It is also possible for a clever adversary to use debug registers or guard or no-access pages to simulate hooking without patching opcode bytes, which would again defeat opcode-scanning hook detection mechanisms.

Extensions such as !vad or !pte or !vtop should show the actual story with respect to whether memory was resident or not (though I?m not sure if a minidump will have enough information to use all of those, and it?s possible that those extensions have become broken recently as well, unfortunately).

S

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of chandra97 97
Sent: Thursday, November 27, 2008 12:45 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] load address of ntdll

My driver code does not assume a fixed based address of ntdll. I do lookup into export table of ntdll for address for location of a named function address to check for any hooks.

I got this bug check

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: bfc4303c, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: b09009da, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000002, (reserved)

READ_ADDRESS: bfc4303c

FAULTING_IP:
b09009da 8b423c mov eax,dword ptr [edx+3Ch]

kd> r
eax=f78dab18 ebx=8a296447 ecx=0000bb40 edx=bfc43000 esi=b090b220 edi=00000000
eip=b09009da esp=f78daae8 ebp=f78dab28 iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282

Note edx has base address ntdll (which I posted earlier in lm command). The expression [edx+3Ch] actually is reading RVA of beginning of PE signature. It seems from the bug check code, a read was attempted from invalid address. Buf, the puzzling part is when I use db and !dh commands on the base address in the crash dump, they both displays the memory content fine as below.