This PR fixes several things related to threads emulation:
1. Support `SameTebFlags.InitialThread`
This flag is needed to support emulation of .net executables (not yet
fully supported) that don't have an entry point set in `PE` header. This
applies to both `PE32` and `PE64` executables. If `InitialThread` is set
the loader substitutes an entry point of the .net executable with
`mscoree.dll!_CorExeMain`.
2. Fix static thread local storage for `WOW64`
This fix resolves `shell32.dll` initialization on `WOW64`. This fix also
uses correct structure and field names that are obtained from the
corresponding `.pdb` files.
3. Fix dynamic thread local storage for `WOW64`
4. Fix setting argument of a `WOW64` thread start proc
5. Fix creating suspended thread and parse create_flags
Currently creating suspended thread doesn't work because
`NtCreateThreadEx` handler uses invalid flag `CREATE_SUSPENDED`. This PR
fixes that, and moreover it carefully parses create_flags of the
`NtCreateThreadEx` call.
6. Fix `FS` and `GS` handling
This PR fixes several problems with `GS` and `FS` segments:
* Wrong GDT descriptor for selector 0x53
* Update GDT descriptor for selector 0x53 for a `WOW64` process every
context switch like Windows does
* Set `GS` base when `GS` segment register is updated in 64-bit code
(code selector is `0x33`). When `GS` segment register is loaded with
correct selector (`0x2b`) `GS` base is set to 0. So, when the code
accesses something like `gs:[0]`, a page fault occurs. `KiPageFault`
handles this situation and sets correct `GS` base.
Also, take into account that `teb64.ExceptionList` initially contains
`teb32` address for `WOW64` process. This is used to setup `FS` base
when `wrfsbase` instruction is available. We can enable this instruction
using `kusd.ProcessorFeatures.arr[PF_RDWRFSGSBASE_AVAILABLE] = 1;` and
this work perfectly with `unicorn` backend. Unfortunately `icicle`
backend does not support `wrfsbase`, so I don't enable this instruction
by default.
This PR fixes some issues with VMP program emulation. It has
successfully allowed programs protected by VMP 3.5 to run normally, and
it modifies the following functions:
1. Correct implementation of ProcessInstrumentationCallback
2. Add missing path check in handle_NtCreateFile
3. Fix the check in handle_NtOpenSection
4. Fix the behavioral differences between the emulator and the kernel
when the return value is an invalid pointer
5. Add printing of the content of the NtRaiseHardError message box
6. Bypass NtClose detection for VMP
This flag is needed to suport emulation of .net executables
that don't have an entry point set in PE header. This applies
to both PE32 and PE64 executables. If InitialThread is set
the loader substitutes an entry point of the .net executable
with mscoree.dll!_CorExeMain.
When emulating `WOW64` samples sometimes you can see a garbige like
this:
```
Executing syscall: NtQueryAttributesFile (0x3D) at 0x18009dd42 via 0x100037f1c (wow64.dll)
--> Querying file attributes: \??\C:\SH╠мхЯЦэР╜р░АC:\Windows\SYSTEM32\VCRUNTIME140.dll
```
This is because of incorrect `PEB32` creation that leads to damaging
several `UNICODE_STRING` fields in `ProcessParameters`.
This PR fixes that.
This PR fixes incorrect size when using `uc_hook_add`.
`uc_hook_add`'s memory range is inclusive on both sides. So we need to
adjust an ending address to keep correct size.
This is manifested, for example, when using gdb. If a breakpoint is set
on a 1-byte instruction, you won't be able to single-step the next
instruction because that instruction also triggers the breakpoint, which
the debugger doesn't expect.
This PR fixes getting `ProcessBasicInformation`.
When emulating a program that uses
[ProcessPrng](https://learn.microsoft.com/ru-ru/windows/win32/seccng/processprng)
function from `BCryptPrimitives.dll`, an error occurs:
```
Unimplemented syscall: NtCallbackReturn - 0x5 (raw: 0x8000005)
```
`BCryptPrimitives.dll` checks whether the running process is a [secure
process](https://learn.microsoft.com/en-us/windows/win32/procthread/isolated-user-mode--ium--processes).
If it is, then `iumbase.dll` is loaded. `iumbase.dll` depends on
`iumdll.dll` that's like an `ntdll.dll` for secure processes, and it has
its own subset of system calls with different syscall numbers. So,
`0x8000005` is not `NtCallbackReturn`, it is `IumCrypto`.
But why does `BCryptPrimitives.dll` get into trouble? It calls
`NtQueryInformationProcess` with class `ProcessBasicInformation` and
`ProcessInformationLength == 0x40`. It turned out that it is a special
case and it's even documented in the aforemantioned link, look for the
definition of the function `IsSecureProcess`.
