Windows memory management and protection discuss

I have tried the following two methods,both of them can write read only memory.If i don’t not use the following methods, and try to write the memory(assume the system space memory like nt or hal data structure and so on), i got BSOD:
Bug Check 0xBE: ATTEMPTED_WRITE_TO_READONLY_MEMORY

Methord one:
function WriteReadOnlyMemoryMark(lpDest, lpSource: Pointer; Length: Integer):

NTSTATUS;
var
tempSpinLock: KSPIN_LOCK;
oldirql: KIRQL;
mdl: PMDL;
writableAddress: Pointer;
begin
Result := STATUS_UNSUCCESSFUL;
mdl := IoAllocateMdl(lpDest, Length, False, False, nil);
if (mdl <> nil) then
begin
MmBuildMdlForNonPagedPool(mdl);
MmProbeAndLockPages(mdl, KernelMode, IoWriteAccess);
writableAddress := MmMapLockedPages(mdl, KernelMode);
if (writableAddress <> nil) then
begin
oldirql := 0;

KeInitializeSpinLock(@tempSpinLock);
fast_KfAcquireSpinLock(@tempSpinLock);
memcpy(writableAddress, lpSource, Length);
fast_KfReleaseSpinLock(@tempSpinLock, oldirql);

MmUnmapLockedPages(writableAddress, mdl);
Result := STATUS_SUCCESS;
end;
MmUnlockPages(mdl);
IoFreeMdl(mdl);
end;
end;

Methord two:

function WriteReadOnlyMemoryGates(lpDest, lpSource: Pointer; Length: Integer):

NTSTATUS;
var
tempSpinLock: KSPIN_LOCK;
oldirql: KIRQL;
mdl: PMDL;
writableAddress: Pointer;
begin
Result := STATUS_UNSUCCESSFUL;
mdl := MmCreateMdl(nil, lpDest, Length);
if (mdl <> nil) then
begin
MmBuildMdlForNonPagedPool(mdl);
mdl^.MdlFlags := mdl^.MdlFlags or MDL_MAPPED_TO_SYSTEM_VA;
writableAddress := MmMapLockedPages(mdl, KernelMode);
if (writableAddress <> nil) then
begin
oldirql := 0;

KeInitializeSpinLock(@tempSpinLock);
fast_KfAcquireSpinLock(@tempSpinLock);
memcpy(writableAddress, lpSource, Length);
fast_KfReleaseSpinLock(@tempSpinLock, oldirql);

MmUnmapLockedPages(writableAddress, mdl);
Result := STATUS_SUCCESS;

end;
MmUnlockPages(mdl);
IoFreeMdl(mdl);
end;
end;

Now my question is:
1 why the methords mentioned above can let the memory be writable?
Does the functions change the propertries(like x86 CPU defined) of the physical page of the memory? This refers to memory management and protection mechanism of windows, one word can not classifies clearly.
2 Will changed memory be writen to the disk image(not page file on the disk)? If this is truth,then the disk image of the system key files(like hal.dll and so on) may be destroyed(I assume the WFP is disabled)?

Just for research purpose, so the more details supplied(don’t say the OS do it, i do know cpu and os do it:)), the better i think. Any articles about those aspect will be highly appreciated too.

Thanks very much.
Ma

You don’t really write drivers in Delphi, don’t you?

–PA

xxxxx@gmail.com wrote:

I have tried the following two methods,both of them can write read only memory.If i don’t not use the following methods, and try to write the memory(assume the system space memory like nt or hal data structure and so on), i got BSOD:
Bug Check 0xBE: ATTEMPTED_WRITE_TO_READONLY_MEMORY

Methord one:
function WriteReadOnlyMemoryMark(lpDest, lpSource: Pointer; Length: Integer):

NTSTATUS;
var
tempSpinLock: KSPIN_LOCK;
oldirql: KIRQL;
mdl: PMDL;
writableAddress: Pointer;
begin
Result := STATUS_UNSUCCESSFUL;
mdl := IoAllocateMdl(lpDest, Length, False, False, nil);
if (mdl <> nil) then
begin
MmBuildMdlForNonPagedPool(mdl);
MmProbeAndLockPages(mdl, KernelMode, IoWriteAccess);
writableAddress := MmMapLockedPages(mdl, KernelMode);
if (writableAddress <> nil) then
begin
oldirql := 0;

KeInitializeSpinLock(@tempSpinLock);
fast_KfAcquireSpinLock(@tempSpinLock);
memcpy(writableAddress, lpSource, Length);
fast_KfReleaseSpinLock(@tempSpinLock, oldirql);

MmUnmapLockedPages(writableAddress, mdl);
Result := STATUS_SUCCESS;
end;
MmUnlockPages(mdl);
IoFreeMdl(mdl);
end;
end;

Methord two:

function WriteReadOnlyMemoryGates(lpDest, lpSource: Pointer; Length: Integer):

NTSTATUS;
var
tempSpinLock: KSPIN_LOCK;
oldirql: KIRQL;
mdl: PMDL;
writableAddress: Pointer;
begin
Result := STATUS_UNSUCCESSFUL;
mdl := MmCreateMdl(nil, lpDest, Length);
if (mdl <> nil) then
begin
MmBuildMdlForNonPagedPool(mdl);
mdl^.MdlFlags := mdl^.MdlFlags or MDL_MAPPED_TO_SYSTEM_VA;
writableAddress := MmMapLockedPages(mdl, KernelMode);
if (writableAddress <> nil) then
begin
oldirql := 0;

