Windows 8, hook DLL causing memory access exception

[Nathan Brown]

Hello,

I was trying to use tup on Windows 8 with the MinGW compilers and kept
having the commands crash (gcc, as, ld) under tup. When I ran the
same command manually, no problems... Here's an example message from
the crash dump:

Process Architecture: x86
Exception Code: 0xC0000005
Exception Information: The thread tried to read from or write to a
virtual address for which it does not have the appropriate access.

I started debugging it, and traced it to the tup-dllinject.dll:

Call Stack
----------
... more ...
ntdll.dll!_KiUserExceptionDispatcher@8 () Unknown
KernelBase.dll!_WideCharToMultiByte@32 () Unknown
> tup-dllinject.dll!unicode_to_ansi(_UNICODE_STRING * uni) Line 654 C
tup-dllinject.dll!NtCreateFile_hook(void * * FileHandle, unsigned
long DesiredAccess, _OBJECT_ATTRIBUTES * ObjectAttributes, void *
IoStatusBlock, _LARGE_INTEGER * AllocationSize, unsigned long
FileAttributes, unsigned long ShareAccess, unsigned long
CreateDisposition, unsigned long CreateOptions, void * EaBuffer,
unsigned long EaLength) Line 685 C
KernelBase.dll!_CreateFileInternal@24 () Unknown
KernelBase.dll!_CreateFileW@28 () Unknown
KernelBase.dll!_BasepLoadLibraryAsDataFileInternal@20 () Unknown
KernelBase.dll!_BasepLoadLibraryAsDataFile@20 () Unknown
KernelBase.dll!_LoadLibraryExW@12 () Unknown
KernelBase.dll!_ConvertTimeZoneMuiString@8 () Unknown
KernelBase.dll!_ConvertTimeZoneMuiStrings@12 () Unknown
KernelBase.dll!_GetTimeZoneInformation@4 () Unknown
msvcrt.dll!___tzset () Unknown
msvcrt.dll!___tzset () Unknown
msvcrt.dll!___loctotime32_t () Unknown
msvcrt.dll!__stat32 () Unknown
gcc.exe!00401dcc() Unknown
.... more ...

(Yes, I recompiled the DLL with Microsoft's C++ compiler to get debug
info).

I looked into it and it appears that WideCharToMultiByte doesn't quite
work as documented when a source size is passed in. It's reading past
the declared end of the source unicode string and hitting not
accessible memory. Since the string is coming from kernel memory (to
the CreateFile hook), they might have tightened the amount of memory
open in Windows 8, and that's why I am seeing it.

I can demonstrate the issue with crash test code: https://gist.github.com/2467960

I also ran my test program on Windows 7, and it crashes the same way
there too. Can you guys look at and run my gist and tell me if I
proved that WideCharToMultiByte has a bug?

Any ideas on an alternative unicode_to_ansi implementation to get
around the issue with WideCharToMultiByte?

Nathan Brown

[James McKaskill]

On Sun, Apr 22, 2012 at 21:35, Nathan Brown <nat...@nkbrown.us> wrote:
> I looked into it and it appears that WideCharToMultiByte doesn't quite
> work as documented when a source size is passed in. It's reading past
> the declared end of the source unicode string and hitting not
> accessible memory. Since the string is coming from kernel memory (to
> the CreateFile hook), they might have tightened the amount of memory
> open in Windows 8, and that's why I am seeing it.

With the UNICODE_STRING, what's the value of uni->MaximumLength.
Also is this hitting the first or second call to MultByteToWideChar?

> Any ideas on an alternative unicode_to_ansi implementation to get
> around the issue with WideCharToMultiByte?

If you're willing to restrict to just UTF8, it's pretty easy to write
one... Otherwise I wouldn't really recommend pulling in icu or another
full encoding conversion library into the injection dll.

PS: Dang, it shows how often I post here.... I had to go and change
the subscription over from my old email address.

-- James

[Nathan Brown]

Hi James,

On Apr 22, 9:43 pm, James McKaskill <ja...@foobar.co.nz> wrote:

> With the UNICODE_STRING, what's the value of uni->MaximumLength.
> Also is this hitting the first or second call to MultByteToWideChar?

It's hitting the second call to WideCharToMultiByte.

