VirtualAlloc

NTDEV
1

This is an experiment, to create a test tool for a client in security
business…

OS, Win 7 x86 (or others as well, but lets stick to this) all service packs
installed (doesnt matter)

what I am trying to do:
inject memory into another process, in this case always notepad.exe

Logic used:

  1. OpenProcess API used to open a running notepad.exe (we are admin)
  2. once we get HPROCESS use that to do a virtualAllocEx inside notepad’s
    address space.
    VirtualAllocEx is called with the lpAddress = NULL.
  3. Using getprocaddress grab the address of NtWriteVirtualMemory and then
    write to the memory returned by VirtualAllocEx.

All work fine. I am able to over write the memory I created. However
something isnt right, hence this thread.

After a successful over write (this is what the security software is
supposed to stop, in this case it is disabled and hence the overwrite is
possible) we use TerminateProcess api to kill notepad. It should have died,
but it doesnt. TerminateProcess is async, so it returns immidiately (after
scheduling an APC) so we wait on it.

What we see is that notepad stays alive a long time, like a real long time
(10 mins).

I did some initial debugging, my hunch was the apc isnt being dleivered to
notepad, probably because the process is corrupted or it is waiting for
something (lock? event?) in the kernel.

Win7 x86 (this is why i said lets stick to this os for the time) notepad
proces is a single threaded app (I dont know why a GUI app will be single
threaded, looks like notepad is really rudimentary), if my assumption that
we corrupted the thread in the injection process was rght then the process
should have crashed, thrown an exception or some thing of hte sort, but the
process is fine, in fact if I press the close icon (X) it shuts down
immediately, but TerminateProcess doesnt respond. that leads to the second
assumption is it waiting in the kernel? if so on what?

i havent debugged this entirely yet, but before i dig into it wanted to
know if we are doing something obviously wrong, it shouldnt be as this is a
simple enough case.

the other question is, when calling virtualallocex with the second param as
null, does it allocate memory pages i na region which is somehow
unstabelizing the process? If so I do not understand how the (X) icon
closes it, because that will post a WM_QUIT and if the main thread is
themessage processor (since tehre is one thread) and that is hung/corrupt
then it doesnt explain that…

any ideas?

-Al

2

On May 8, 2017, at 9:58 PM, A P > wrote:

After a successful over write (this is what the security software is supposed to stop, in this case it is disabled and hence the overwrite is possible) we use TerminateProcess api to kill notepad. It should have died, but it doesnt. TerminateProcess is async, so it returns immidiately (after scheduling an APC) so we wait on it.

What we see is that notepad stays alive a long time, like a real long time (10 mins).
…
Win7 x86 (this is why i said lets stick to this os for the time) notepad proces is a single threaded app (I dont know why a GUI app will be single threaded, looks like notepad is really rudimentary)

Of course it is. The source code used to be part of the SDK. The application is literally nothing more than a standard edit control, with a few menu event handlers to do cut and paste.

You shouldn’t be surprised by it being single-threaded. All UI activity has to be done in the main thread, so almost all UI-intensive applications are single-threaded. That’s actually true in every major operating system today.
—
Tim Roberts, xxxxx@probo.commailto:xxxxx
Providenza & Boekelheide, Inc.</mailto:xxxxx>

3

Can you elaborate on “notepad stays alive a long time” ?

Did you mean that you observed a notepad process in the process list shown by WinDBG in “Kernel Debug” mode or in the process list shown by TaskManager or Notepad GUI was alive?

4

the process is completely alive, responsive, taking user inputs etc(this is
expected, as we alocated pages in its heap and injected data into that, and
didnt clobber the process), but why TerminateProcess doesnt work is the
question

On Tue, May 9, 2017 at 6:37 AM, wrote:

> Can you elaborate on “notepad stays alive a long time” ?
>
> Did you mean that you observed a notepad process in the process list shown
> by WinDBG in “Kernel Debug” mode or in the process list shown by
> TaskManager or Notepad GUI was alive?
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

5

Are you sure TerminateProcess is successful ?

TerminateProcess calls NtTerminateProcess. This system call walks the thread list of the process and stops each thread.

Why do you think an APC is queued ? The disas does not contain any occurrence of the Apc acronym.

J. S.

6

@johns.stadt my understanding was that to terminate a process(threads) you
need an APC? I was going off that assumption without verifying it. I
realize there are gaps in my knowledge. Would you mind elaborating on the
topic please.

On Tue, May 9, 2017 at 1:03 PM, xxxxx@outlook.com <
xxxxx@outlook.com> wrote:

Are you sure TerminateProcess is successful ?

TerminateProcess calls NtTerminateProcess. This system call walks the
thread list of the process and stops each thread.

Why do you think an APC is queued ? The disas does not contain any
occurrence of the Apc acronym.

J. S.

NTDEV is sponsored by OSR

Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

7

Assuming that APC is required to terminate a thread was a correct one.

00 nt!PspExitThread
01 nt!KiSchedulerApcTerminate
02 nt!KiDeliverApc
03 nt!KiInitiateUserApc
04 nt!KiStartUserThread
05 nt!KiStartUserThreadReturn

The stack is for Win 10 but it is the same on Win 7.

8

A Notepad thread stack while being terminated by Task Manager

00 nt!PspExitThread
01 nt!KiSchedulerApcTerminate
02 nt!KiDeliverApc
03 nt!KiInitiateUserApc
04 nt!KiSystemServiceExit
05 ntdll!NtWaitForWorkViaWorkerFactory
06 ntdll!TppWorkerThread
07 KERNEL32!BaseThreadInitThunk
08 ntdll!RtlUserThreadStart

9

This api is simple :

  1. The call is successful and the process is terminated when the api returns. The api doesn’t return when the current process is being terminated.
  2. The call fails and GetLastError should help you.
    J. S.
10

With what arguments do you call OpenProcess?

11

Also, why do you bother with finding address of NtWriteVirtualMemory, when you can simply call WriteProcessMemory?

12

Slava is right and threads are terminated with an APC. So the assumption that the process is terminated on api return is incorrect.

Thank you Slava.

J. S.