KeInitializeSpinLock(@tempSpinLock);
fast_KfAcquireSpinLock(@tempSpinLock);
memcpy(writableAddress, lpSource, Length);
fast_KfReleaseSpinLock(@tempSpinLock, oldirql);

MmUnmapLockedPages(writableAddress, mdl);
Result := STATUS_SUCCESS;

end;
MmUnlockPages(mdl);
IoFreeMdl(mdl);
end;
end;

Now my question is:
1 why the methords mentioned above can let the memory be writable?
Does the functions change the propertries(like x86 CPU defined) of the physical page of the memory? This refers to memory management and protection mechanism of windows, one word can not classifies clearly.
2 Will changed memory be writen to the disk image(not page file on the disk)? If this is truth,then the disk image of the system key files(like hal.dll and so on) may be destroyed(I assume the WFP is disabled)?

Just for research purpose, so the more details supplied(don’t say the OS do it, i do know cpu and os do it:)), the better i think. Any articles about those aspect will be highly appreciated too.

Thanks very much.
Ma

Of cource not. you means the code i paste, that’s not the real code in the
driver

2008/9/25 Pavel A.

> You don’t really write drivers in Delphi, don’t you?
>
> --PA
>
>
>
> xxxxx@gmail.com wrote:
>
>> I have tried the following two methods,both of them can write read only
>> memory.If i don’t not use the following methods, and try to write the
>> memory(assume the system space memory like nt or hal data structure and so
>> on), i got BSOD:
>> Bug Check 0xBE: ATTEMPTED_WRITE_TO_READONLY_MEMORY
>>
>> Methord one:
>> function WriteReadOnlyMemoryMark(lpDest, lpSource: Pointer; Length:
>> Integer):
>>
>> NTSTATUS;
>> var
>> tempSpinLock: KSPIN_LOCK;
>> oldirql: KIRQL;
>> mdl: PMDL;
>> writableAddress: Pointer;
>> begin
>> Result := STATUS_UNSUCCESSFUL;
>> mdl := IoAllocateMdl(lpDest, Length, False, False, nil);
>> if (mdl <> nil) then
>> begin
>> MmBuildMdlForNonPagedPool(mdl);
>> MmProbeAndLockPages(mdl, KernelMode, IoWriteAccess);
>> writableAddress := MmMapLockedPages(mdl, KernelMode);
>> if (writableAddress <> nil) then
>> begin
>> oldirql := 0;
>>
>> KeInitializeSpinLock(@tempSpinLock);
>> fast_KfAcquireSpinLock(@tempSpinLock);
>> memcpy(writableAddress, lpSource, Length);
>> fast_KfReleaseSpinLock(@tempSpinLock, oldirql);
>>
>> MmUnmapLockedPages(writableAddress, mdl);
>> Result := STATUS_SUCCESS;
>> end;
>> MmUnlockPages(mdl);
>> IoFreeMdl(mdl);
>> end;
>> end;
>>
>>
>> Methord two:
>>
>> function WriteReadOnlyMemoryGates(lpDest, lpSource: Pointer; Length:
>> Integer):
>>
>> NTSTATUS;
>> var
>> tempSpinLock: KSPIN_LOCK;
>> oldirql: KIRQL;
>> mdl: PMDL;
>> writableAddress: Pointer;
>> begin
>> Result := STATUS_UNSUCCESSFUL;
>> mdl := MmCreateMdl(nil, lpDest, Length);
>> if (mdl <> nil) then
>> begin
>> MmBuildMdlForNonPagedPool(mdl);
>> mdl^.MdlFlags := mdl^.MdlFlags or MDL_MAPPED_TO_SYSTEM_VA;
>> writableAddress := MmMapLockedPages(mdl, KernelMode);
>> if (writableAddress <> nil) then
>> begin
>> oldirql := 0;
>>
>> KeInitializeSpinLock(@tempSpinLock);
>> fast_KfAcquireSpinLock(@tempSpinLock);
>> memcpy(writableAddress, lpSource, Length);
>> fast_KfReleaseSpinLock(@tempSpinLock, oldirql);
>>
>> MmUnmapLockedPages(writableAddress, mdl);
>> Result := STATUS_SUCCESS;
>>
>> end;
>> MmUnlockPages(mdl);
>> IoFreeMdl(mdl);
>> end;
>> end;
>>
>> Now my question is:
>> 1 why the methords mentioned above can let the memory be writable?
>> Does the functions change the propertries(like x86 CPU defined) of the
>> physical page of the memory? This refers to memory management and protection
>> mechanism of windows, one word can not classifies clearly.
>> 2 Will changed memory be writen to the disk image(not page file on the
>> disk)? If this is truth,then the disk image of the system key files(like
>> hal.dll and so on) may be destroyed(I assume the WFP is disabled)?
>>
>> Just for research purpose, so the more details supplied(don’t say the OS
>> do it, i do know cpu and os do it:)), the better i think. Any articles about
>> those aspect will be highly appreciated too.
>>
>> Thanks very much.
>> Ma
>>
>
> —
> 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
>

Lol :slight_smile:
I thought that was Pascal :))

Be careful at this line though
“MmProbeAndLockPages(mdl, KernelMode, IoWriteAccess);”

This function can through an exception. You should put it in the __try
__except embrace.
Just to give you a teaser, instead of KernelMode use UserMode. I think you
should see that you might not get the lock, and thus access to write the
memory.
Make a little more research on kernel mode vs user mode in the memory
management side.

