- Import the Catch2 self-contained C++ test framework.
It's used by many Microsoft OSS projects:
- https://github.com/microsoft/cppwinrt/tree/master/test
- https://github.com/microsoft/wil/tree/master/tests
As well as many OSS projects in general.
When the CMake PR is merged, we can remove this as
a checked in development dependency, and can instead
download it using CMake.
- Start basic set of unit tests to validate failure modes of
- Hook the execution into the existing NMake build system.
- Hook test execution into CI pipeline
Currently we can not use createwith API to start exes which path contain special characters or unicode languages like Chinese.
This change fixes that by formatting the string path correctly.
Detours 4.0.1 looks like it's Detours 3.0 build_339 changed its name by comparing the code and looking at git commit logs, so the code in follow version need to be merged.
Since both of the types have the same capacity in the same arch, they both work.
But IMAGE_THUNK_DATAXX is the right struct for this code and I believe to make the code more readable and descriptive.
This patch improves the logic for detecting whether the process to be
patched is a 32bit or a 64bit process.
The old logic would first enumerate the modules in the process and see
if:
1. There is a 32bit executable module
2. There is a 64bit DLL module
In case 1.) is true and 2.) is false, i.e. a 32bit executable but no
64bit DLL, the process was deemed to be a 32bit process.
This seems plausible, but I encountered a case in which it is not true:
I launched an IL-only .NET application (a Windows Forms GUI application) in
Windows 10. Right after the CreateProcess call, there were just two
modules in the process
- A 32bit executable
- A 32bit ntdll.dll library
I.e. the .NET runtime was not loaded yet. Hence, because there *is* a
32bit executable but there is *not* a 64bit DLL, bIs32BitProcess was set
to TRUE. However, when resuming the process and inspecting with Process
Explorer, it appears that the process executed in 64bit mode!
I suppose it would be possible to replicate the behavior of the Windows
loader and be a bit smarter about looking for 32bit executables: instead
of just looking at the 'machine' flag, also look for a potential
IMAGE_COR20_HEADER (which basically acts as the PE header for .NET
executables) and see if that requires 32bit. However, I think there is
an easier way to check if the process is 32bit or not.
The new logic performs two steps:
1. Detect whether the operating system is 64bit. If the code is compiled
as 64bit, then the OS is trivially 64bit. If the code does not have
_WIN64 defined, i.e. it is 32bit, but it is running under WOW64, then
the OS is 64bit, too.
2. Detect if the process to be patched is 32bit. If the OS is *not*
64bit, the process can't possibly be 64bit. So it must be 32bit. If the
OS *is* 64bit, we can identify 32bit processes by calling
IsWow64Process() again.
* Build: Catch incorrect format specifiers with /we4777 and fix issues.
Most of these are using %d for a DWORD when it should be %ld.
* More compilation fixes
@GladYouLikeIt described the bug in the issue:
> Extend.cpp is built into extend64.dll for x64, and extend86.dll for x86,
> but the code in samples\findfunc\extend.cpp references the dll without
> specifying the DETOURS_BITS in the dll name. DetourFindFunction fails
> at runtime because of this.
@ohuseyinoglu noted the same bug in SymTest.cpp as well.
Fixes#2
The VS Developer command prompts sets two variables based on the configuration
which was launched. One is the architecture of the host compiler, the other is
the architecture that the compiler is targeting.
```
C:\> set | rg VSCMD_ARG_
VSCMD_ARG_HOST_ARCH=x64
VSCMD_ARG_TGT_ARCH=x86
```
$(VSCMD_ARG_TGT_ARCH) is a direct mapping to what the user is expected to set
the $(DETOURS_TARGET_PROCESSOR) environment variable too. For cross compilation
and normal compilation the variable is always set to the value that is expected.
This change uses this to our advantage so that users won't have to manually set
the $(DETOURS_TARGET_PROCESSOR) variable in order to compile.
The dynamic_alloc example fails to compile on Visual Studio 2015 due to an C4800 / C2220 compiler error (LONG status is used as return value). Apart from the performance warning, which is treated as error because of the /WX flag, the semantics of this operation seem to be wrong. At the end of the function, we find return status == NO_ERROR. That means that in line 70 a successful execution results in a return value of true and an unsuccessful execution results in false. However, if the function is left in line 52, the return code is true (because the test status != NO_ERROR was positive).
Fix this, and force /we4800 to be enabled to catch issues in the future.
Co-authored-by: Brian Gianforcaro <bgianf@microsoft.com>
We need to set DETOURS_TARGET_PROCESSOR to tell the makefile's what
architecture we are targeting. It seems like we should eventually
fix system.mak to sniff target architecture using %VSCMD_ARG_TGT_ARCH%.
Also add support for uploading the artifacts from the pipeline so
they are available for download / testing and consumption.
Early return in case the VirtualAlloc fails with ERROR_DYNAMIC_CODE_BLOCKED error
(aka The operation was blocked as the process prohibits dynamic code generation).
* Build: Fix of traceapi on Windows SDK >= 10.0.19041.0
In the 10.0.19041.0 SDK, the definitions for GetThreadLocale
and SetThreadLocale were moved under a #if(WINVER >= 0x0500)
check, where there was no such check before.
Adjust the detours build to have the same check, to avoid
consuming undeclared functions
* Build: Suppress logo (/nologo) in places where it was missed
* CI: Add initial CI workflow for Detours project
Add a simple workflow that builds x86 and x64 build architecture on push to master,
or to validate pull requests before merge.
* CI: Add codeql analysis to the build
* Fix incorrect usage of ZeroMemory
* Fix inconsistent declaration of DetourFindFunction
* Move DETOURS_STRINGIFY macros, and fix inconsistent reference to them
* Fix macros in detver.h
- Describe how to set up the build open environment (Visual Studio).
- Clarify that you should build the tests in a Developer Command
Prompt for Visual Studio. Explain that there are several different
ones.
- Note that you can run all the tests from the sample directory
using "nmake test".
* Replace ARM64's patch jmp from a 16 byte encoding to a 12 byte encoding, as some functions in Windows are only 12 bytes long and have no padding.
* NIB: Update comments and constants.
* Remove redundant field in _DETOUR_TRAMPOLINE. pbDetour can also be used as the island valus for theindirect jump.
* Update the _DETOUR_TRAMPOLINE's comment to describe the new encoding size and shape correctly.
This patch exports the ability to allocate a region within the jump bounds
from the given address, that was implemented as an internal function
`detour_alloc_trampoline`. This ability would be useful for Detours' consumer.
* ARM64 does not like addresses below 4GB -- rebase tests higher.
Port of these changes:
Change 114680 by NTDEV\jaykrell@JAYKRELL100-4 on 2017/10/20 22:24:17
ARM64 does not like addresses below 4GB.
Disable managed test on ARM64 until/unless anyone constructs an adequate environment.
It is disabled on ARM32 also.
Affected files ...
... //depot/969/private/jaykrell/3.0/samples/einst/Makefile#5 edit
... //depot/969/private/jaykrell/3.0/samples/findfunc/Makefile#4 edit
... //depot/969/private/jaykrell/3.0/samples/Makefile#4 edit
Change 114788 by NTDEV\jaykrell@JAYKRELL100-4 on 2017/11/16 01:00:07
fix copy/pasto that breaks all except arm64
Affected files ...
... //depot/969/private/jaykrell/3.0/samples/findfunc/Makefile#5 edit
* PR: Use separate variables for each .dll base address and set them each conditionally based on ARM64.
Port support for Intel EVEX (AVX512) and AMD XOP.
Port support for Intel EVEX (AVX512) and AMD XOP. EVEX appeared in shipping hardware in 2017 e.g. SkyLake Xeon and has been seen in binaries. AMD has stopped implementing XOP but the instructions are latent in binaries.
I moved the C_ASSERT outside of the `DETOUR_EXE_RESTORE` struct definition because it expands into a typedef (which I believe isn't valid C) and causes this compilation error if you include `detours.h` in a C program or library:
```
detours.h(390): error C2071: '__C_ASSERT__': illegal storage class
```
The '±' character can not be correctly represented in some code pages. This causes the build to fail with a C4919 warning. This commit replaces the '±' character in the comments with '+/-'.
This is a little high, but 64 seemed low.
Change 114686 by NTDEV\jaykrell@JAYKRELL100-4 on 2017/10/23 19:06:28
Expand ARM64 rbCode (and scratch) to 128 and document why.
This is a little high, but 64 seemed low.
This is a lot of bytes to overwrite, and it precludes
patching a number of small-ish functions, but it is how many.
For example, automatic following imports, has lead to system service stubs,
that were smaller than this (and aligned less than this).
Brian Gianforcaro
Yogesh B
sonyps5201314
Jay Krell
lironzua
Frerich Raabe
Dani Kamanovsky
Michael Schmidt
pilao
Dani Kamanovsky
Arjun G
Dustin Spicuzza
NancyLi1013
David Tarditi
Pedro Miguel Justo
Assaf Nativ
Indy Ray
tokikuch
Jay Krell
Andreas Rosenberg
asmichi
NoshBar
Sanghyeok Nam