Hmm, just realized that the input parameter, cchWideChar, is
characters, while UNICODE_STRING.Length is bytes. The code currently
is treating the two as the same, passing Length into cchWideChar.
This would explain why the output len in the first call is returning
the same value passed into the cchWideChar value.

I hadn't caught that earlier, thinking they were both bytes.

> If you're willing to restrict to just UTF8, it's pretty easy to write
> one... Otherwise I wouldn't really recommend pulling in icu or another
> full encoding conversion library into the injection dll.

In my attempted fix, I null terminated the string and then passed -1
into cchWideChar for both the first and second call (still using
WideCharToMultiByte), but probably changing it to a count of
characters from bytes will fix it.

Nathan

[Mike Shal]

Hi Nathan,

First of all, thanks for the details report!

On Mon, Apr 23, 2012 at 10:52 AM, Nathan Brown <nat...@nkbrown.us> wrote:
> Hi James,
>
> On Apr 22, 9:43 pm, James McKaskill <ja...@foobar.co.nz> wrote:
>
>> With the UNICODE_STRING, what's the value of uni->MaximumLength.
>> Also is this hitting the first or second call to MultByteToWideChar?
>
> It's hitting the second call to WideCharToMultiByte.
>
> Hmm, just realized that the input parameter, cchWideChar, is
> characters, while UNICODE_STRING.Length is bytes.  The code currently
> is treating the two as the same, passing Length into cchWideChar.
> This would explain why the output len in the first call is returning
> the same value passed into the cchWideChar value.
>
> I hadn't caught that earlier, thinking they were both bytes.

That does indeed look wrong. I am a bit confused about a few things though:

1) Under what circumstances is it crashing for you? I test on Windows
7 (64-bit), and it seems that the UNICODE_STRINGS are nul-terminated,
though sometimes after the Length field (but always before
MaximumLength, I think?). Either way it should be fixed, but I'm
wondering if the test cases need to be expanded.

2) Do you (or anyone else) know what the point of the uni->Length
field is? It seems we can't use it directly in WideCharToMultiByte,
nor could it be used directly as an index bound for uni->Buffer (ie:
for(x=0; x<uni->Length; x++) uni->Buffer[x] would overrun as well),
nor can we use it in wcsnlen() to get the actual character count. So
what good is it?

If there is nothing usable in 2), then I think your proposed patch
makes the most sense. The Nt* functions that use this seem to be
called with the same UNICODE_STRING buffer, but different Length
fields to truncate the path. For example, a buffer might be:
"\??\C:\cygwin\tmp\ccaJ9Afo.c", and then called twice with two
different lengths, so that we get "\??\C:\cygwin\tmp\" the first time
and "\??\C:\cygwin\tmp\ccaJ9Afo.c" the second time. We definitely
can't rely on it to be nul-terminated in the right spot, and if the
Length field is useless then it needs to be nul-terminated before
using WideCharToMultiByte...

>
>> If you're willing to restrict to just UTF8, it's pretty easy to write
>> one... Otherwise I wouldn't really recommend pulling in icu or another
>> full encoding conversion library into the injection dll.
>
> In my attempted fix, I null terminated the string and then passed -1
> into cchWideChar for both the first and second call (still using
> WideCharToMultiByte), but probably changing it to a count of
> characters from bytes will fix it.

I guess this what I'm wondering in 2) above - is there a way to do
this without the temporary nul-terminated buffer?

Thanks again,
-Mike

[Mike Shal]

Hi Nathan,