And for the love of god, please don’t use pascal dude to express you
feelings

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Thursday, September 25, 2008 12:21 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Windows memory management and protection discuss

You don’t really write drivers in Delphi, don’t you?

–PA

xxxxx@gmail.com wrote:

I have tried the following two methods,both of them can write read only
memory.If i don’t not use the following methods, and try to write the
memory(assume the system space memory like nt or hal data structure and so
on), i got BSOD:
Bug Check 0xBE: ATTEMPTED_WRITE_TO_READONLY_MEMORY

Methord one:
function WriteReadOnlyMemoryMark(lpDest, lpSource: Pointer; Length:
Integer):

NTSTATUS;
var
tempSpinLock: KSPIN_LOCK;
oldirql: KIRQL;
mdl: PMDL;
writableAddress: Pointer;
begin
Result := STATUS_UNSUCCESSFUL;
mdl := IoAllocateMdl(lpDest, Length, False, False, nil);
if (mdl <> nil) then
begin
MmBuildMdlForNonPagedPool(mdl);
MmProbeAndLockPages(mdl, KernelMode, IoWriteAccess);
writableAddress := MmMapLockedPages(mdl, KernelMode);
if (writableAddress <> nil) then
begin
oldirql := 0;

KeInitializeSpinLock(@tempSpinLock);
fast_KfAcquireSpinLock(@tempSpinLock);
memcpy(writableAddress, lpSource, Length);
fast_KfReleaseSpinLock(@tempSpinLock, oldirql);

MmUnmapLockedPages(writableAddress, mdl);
Result := STATUS_SUCCESS;
end;
MmUnlockPages(mdl);
IoFreeMdl(mdl);
end;
end;

Methord two:

function WriteReadOnlyMemoryGates(lpDest, lpSource: Pointer; Length:
Integer):

NTSTATUS;
var
tempSpinLock: KSPIN_LOCK;
oldirql: KIRQL;
mdl: PMDL;
writableAddress: Pointer;
begin
Result := STATUS_UNSUCCESSFUL;
mdl := MmCreateMdl(nil, lpDest, Length);
if (mdl <> nil) then
begin
MmBuildMdlForNonPagedPool(mdl);
mdl^.MdlFlags := mdl^.MdlFlags or MDL_MAPPED_TO_SYSTEM_VA;
writableAddress := MmMapLockedPages(mdl, KernelMode);
if (writableAddress <> nil) then
begin
oldirql := 0;

KeInitializeSpinLock(@tempSpinLock);
fast_KfAcquireSpinLock(@tempSpinLock);
memcpy(writableAddress, lpSource, Length);
fast_KfReleaseSpinLock(@tempSpinLock, oldirql);

MmUnmapLockedPages(writableAddress, mdl);
Result := STATUS_SUCCESS;

end;
MmUnlockPages(mdl);
IoFreeMdl(mdl);
end;
end;

Now my question is:
1 why the methords mentioned above can let the memory be writable?
Does the functions change the propertries(like x86 CPU defined) of the
physical page of the memory? This refers to memory management and protection
mechanism of windows, one word can not classifies clearly.
2 Will changed memory be writen to the disk image(not page file on the
disk)? If this is truth,then the disk image of the system key files(like
hal.dll and so on) may be destroyed(I assume the WFP is disabled)?

Just for research purpose, so the more details supplied(don’t say the OS
do it, i do know cpu and os do it:)), the better i think. Any articles about
those aspect will be highly appreciated too.

Thanks very much.
Ma


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

OK. I’ll bite - why are you doing this? Not just post code that isn’t what you actually use, and ask for help with it, but why
chose Delphi?

mm

Carleton Ma wrote:

Of cource not. you means the code i paste, that’s not the real code in
the driver

2008/9/25 Pavel A. >
>
> You don’t really write drivers in Delphi, don’t you?
>
> --PA
>
>
>
> xxxxx@gmail.com mailto:xxxxx wrote:
>
> I have tried the following two methods,both of them can write
> read only memory.If i don’t not use the following methods, and
> try to write the memory(assume the system space memory like nt
> or hal data structure and so on), i got BSOD:
> Bug Check 0xBE: ATTEMPTED_WRITE_TO_READONLY_MEMORY
>
> Methord one:
> function WriteReadOnlyMemoryMark(lpDest, lpSource: Pointer;
> Length: Integer):
>
> NTSTATUS;
> var
> tempSpinLock: KSPIN_LOCK;
> oldirql: KIRQL;
> mdl: PMDL;
> writableAddress: Pointer;
> begin
> Result := STATUS_UNSUCCESSFUL;
> mdl := IoAllocateMdl(lpDest, Length, False, False, nil);
> if (mdl <> nil) then
> begin
> MmBuildMdlForNonPagedPool(mdl);
> MmProbeAndLockPages(mdl, KernelMode, IoWriteAccess);
> writableAddress := MmMapLockedPages(mdl, KernelMode);
> if (writableAddress <> nil) then
> begin
> oldirql := 0;
>
> KeInitializeSpinLock(@tempSpinLock);
> fast_KfAcquireSpinLock(@tempSpinLock);
> memcpy(writableAddress, lpSource, Length);
> fast_KfReleaseSpinLock(@tempSpinLock, oldirql);
>
> MmUnmapLockedPages(writableAddress, mdl);
> Result := STATUS_SUCCESS;
> end;
> MmUnlockPages(mdl);
> IoFreeMdl(mdl);
> end;
> end;
>
>
> Methord two:
>
> function WriteReadOnlyMemoryGates(lpDest, lpSource: Pointer;
> Length: Integer):
>
> NTSTATUS;
> var
> tempSpinLock: KSPIN_LOCK;
> oldirql: KIRQL;
> mdl: PMDL;
> writableAddress: Pointer;
> begin
> Result := STATUS_UNSUCCESSFUL;
> mdl := MmCreateMdl(nil, lpDest, Length);
> if (mdl <> nil) then
> begin
> MmBuildMdlForNonPagedPool(mdl);
> mdl^.MdlFlags := mdl^.MdlFlags or MDL_MAPPED_TO_SYSTEM_VA;
> writableAddress := MmMapLockedPages(mdl, KernelMode);
> if (writableAddress <> nil) then
> begin
> oldirql := 0;
>
> KeInitializeSpinLock(@tempSpinLock);
> fast_KfAcquireSpinLock(@tempSpinLock);
> memcpy(writableAddress, lpSource, Length);
> fast_KfReleaseSpinLock(@tempSpinLock, oldirql);
>
> MmUnmapLockedPages(writableAddress, mdl);
> Result := STATUS_SUCCESS;
>
> end;
> MmUnlockPages(mdl);
> IoFreeMdl(mdl);
> end;
> end;
>
> Now my question is:
> 1 why the methords mentioned above can let the memory be writable?
> Does the functions change the propertries(like x86 CPU defined)
> of the physical page of the memory? This refers to memory
> management and protection mechanism of windows, one word can not
> classifies clearly.
> 2 Will changed memory be writen to the disk image(not page file
> on the disk)? If this is truth,then the disk image of the system
> key files(like hal.dll and so on) may be destroyed(I assume the
> WFP is disabled)?
>
> Just for research purpose, so the more details supplied(don’t
> say the OS do it, i do know cpu and os do it:)), the better i
> think. Any articles about those aspect will be highly
> appreciated too.
>
> Thanks very much.
> Ma
>
>
> —
> 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
>
></mailto:xxxxx>

Here are some problems:

-You do not call MmProbeAndLockPages after MmBuildMdlForNonPagedPool. If
your buffer resides in non paged pool you can call
MmBuildMdlForNonPagedPool. Then the pages are already locked and resident.

-Calls to MmProbeAndLockPages must be within a try/except block.
-MmCreateMdl is obsolete, use IoAllocateMdl instead
-MmMapLockedPages is obsolete, use MmMapLockedPagesSpecifyCache instead
-MmMapLockedPagesSpecifyCache should also be within a try/except block
(assuming BugCheckOnFailure is set to FALSE)

Read the great OSR article on MDLs:

http://www.osronline.com/article.cfm?id=423

Back in the days of NT4 Borland seriously considered allowing Delphi to
build drivers but they fortunately dropped that idea.

//Daniel

wrote in message news:xxxxx@ntdev…
> I have tried the following two methods,both of them can write read only
> memory.If i don’t not use the following methods, and try to write the
> memory(assume the system space memory like nt or hal data structure and so
> on), i got BSOD:
> Bug Check 0xBE: ATTEMPTED_WRITE_TO_READONLY_MEMORY
>
> Methord one:
> function WriteReadOnlyMemoryMark(lpDest, lpSource: Pointer; Length:
> Integer):
>
> NTSTATUS;
> var
> tempSpinLock: KSPIN_LOCK;
> oldirql: KIRQL;
> mdl: PMDL;
> writableAddress: Pointer;
> begin
> Result := STATUS_UNSUCCESSFUL;
> mdl := IoAllocateMdl(lpDest, Length, False, False, nil);
> if (mdl <> nil) then
> begin
> MmBuildMdlForNonPagedPool(mdl);
> MmProbeAndLockPages(mdl, KernelMode, IoWriteAccess);
> writableAddress := MmMapLockedPages(mdl, KernelMode);
> if (writableAddress <> nil) then
> begin
> oldirql := 0;
>
> KeInitializeSpinLock(@tempSpinLock);
> fast_KfAcquireSpinLock(@tempSpinLock);
> memcpy(writableAddress, lpSource, Length);
> fast_KfReleaseSpinLock(@tempSpinLock, oldirql);
>
> MmUnmapLockedPages(writableAddress, mdl);
> Result := STATUS_SUCCESS;
> end;
> MmUnlockPages(mdl);
> IoFreeMdl(mdl);
> end;
> end;
>
>
> Methord two:
>
> function WriteReadOnlyMemoryGates(lpDest, lpSource: Pointer; Length:
> Integer):
>
> NTSTATUS;
> var
> tempSpinLock: KSPIN_LOCK;
> oldirql: KIRQL;
> mdl: PMDL;
> writableAddress: Pointer;
> begin
> Result := STATUS_UNSUCCESSFUL;
> mdl := MmCreateMdl(nil, lpDest, Length);
> if (mdl <> nil) then
> begin
> MmBuildMdlForNonPagedPool(mdl);
> mdl^.MdlFlags := mdl^.MdlFlags or MDL_MAPPED_TO_SYSTEM_VA;
> writableAddress := MmMapLockedPages(mdl, KernelMode);
> if (writableAddress <> nil) then
> begin
> oldirql := 0;
>
> KeInitializeSpinLock(@tempSpinLock);
> fast_KfAcquireSpinLock(@tempSpinLock);
> memcpy(writableAddress, lpSource, Length);
> fast_KfReleaseSpinLock(@tempSpinLock, oldirql);
>
> MmUnmapLockedPages(writableAddress, mdl);
> Result := STATUS_SUCCESS;
>
> end;
> MmUnlockPages(mdl);
> IoFreeMdl(mdl);
> end;
> end;
>
> Now my question is:
> 1 why the methords mentioned above can let the memory be writable?
> Does the functions change the propertries(like x86 CPU defined) of the
> physical page of the memory? This refers to memory management and
> protection mechanism of windows, one word can not classifies clearly.
> 2 Will changed memory be writen to the disk image(not page file on the
> disk)? If this is truth,then the disk image of the system key files(like
> hal.dll and so on) may be destroyed(I assume the WFP is disabled)?
>
> Just for research purpose, so the more details supplied(don’t say the OS
> do it, i do know cpu and os do it:)), the better i think. Any articles
> about those aspect will be highly appreciated too.
>
> Thanks very much.
> Ma
>