After looking at it again, I think we can go from bytes to characters
just by dividing by sizeof(wchar_t), since the UNICODE_STRING is 2
bytes / character. (Correct me if I'm wrong). Then we use
WideCharToMultiByte as before to get the length required in UTF8. Does
the attached patch work for you? I still don't know why it is crashing
for you but not for me. Are you on 32 or 64bit?

Thanks,
-Mike

[Nathan Brown]

On May 1, 5:33 pm, Mike Shal <mar...@gmail.com> wrote:
> After looking at it again, I think we can go from bytes to characters
> just by dividing by sizeof(wchar_t), since the UNICODE_STRING is 2
> bytes / character. (Correct me if I'm wrong). Then we use
> WideCharToMultiByte as before to get the length required in UTF8. Does
> the attached patch work for you? I still don't know why it is crashing
> for you but not for me. Are you on 32 or 64bit?

Dividing by 2 is what I ended up doing and it works fine.

The demo code I had forces the crash by making a very narrow valid
memory window for the WideCharToMultiByte function to read from. In
the demo code, even reading the bytes to far past the buffer cause the
crash.

This was something that was happening occasionally in Windows 8, 64
bit. It would happen some of the time on a rather long build, and it
would depend on the configuration at that moment. Once it happened
though, it would happen at the same spot every time I ran it, so
that's how I was able to debug it.

In your patch, I don't understand why you switched from CP_ACP (ASCII)
to CP_UTF8. What is the requirement for handle_file()? I did try the
patch the way you have it and it's working.

I don't have a Linux machine setup to do these builds and had to hack
back in the stuff (headers, #defines, etc.) required to build just
the .dll in Visual Studio (at command prompt). The advantage of this
was that I also got reasonable debugging info.

[Mike Shal]

On Wed, May 2, 2012 at 8:47 PM, Nathan Brown <nat...@nkbrown.us> wrote:
> On May 1, 5:33 pm, Mike Shal <mar...@gmail.com> wrote:
>> After looking at it again, I think we can go from bytes to characters
>> just by dividing by sizeof(wchar_t), since the UNICODE_STRING is 2
>> bytes / character. (Correct me if I'm wrong). Then we use
>> WideCharToMultiByte as before to get the length required in UTF8. Does
>> the attached patch work for you? I still don't know why it is crashing
>> for you but not for me. Are you on 32 or 64bit?
>
> Dividing by 2 is what I ended up doing and it works fine.

Ok, this should be in master now. Let me know if it is still causing problems.

>
> The demo code I had forces the crash by making a very narrow valid
> memory window for the WideCharToMultiByte function to read from.  In
> the demo code, even reading the bytes to far past the buffer cause the
> crash.
>
> This was something that was happening occasionally in Windows 8, 64
> bit.  It would happen some of the time on a rather long build, and it
> would depend on the configuration at that moment.  Once it happened
> though, it would happen at the same spot every time I ran it, so
> that's how I was able to debug it.
>
> In your patch, I don't understand why you switched from CP_ACP (ASCII)
> to CP_UTF8.  What is the requirement for handle_file()?  I did try the
> patch the way you have it and it's working.

I think tup should be able to support UTF8 filenames since SQLite uses
that by default. I added a test case for it, but it currently doesn't
work on Windows (need some extra UTF16 <-> UTF8 conversions), or OSX
(which mangles certain UTF8 characters). If the filename is just 7-bit
ascii I think both conversions are the same anyway, right?

>
> I don't have a Linux machine setup to do these builds and had to hack
> back in the stuff (headers, #defines, etc.) required to build just
> the .dll in Visual Studio (at command prompt).  The advantage of this
> was that I also got reasonable debugging info.

Is the debugging you used specific to Visual Studio? Maybe I could
have a release and debug .zip files for Windows if I can build it with
mingw from Linux.

Thanks,
-Mike

[Tim Cuthbertson]

On Wednesday, May 9, 2012 6:30:48 AM UTC+10, mar...@gmail.com wrote:

On Wed, May 2, 2012 at 8:47 PM, Nathan Brown <nat...@nkbrown.us> wrote:
> On May 1, 5:33 pm, Mike Shal <mar...@gmail.com> wrote:
>> After looking at it again, I think we can go from bytes to characters
>> just by dividing by sizeof(wchar_t), since the UNICODE_STRING is 2
>> bytes / character. (Correct me if I'm wrong). Then we use
>> WideCharToMultiByte as before to get the length required in UTF8. Does
>> the attached patch work for you? I still don't know why it is crashing
>> for you but not for me. Are you on 32 or 64bit?
>
> Dividing by 2 is what I ended up doing and it works fine.

Ok, this should be in master now. Let me know if it is still causing problems.

 

I'm getting what looks like the same issue, although unfortunately I don't know how to compile with debug symbols in order to check thoroughly. I'm getting the following crash info:

Problem signature:
  Problem Event Name:    APPCRASH
  Application Name:    python.exe
  Application Version:    0.0.0.0
  Application Timestamp:    4cf14060
  Fault Module Name:    tup-dllinject.dll
  Fault Module Version:    0.0.0.0
  Fault Module Timestamp:    501c1da4
  Exception Code:    c0000005
  Exception Offset:    00001700
  OS Version:    6.1.7601.2.1.0.256.4
  Locale ID:    3081
  Additional Information 1:    0a9e
  Additional Information 2:    0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:    0a9e
  Additional Information 4:    0a9e372d3b4ad19135b953a78882e789

using the latest tup (tup v0.6-240-gc7160c8)

[Mike Shal]

Hi Tim,

What version of Windows and python are you using? And what does your
Tupfile look like? I tried python 2.6.8 on Win7 (64-bit) and was able
to write a file using a python script:

$ cat ok.py
#! /usr/bin/python
f = open('outfile', 'w')
f.write("hello world\n")
f.close()
$ cat Tupfile
: |> sh -c 'python ok.py' |> outfile
$ tup upd
[ tup ] [0.000s] Scanning filesystem...
[ tup ] [0.375s] Reading in new environment variables...
[ tup ] [0.375s] No Tupfiles to parse.
[ tup ] [0.375s] No files to delete.
[ tup ] [0.375s] Executing Commands...
100% 1) [0.109s] sh -c 'python ok.py'
[ tup ] [0.500s] Updated.

-Mike

[Tim Cuthbertson]

Hi Mike,

Sorry for the lack of details. My python build script is big and unwieldy, but thankfully I found a minimal example that exhibits the same problem - it has something to do with child processes, I guess:

$ cat ok.py
#! /usr/bin/python

import subprocess
subprocess.Popen(["where", "find"]).wait()

f = open('outfile', 'w')
f.write("hello world\n")
f.close()

(using the same tupfile as yours)

Python 2.7.1, Windows 7 sp1 (64-bit)

I've had the same problem running `msbuild` rather than python, so I don't think it's python-specific.

Cheers,
 - Tim.

[Mike Shal]

On Tue, Aug 14, 2012 at 1:21 AM, Tim Cuthbertson <gfx...@gmail.com> wrote:
> Hi Mike,
>
> Sorry for the lack of details. My python build script is big and unwieldy,
> but thankfully I found a minimal example that exhibits the same problem - it
> has something to do with child processes, I guess:
>
>
> $ cat ok.py
> #! /usr/bin/python
> import subprocess
> subprocess.Popen(["where", "find"]).wait()
>
> f = open('outfile', 'w')
> f.write("hello world\n")
> f.close()
>
> (using the same tupfile as yours)
>
> Python 2.7.1, Windows 7 sp1 (64-bit)
>
> I've had the same problem running `msbuild` rather than python, so I don't
> think it's python-specific.
>
> Cheers,
> - Tim.

Hi Tim,

Sorry for the delay - been travelling and getting caught up on non-tup
related things.

Your example works for me with Cygwin python (2.6.8), which is a
32-bit executable. However when I run with python 2.7.3 (64-bit
executable) from the official msi installer, it fails to detect the
output file. It seems the GetThreadContext() call in the DLL injection
code is failing because it is a 64-bit exe, so tup doesn't end up
watching the python executable. I haven't been able to reproduce the
crash though, so I'm not sure if this problem is related. Can you
check to see if your python.exe is 32-bit or 64-bit? If it's 64-bit,
I'll have to look into what it will take to get tup to support those.
Maybe it just needs to be compiled as 64-bit itself...

Thanks,
-Mike

[Tim Cuthbertson]

Thanks Mike,

My python.exe is actually a 32-bit regular windows exe (from the MSI
installer, not from cygwin).

[Mike Shal]

I can't reproduce this with the 32-bit python msi installer either :(.
Is anyone else having problems running programs that execute
subprocesses on Windows? If so maybe we can find out what's common (or
why my Win-7 install is different).

-Mike

[Nathan Brown]

I'm still having problems running tup on Windows 8.  Some applications hook correctly, and others don't.  For example, I'm trying to track down a problem right now where a compiled application is spawning a sub-process through _spawnvp in msvcrt.dll.  the stack of calls hits CreateProcessA in KernelBase.dll, but KernelBase.dll is never patched.  From there it goes to ntdll.dll, never through advapi32.dll or kernel32.dll.  The create process is never intercepted, so the spawned process is never hooked.

The Sysinternals Process Monitor can show the stack of file creations and process events.

[Mike Shal]

On Fri, Sep 14, 2012 at 2:01 AM, Nathan Brown <nat...@nkbrown.us> wrote:
> I'm still having problems running tup on Windows 8. Some applications hook
> correctly, and others don't. For example, I'm trying to track down a
> problem right now where a compiled application is spawning a sub-process
> through _spawnvp in msvcrt.dll. the stack of calls hits CreateProcessA in
> KernelBase.dll, but KernelBase.dll is never patched. From there it goes to
> ntdll.dll, never through advapi32.dll or kernel32.dll. The create process
> is never intercepted, so the spawned process is never hooked.
>
> The Sysinternals Process Monitor can show the stack of file creations and
> process events.

Are the processes that don't hook 64-bit? You can check by using cygwin's file:

32-test.exe: PE32 executable (console) Intel 80386, for MS Windows
64-test.exe: PE32+ executable (console) x86-64, for MS Windows

(I'm sure there's some Windows-y way to check too)

The 64-bit ones won't work at the moment. I'm curious if the issues
you are seeing on Win8 are because more things are 64-bit, or if
there's some other issue (seems you are alluding to a possibly
different DLL structure).

If anyone is familiar with WOW64 and using 32-bit/64-bit processes
together in Windows, I could probably use some help. Currently I'm not
sure if I need to compile tup as 64-bit to handle 64-bit processes at
all, or if there's some way to do it with a 32-bit tup, or if I need
two separate DLLs to inject, or what...

-Mike

[Nathan Brown]

Hi Mike,

The processes are all 32-bit (on a 64-bit computer though).  The DLL architecture change has changed in Windows 7 and then changed more in Windows 8.  Here is some information on it:

http://www.nirsoft.net/articles/windows_7_kernel_architecture_changes.html 

http://j00ru.vexillium.org/dump/win7_vs_win8/export%20lists/KernelBase.dll.html 

On an older version of TUP (before hot-patching) I tried hooking CreateProcess on KernelBase, and I think that sometimes worked, but then would get double hooked when a program went through a different channel (like advapi32 or kenel32).  I don't totally understand it right now, and I've only gotten the DLL to be debuggable in Windows, not the rest of TUP.

My changes to TUP changes to allow compile on windows and also a visual studio project.

The stack from Process Monitor for a process (LCC.exe) that is being created and the DLL is injected correctly looks like this (Note, the injection isn't because of a hook but because TUP is directly creating the process):

0 fltmgr.sys fltmgr.sys + 0x1844 0xfffff8800174c844 C:\Windows\system32\drivers\fltmgr.sys

1 fltmgr.sys FltIsCallbackDataDirty + 0x9ec 0xfffff8800174da6c C:\Windows\system32\drivers\fltmgr.sys

2 fltmgr.sys fltmgr.sys + 0x12e9 0xfffff8800174c2e9 C:\Windows\system32\drivers\fltmgr.sys

3 fltmgr.sys fltmgr.sys + 0x109e 0xfffff8800174c09e C:\Windows\system32\drivers\fltmgr.sys

4 ntoskrnl.exe IopGetSetSecurityObject + 0x185 0xfffff8031d3fe225 C:\Windows\system32\ntoskrnl.exe

5 ntoskrnl.exe ObpGetObjectSecurity + 0x161 0xfffff8031d47b391 C:\Windows\system32\ntoskrnl.exe

6 ntoskrnl.exe ObCheckObjectAccess + 0x49 0xfffff8031d47bb69 C:\Windows\system32\ntoskrnl.exe

7 ntoskrnl.exe ObpCreateHandle + 0x58d 0xfffff8031d45c27d C:\Windows\system32\ntoskrnl.exe

8 ntoskrnl.exe ObOpenObjectByPointer + 0x1e5 0xfffff8031d43f0c5 C:\Windows\system32\ntoskrnl.exe

9 ntoskrnl.exe AhcValidateAndGetParameters + 0x12e 0xfffff8031d42a016 C:\Windows\system32\ntoskrnl.exe

10 ntoskrnl.exe NtApphelpCacheControl + 0x166 0xfffff8031d4895dd C:\Windows\system32\ntoskrnl.exe

11 ntoskrnl.exe KiSystemServiceCopyEnd + 0x13 0xfffff8031d08d053 C:\Windows\system32\ntoskrnl.exe

12 ntdll.dll NtApphelpCacheControl + 0xa 0x7fdd931306a C:\Windows\System32\ntdll.dll

13 wow64.dll whNtApphelpCacheControl + 0x2d8 0x7713b000 C:\Windows\System32\wow64.dll

14 wow64.dll Wow64SystemServiceEx + 0xd7 0x7712c363 C:\Windows\System32\wow64.dll

15 wow64cpu.dll ServiceNoTurbo + 0xb 0x771125a7 C:\Windows\System32\wow64cpu.dll

16 wow64.dll RunCpuSimulation + 0xa 0x7712c4f6 C:\Windows\System32\wow64.dll

17 wow64.dll Wow64LdrpInitialize + 0x435 0x7712b8f5 C:\Windows\System32\wow64.dll

18 ntdll.dll _LdrpInitialize + 0xde 0x7fdd938d6af C:\Windows\System32\ntdll.dll

19 ntdll.dll LdrInitializeThunk + 0xe 0x7fdd932c1ae C:\Windows\System32\ntdll.dll

20 ntdll.dll NtApphelpCacheControl + 0xc 0x771b1228 C:\Windows\SysWOW64\ntdll.dll

21 kernel32.dll BaseCheckDetectionMethods + 0x143 0x748fa99d C:\Windows\SysWOW64\kernel32.dll

22 kernel32.dll BaseCheckElevation + 0x8b 0x748fa712 C:\Windows\SysWOW64\kernel32.dll

23 KernelBase.dll CreateProcessInternalW + 0x1e50 0x770411ef C:\Windows\SysWOW64\KernelBase.dll

24 KernelBase.dll CreateProcessInternalA + 0x2bf 0x7708db89 C:\Windows\SysWOW64\KernelBase.dll

25 KernelBase.dll CreateProcessA + 0x2c 0x7708dc95 C:\Windows\SysWOW64\KernelBase.dll

26 tup.exe tup.exe + 0x217e9 0x4217e9 C:\dev\Learning\lcc\build\tup\tup.exe

27 tup.exe tup.exe + 0x1da5b 0x41da5b C:\dev\Learning\lcc\build\tup\tup.exe

28 tup.exe tup.exe + 0x754c6 0x4754c6 C:\dev\Learning\lcc\build\tup\tup.exe

29 kernel32.dll BaseThreadInitThunk + 0xe 0x74908543 C:\Windows\SysWOW64\kernel32.dll

30 ntdll.dll __RtlUserThreadStart + 0x72 0x771cac69 C:\Windows\SysWOW64\ntdll.dll

31 ntdll.dll _RtlUserThreadStart + 0x1b 0x771cac3c C:\Windows\SysWOW64\ntdll.dll

The stack from a process (RCC.exe, when created from the above created process, LCC.exe) that is being created but not hooking correctly looks like this (tup-dllinject.dll is a listed module in LCC.exe, so it was injected):

0 fltmgr.sys FltpPerformPreCallbacks + 0x324 0xfffff8800174c844 C:\Windows\system32\drivers\fltmgr.sys

1 fltmgr.sys FltpPassThroughInternal + 0x8c 0xfffff8800174da6c C:\Windows\system32\drivers\fltmgr.sys

2 fltmgr.sys FltpCreate + 0x339 0xfffff88001778349 C:\Windows\system32\drivers\fltmgr.sys

3 ntoskrnl.exe IopParseDevice + 0x77b 0xfffff8031d45e05b C:\Windows\system32\ntoskrnl.exe

4 ntoskrnl.exe ObpLookupObjectName + 0x7a1 0xfffff8031d45ac5d C:\Windows\system32\ntoskrnl.exe

5 ntoskrnl.exe ObOpenObjectByName + 0x258 0xfffff8031d4602b8 C:\Windows\system32\ntoskrnl.exe

6 ntoskrnl.exe IopCreateFile + 0x37c 0xfffff8031d471ebe C:\Windows\system32\ntoskrnl.exe

7 ntoskrnl.exe NtOpenFile + 0x58 0xfffff8031d44821c C:\Windows\system32\ntoskrnl.exe

8 ntoskrnl.exe KiSystemServiceCopyEnd + 0x13 0xfffff8031d08d053 C:\Windows\system32\ntoskrnl.exe

9 ntoskrnl.exe KiServiceLinkage 0xfffff8031d092230 C:\Windows\system32\ntoskrnl.exe

10 ntoskrnl.exe NtCreateUserProcess + 0x364 0xfffff8031d42fcc4 C:\Windows\system32\ntoskrnl.exe

11 ntoskrnl.exe KiSystemServiceCopyEnd + 0x13 0xfffff8031d08d053 C:\Windows\system32\ntoskrnl.exe

12 ntdll.dll NtCreateUserProcess + 0xa 0x7fdd931371b C:\Windows\System32\ntdll.dll

13 wow64.dll Wow64NtCreateUserProcess + 0x13a 0x7712ae0a C:\Windows\System32\wow64.dll

14 wow64.dll whNtCreateUserProcess + 0x799 0x77141a91 C:\Windows\System32\wow64.dll

15 wow64.dll Wow64SystemServiceEx + 0xd7 0x7712c363 C:\Windows\System32\wow64.dll

16 wow64cpu.dll ServiceNoTurbo + 0xb 0x771125a7 C:\Windows\System32\wow64cpu.dll

17 wow64.dll RunCpuSimulation + 0xa 0x7712c4f6 C:\Windows\System32\wow64.dll

18 wow64.dll Wow64LdrpInitialize + 0x435 0x7712b8f5 C:\Windows\System32\wow64.dll

19 ntdll.dll LdrpInitializeProcess + 0x1521 0x7fdd93651a7 C:\Windows\System32\ntdll.dll

20 ntdll.dll _LdrpInitialize + 0x1565e 0x7fdd9341826 C:\Windows\System32\ntdll.dll

21 ntdll.dll LdrInitializeThunk + 0xe 0x7fdd932c1ae C:\Windows\System32\ntdll.dll

22 ntdll.dll NtCreateUserProcess + 0xc 0x771b18d8 C:\Windows\SysWOW64\ntdll.dll

23 KernelBase.dll CreateProcessInternalW + 0x116d 0x77040d17 C:\Windows\SysWOW64\KernelBase.dll

24 KernelBase.dll CreateProcessInternalA + 0x2bf 0x7708db89 C:\Windows\SysWOW64\KernelBase.dll

25 KernelBase.dll CreateProcessA + 0x2c 0x7708dc95 C:\Windows\SysWOW64\KernelBase.dll

26 msvcrt.dll _dospawn + 0x1a1 0x76224d99 C:\Windows\SysWOW64\msvcrt.dll

27 msvcrt.dll _spawnve + 0x28d 0x76223c84 C:\Windows\SysWOW64\msvcrt.dll

28 msvcrt.dll _spawnve + 0x126 0x76223b1d C:\Windows\SysWOW64\msvcrt.dll

29 msvcrt.dll _spawnvpe + 0x82 0x76223d44 C:\Windows\SysWOW64\msvcrt.dll

30 msvcrt.dll _spawnvp + 0x15 0x76223cb8 C:\Windows\SysWOW64\msvcrt.dll

31 lcc.exe lcc.exe + 0x1ea1 0x401ea1 C:\dev\Learning\lcc\build\mingw\lcc.exe

32 lcc.exe lcc.exe + 0x1fd8 0x401fd8 C:\dev\Learning\lcc\build\mingw\lcc.exe

33 lcc.exe lcc.exe + 0x2633 0x402633 C:\dev\Learning\lcc\build\mingw\lcc.exe

34 lcc.exe lcc.exe + 0x25dd 0x4025dd C:\dev\Learning\lcc\build\mingw\lcc.exe

35 lcc.exe lcc.exe + 0x19df 0x4019df C:\dev\Learning\lcc\build\mingw\lcc.exe

36 lcc.exe lcc.exe + 0x10b9 0x4010b9 C:\dev\Learning\lcc\build\mingw\lcc.exe

37 lcc.exe lcc.exe + 0x1284 0x401284 C:\dev\Learning\lcc\build\mingw\lcc.exe

38 kernel32.dll BaseThreadInitThunk + 0xe 0x74908543 C:\Windows\SysWOW64\kernel32.dll

39 ntdll.dll __RtlUserThreadStart + 0x72 0x771cac69 C:\Windows\SysWOW64\ntdll.dll

40 ntdll.dll _RtlUserThreadStart + 0x1b 0x771cac3c C:\Windows\SysWOW64\ntdll.dll

Nathan Brown

[Zahary Karadjov]

Mike, my understanding is that WriteProcessMemory is possible from 64-bit process 

to 32-bit process, but not the other way around so tup needs to be compiled in 64-bit.

The injected DLL itself should match the architecture of the target executable so we

need 2 separate builds of the DLL to be distributed with tup.