Ehrm, one thing though: Delphi != Pascal. It used to be, though.

There is nothing wrong with either one, but they *shouldn’t* be used for the same reason the GCC is not recommended. But it is probably *possible* to write (KM) drivers in any language that gives you enough control over linker and compiler.

I guess the bigger problem is that most people here do not have any kind of Pascal build environment for drivers, so it’s impossible to test-drive scenarios like in many other posts. Therefore the help is limited to a theoretical discussion and still leaves the possibility for a compiler-related problem …

Just my two cents :wink:

// Oliver

-------- Original-Nachricht --------

Datum: Thu, 25 Sep 2008 06:36:16 -0400
Von: Martin O'Brien
> An: “Windows System Software Devs Interest List”
> Betreff: Re:[ntdev] Windows memory management and protection discuss

> OK. I’ll bite - why are you doing this? Not just post code that isn’t
> what you actually use, and ask for help with it, but why
> chose Delphi?
>
>
> mm
> […]


---------------------------------------------------
DDKWizard and DDKBUILD: http:

Trunk (potentially unstable) version: http:</http:></http:>

Thanks to reply my questions.
To be honest, i really don’t know what the language is for the code i have
pasted(i got it from google), i just pay attention to the memory manager
related funcion like IoAllocateMdl,MmProbeAndLockPages(i did use the
try/catch block),MmMapLockedPages and so on, i have read the nt insider’s
article your have shown above before i post this topic, that’s really a good
knowage about MDL, but is seems the article focus on what is mdl on earth
and how you can use it in your driver, while my concerns are:
1 How these functions could change the read only memory to be writable
memory.
2 When the read only memory(assum it contains system structures) has been
changed to writble memory and if the WFP(windows file protection) is
disable, whether the changed system structure will be flush back to disk
image of the system file or the page files on the disk, and why?

once again, thanks to pay attention to my question, any suggestion will be
appreciated.

Ma

2008/9/25 Oliver Schneider

> Ehrm, one thing though: Delphi != Pascal. It used to be, though.
>
> There is nothing wrong with either one, but they shouldn’t be used for
> the same reason the GCC is not recommended. But it is probably possible to
> write (KM) drivers in any language that gives you enough control over linker
> and compiler.
>
> I guess the bigger problem is that most people here do not have any kind of
> Pascal build environment for drivers, so it’s impossible to test-drive
> scenarios like in many other posts. Therefore the help is limited to a
> theoretical discussion and still leaves the possibility for a
> compiler-related problem …
>
> Just my two cents :wink:
>
> // Oliver
>
> -------- Original-Nachricht --------
> > Datum: Thu, 25 Sep 2008 06:36:16 -0400
> > Von: Martin O'Brien
> > An: “Windows System Software Devs Interest List”
> > Betreff: Re:[ntdev] Windows memory management and protection discuss
>
> > OK. I’ll bite - why are you doing this? Not just post code that isn’t
> > what you actually use, and ask for help with it, but why
> > chose Delphi?
> >
> >
> > mm
> > […]
>
> –
> ---------------------------------------------------
> DDKWizard and DDKBUILD: http:
>
> Trunk (potentially unstable) version: <
> http://ddkwizard.assarbad.net/trunk/ddkbuild.cmd&gt;
>
>
> —
> 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
></http:>

In addtion to articles about MDL, i also read the articles about the virtual
memory manager from the online NT insider:Windows NT Virtual Memory (Part
I),Windows NT Virtual Memory (Part ||) and Windows NT Virtual Memory (Part
|||) and so on, but it seems that i cann’t find the answer to my question
from the articles.

Thanks
Ma

2008/9/25

> Here are some problems:
>
> -You do not call MmProbeAndLockPages after MmBuildMdlForNonPagedPool. If
> your buffer resides in non paged pool you can call
> MmBuildMdlForNonPagedPool. Then the pages are already locked and resident.
>
> -Calls to MmProbeAndLockPages must be within a try/except block.
> -MmCreateMdl is obsolete, use IoAllocateMdl instead
> -MmMapLockedPages is obsolete, use MmMapLockedPagesSpecifyCache instead
> -MmMapLockedPagesSpecifyCache should also be within a try/except block
> (assuming BugCheckOnFailure is set to FALSE)
>
> Read the great OSR article on MDLs:
>
> http://www.osronline.com/article.cfm?id=423
>
> Back in the days of NT4 Borland seriously considered allowing Delphi to
> build drivers but they fortunately dropped that idea.
>
> //Daniel
>
>
>
>
> wrote in message news:xxxxx@ntdev…
>
> I have tried the following two methods,both of them can write read only
>> memory.If i don’t not use the following methods, and try to write the
>> memory(assume the system space memory like nt or hal data structure and so
>> on), i got BSOD:
>> Bug Check 0xBE: ATTEMPTED_WRITE_TO_READONLY_MEMORY
>>
>> Methord one:
>> function WriteReadOnlyMemoryMark(lpDest, lpSource: Pointer; Length:
>> Integer):
>>
>> NTSTATUS;
>> var
>> tempSpinLock: KSPIN_LOCK;
>> oldirql: KIRQL;
>> mdl: PMDL;
>> writableAddress: Pointer;
>> begin
>> Result := STATUS_UNSUCCESSFUL;
>> mdl := IoAllocateMdl(lpDest, Length, False, False, nil);
>> if (mdl <> nil) then
>> begin
>> MmBuildMdlForNonPagedPool(mdl);
>> MmProbeAndLockPages(mdl, KernelMode, IoWriteAccess);
>> writableAddress := MmMapLockedPages(mdl, KernelMode);
>> if (writableAddress <> nil) then
>> begin
>> oldirql := 0;
>>
>> KeInitializeSpinLock(@tempSpinLock);
>> fast_KfAcquireSpinLock(@tempSpinLock);
>> memcpy(writableAddress, lpSource, Length);
>> fast_KfReleaseSpinLock(@tempSpinLock, oldirql);
>>
>> MmUnmapLockedPages(writableAddress, mdl);
>> Result := STATUS_SUCCESS;
>> end;
>> MmUnlockPages(mdl);
>> IoFreeMdl(mdl);
>> end;
>> end;
>>
>>
>> Methord two:
>>
>> function WriteReadOnlyMemoryGates(lpDest, lpSource: Pointer; Length:
>> Integer):
>>
>> NTSTATUS;
>> var
>> tempSpinLock: KSPIN_LOCK;
>> oldirql: KIRQL;
>> mdl: PMDL;
>> writableAddress: Pointer;
>> begin
>> Result := STATUS_UNSUCCESSFUL;
>> mdl := MmCreateMdl(nil, lpDest, Length);
>> if (mdl <> nil) then
>> begin
>> MmBuildMdlForNonPagedPool(mdl);
>> mdl^.MdlFlags := mdl^.MdlFlags or MDL_MAPPED_TO_SYSTEM_VA;
>> writableAddress := MmMapLockedPages(mdl, KernelMode);
>> if (writableAddress <> nil) then
>> begin
>> oldirql := 0;
>>
>> KeInitializeSpinLock(@tempSpinLock);
>> fast_KfAcquireSpinLock(@tempSpinLock);
>> memcpy(writableAddress, lpSource, Length);
>> fast_KfReleaseSpinLock(@tempSpinLock, oldirql);
>>
>> MmUnmapLockedPages(writableAddress, mdl);
>> Result := STATUS_SUCCESS;
>>
>> end;
>> MmUnlockPages(mdl);
>> IoFreeMdl(mdl);
>> end;
>> end;
>>
>> Now my question is:
>> 1 why the methords mentioned above can let the memory be writable?
>> Does the functions change the propertries(like x86 CPU defined) of the
>> physical page of the memory? This refers to memory management and protection
>> mechanism of windows, one word can not classifies clearly.
>> 2 Will changed memory be writen to the disk image(not page file on the
>> disk)? If this is truth,then the disk image of the system key files(like
>> hal.dll and so on) may be destroyed(I assume the WFP is disabled)?
>>
>> Just for research purpose, so the more details supplied(don’t say the OS
>> do it, i do know cpu and os do it:)), the better i think. Any articles about
>> those aspect will be highly appreciated too.
>>
>> Thanks very much.
>> Ma
>>
>>
> —
> 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
>

FYI The code comes originally from here:

http://bbs.pediy.com/showthread.php?p=446341

Translated:

http://babelfish.yahoo.com/translate_url?doit=done&tt=url&intl=1&fr=bf-home&
trurl=http%3A%2F%2Fbbs.pediy.com%2Fshowthread.php%3Fp%3D446341&lp=zt_en&btnT
rUrl=Translate

Crispin.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Thursday, September 25, 2008 11:36
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Windows memory management and protection discuss

OK. I’ll bite - why are you doing this? Not just post code that isn’t what
you actually use, and ask for help with it, but why
chose Delphi?

mm

Carleton Ma wrote:

Of cource not. you means the code i paste, that’s not the real code in
the driver

2008/9/25 Pavel A. >
>
> You don’t really write drivers in Delphi, don’t you?
>
> --PA
>
>
>
> xxxxx@gmail.com mailto:xxxxx wrote:
>
> I have tried the following two methods,both of them can write
> read only memory.If i don’t not use the following methods, and
> try to write the memory(assume the system space memory like nt
> or hal data structure and so on), i got BSOD:
> Bug Check 0xBE: ATTEMPTED_WRITE_TO_READONLY_MEMORY
>
> Methord one:
> function WriteReadOnlyMemoryMark(lpDest, lpSource: Pointer;
> Length: Integer):
>
> NTSTATUS;
> var
> tempSpinLock: KSPIN_LOCK;
> oldirql: KIRQL;
> mdl: PMDL;
> writableAddress: Pointer;
> begin
> Result := STATUS_UNSUCCESSFUL;
> mdl := IoAllocateMdl(lpDest, Length, False, False, nil);
> if (mdl <> nil) then
> begin
> MmBuildMdlForNonPagedPool(mdl);
> MmProbeAndLockPages(mdl, KernelMode, IoWriteAccess);
> writableAddress := MmMapLockedPages(mdl, KernelMode);
> if (writableAddress <> nil) then
> begin
> oldirql := 0;
>
> KeInitializeSpinLock(@tempSpinLock);
> fast_KfAcquireSpinLock(@tempSpinLock);
> memcpy(writableAddress, lpSource, Length);
> fast_KfReleaseSpinLock(@tempSpinLock, oldirql);
>
> MmUnmapLockedPages(writableAddress, mdl);
> Result := STATUS_SUCCESS;
> end;
> MmUnlockPages(mdl);
> IoFreeMdl(mdl);
> end;
> end;
>
>
> Methord two:
>
> function WriteReadOnlyMemoryGates(lpDest, lpSource: Pointer;
> Length: Integer):
>
> NTSTATUS;
> var
> tempSpinLock: KSPIN_LOCK;
> oldirql: KIRQL;
> mdl: PMDL;
> writableAddress: Pointer;
> begin
> Result := STATUS_UNSUCCESSFUL;
> mdl := MmCreateMdl(nil, lpDest, Length);
> if (mdl <> nil) then
> begin
> MmBuildMdlForNonPagedPool(mdl);
> mdl^.MdlFlags := mdl^.MdlFlags or MDL_MAPPED_TO_SYSTEM_VA;
> writableAddress := MmMapLockedPages(mdl, KernelMode);
> if (writableAddress <> nil) then
> begin
> oldirql := 0;
>
> KeInitializeSpinLock(@tempSpinLock);
> fast_KfAcquireSpinLock(@tempSpinLock);
> memcpy(writableAddress, lpSource, Length);
> fast_KfReleaseSpinLock(@tempSpinLock, oldirql);
>
> MmUnmapLockedPages(writableAddress, mdl);
> Result := STATUS_SUCCESS;
>
> end;
> MmUnlockPages(mdl);
> IoFreeMdl(mdl);
> end;
> end;
>
> Now my question is:
> 1 why the methords mentioned above can let the memory be
writable?
> Does the functions change the propertries(like x86 CPU defined)
> of the physical page of the memory? This refers to memory
> management and protection mechanism of windows, one word can not
> classifies clearly.
> 2 Will changed memory be writen to the disk image(not page file
> on the disk)? If this is truth,then the disk image of the system
> key files(like hal.dll and so on) may be destroyed(I assume the
> WFP is disabled)?
>
> Just for research purpose, so the more details supplied(don’t
> say the OS do it, i do know cpu and os do it:)), the better i
> think. Any articles about those aspect will be highly
> appreciated too.
>
> Thanks very much.
> Ma
>
>
> —
> 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

Information from ESET NOD32 Antivirus, version of virus signature
database 3470 (20080925)


The message was checked by ESET NOD32 Antivirus.

http://www.eset.com</mailto:xxxxx>

> You don’t really write drivers in Delphi, don’t you?

IIRC, a couple of weeks ago someone actually managed to exactly this kind of thing. I really have no idea how he managed to set up his environment, but, according to the poster, he did it… I think he should share his “know-how” with Peter - after all, according to Peter’s article in the most recent issue of “NT Insider”, he has never really liked C, so that he must be quite interested in it…

Anton Bassov

Well, by all means… share the details!

If it gets us away from pointers, manually-managed allocations, and buffer overflows, I’m all for it!

Peter
OSR

According to Pavel,MM,and Peter and so on, then i paste the code i compiled in C language(i have said that pay attention to the Memory management related functions,again,i even don’t know the code i have pasted above is what language,just concern the functions it uses,then write the code in C,i really hope i don’t waste all your time to read so many replies while most has not concern with what i concern)

PMDL pMyMdl;
PVOID *pTheMmToWrite;

Methord one:
pMyMdl = IoAllocateMdl(pDesBuffer,DesLength,FALSE,FALSE,NULL);
if(!pMyMdl)
return STATUS_UNSUCCESSFUL;
MmBuildMdlForNonPagedPool(pMyMdl);

try
{

//
// Probe and lock the pages of this buffer in physical memory.
// You can specify IoReadAccess, IoWriteAccess or IoModifyAccess
// Always perform this operation in a try except block.
// MmProbeAndLockPages will raise an exception if it fails.
//
MmProbeAndLockPages(pMyMdl,KernelMode,IoWriteAccess);
}
except(EXCEPTION_EXECUTE_HANDLER)
{

//ntStatus = GetExceptionCode();
IoFreeMdl(pMyMdl);
//break;
}
pTheMmToWrite = MmMapLockedPages(pMyMdl,KernelMode);

//for testing purpose, no protection
memcpy(pTheMmToWrite, pSourceBuffer, Length);
MmUnmapLockedPages(pTheMmToWrite, mdl);
MmUnlockPages(pMyMdl);
IoFreeMdl(pMyMdl);

Methord two:
MmCreateMdl(pMyMdl, pDesBuffer, DesLength);
if(!MyMdl)
return STATUS_UNSUCCESSFUL;
MmBuildMdlForNonPagedPool(pMyMdl);

// Change the flags of the MDL
pMyMdl->MdlFlags = pMyMdl->MdlFlags | MDL_MAPPED_TO_SYSTEM_VA;

pTheMmToWrite = MmMapLockedPages(pMyMdl, KernelMode);

memcpy(pTheMmToWrite, pSourceBuffer, Length);
MmUnmapLockedPages(pTheMmToWrite, mdl);
MmUnlockPages(pMyMdl);
IoFreeMdl(pMyMdl);

That’s all. Thanks again for reply my question.
Looking forword your answers.

Ma

The code – in C, dephi, pascal or Tagalog, aside – I’m not sure I know what you’re asking.

If your asking: Can “read-only memory be read-write” the answer is: HUH?

If the memory is PHYSICALLY read-only, that is it’s in a ROM, then no. You can’t write to it no matter how hard you try. That’s why it’s called “Read Only Memory.”

If the memory is physically RAM in main memory, SOMEbody has to be able to write to it, right? OR else it would be, ah… empty and useless.

The read-only or read-write attribute is an attribute of how the memory is MAPPED, the VIEW onto the physical pages of memory, gained by a particular thread of processing. Given that the OS is what CONTROLS memory access (it’s the guy who’s responsible for deciding what parts of main memory are mapped read-write or read-only and for whom), it is entirely reasonable for the OS to be able to have write access to any main memory on the system.

Does that answer your question?

Peter
OSR

> Well, by all means… share the details!

[begin quote]

i did succeed in writing a simple readprocessmemory driver in delphi, with a fair amount of hacking i succeeded in compiling a valid .sys which didnt cause bsods.

[end quote]

This is all that we have (http://www.osronline.com/showThread.cfm?link=137424)…

If it gets us away from pointers, manually-managed allocations, and buffer overflows, I’m all for it!

Well, if you don’t like worrying about these things, why did you choose to become a driver writer, in the first place??? Sorry, but managed languages have been around for quite a while, so that if you find these things so annoying, you could have chosen to do, say, database development in VB…

Anton Bassov

Just to annoy you, Anton. No other reason. Just to annoy YOU. Or to explain my career development to you, so you can help me become successful, which is really the next best thing, isn’t it?

Peter
OSR

wrote in message news:xxxxx@ntdev…
> Well, by all means… share the details!
>

Here you go… the Delphi Driver Development Kit:
http://w-shadow.com/blog/2006/10/12/writing-drivers-in-delphi/

Once they considered out of the box support for this but they figured that
staying up to date with the DDK and translating all the related header files
was going to take too much time.

> If it gets us away from pointers, manually-managed allocations, and buffer
> overflows, I’m all for it!
>

That I think is going to be a disappointment. What I am expecting to work is
a very rudimentary subset of the Delphi languag, something like a 1:1
translation from C to Pascal. Not any of the fancy the fancy object oriented
features, its classes, properties, not even any of the native types such as
strings or anything that does automatic allocations.

Pointers can be passed by reference (var), but the way the compiler handles
them has always been causing trouble even in usermode when mapping to the
SDK. And buffer overflows… possibly. One advantage is that it’s a
strongly typed language which does not take much nonsense.

//Daniel

HI, Peter, Thanks, your answer is somewhat i looking for(I am talking about the Main physical memory access),but not specificly.

The read-only or read-write attribute is an attribute of how the memory is MAPPED, the VIEW onto the physical pages of memory, gained by a particular thread of processing. Given that the OS is what CONTROLS memory access (it’s the guy who’s responsible for deciding what parts of main memory are mapped read-write or read-only and for whom), it is entirely reasonable for the OS to be able to have write access to any main memory on the system.


Yes, the OS conctrols the memory mapped, then if the driver can remap the memory to another virtual address in system space and can change the access rights(how can it do this!but the above code do tell me the driver really can do this), that means the functions above can change the memory access right, cann’t it?
If the driver can change(it does can), then the change memory will be write back to the disk image? I am worried if a miss action driver really change the system structure that has been loaded to physical memory,will it be writen back to the disk, thus may even cause the system will not boot up next time?

thanks
Ma

xxxxx@resplendence.com wrote:

THANKS DANIEL…

That package set off my AV… People, heads up when downloading…

lol

wrote in message news:xxxxx@ntdev…
>> Well, by all means… share the details!
>>
>
> Here you go… the Delphi Driver Development Kit:
> http://w-shadow.com/blog/2006/10/12/writing-drivers-in-delphi/
>
> Once they considered out of the box support for this but they figured
> that staying up to date with the DDK and translating all the related
> header files was going to take too much time.
>
>> If it gets us away from pointers, manually-managed allocations, and
>> buffer overflows, I’m all for it!
>>
>
> That I think is going to be a disappointment. What I am expecting to
> work is a very rudimentary subset of the Delphi languag, something
> like a 1:1 translation from C to Pascal. Not any of the fancy the
> fancy object oriented features, its classes, properties, not even any
> of the native types such as strings or anything that does automatic
> allocations.
>
> Pointers can be passed by reference (var), but the way the compiler
> handles them has always been causing trouble even in usermode when
> mapping to the SDK. And buffer overflows… possibly. One advantage
> is that it’s a strongly typed language which does not take much nonsense.
>
> //Daniel
>
>
>
> —
> 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
>

> If the driver can change(it does can), then the change memory will be write back to the disk image?

Only if you are speaking about the mapped file that got mapped as data section. However, all executable code for UM apps is mapped as a code section that does not get flushed to the disk even if it gets changed - otherwise, any run of a program would screw up its executable image on the disk. When it comes to drivers, they get completely loaded into RAM without being backed up by a section (code that is marked as pageable will be backed up by the pagefile, rather than mapped section). This is why you can modify/replace/delete driver image on the disk while the driver is loaded, i.e. something you cannot do with an app…

Anton Bassov