Project-X - A Worthy Xenos Injector Mod [v2.4]

[InUrFace1337]

I apologize if I did this incorrectly, not quite sure how to update the existing thread.

Project-X is my personal injector, and the only injector I ever use when using one of my cheats that does not make use of my self-injecting loader. It's basically a tweaked version of the widely popular Xenos Injector (The X in Project-X stands for Xenos) and therefore contains all the features of Xenos, with everything I didn't like about it being re-coded to suit my wants/needs and many other neat features/improvements added into the mix.

Here's the original features list for Xenos:

- Supports x86 and x64 processes and modules
- Kernel-mode injection feature (driver required)
- Manual map of kernel drivers (driver required)
- Injection of pure managed images without proxy dll
- Windows 7 cross-session and cross-desktop injection
- Injection into native processes (those having only ntdll loaded)
- Calling custom initialization routine after injection
- Unlinking module after injection
- Injection using thread hijacking
- Injection of x64 images into WOW64 process
- Image manual mapping
- Injection profiles

Manual map features:
- Relocations, import, delayed import, bound import
- Static TLS and TLS callbacks
- Security cookie
- Image manifests and SxS
- Make module visible to GetModuleHandle, GetProcAddress, etc.
- Support for exceptions in private memory under DEP
- C++/CLI images are supported (use 'Add loader reference' in this case)

Kernel manual map features are mostly identical to user-mode with few exceptions:
- No C++ exception handling support for x64 images (only SEH)
- No static TLS
- No native loader compatibility
- Limited dependency path resolving. Only API set schema, SxS, target executable directory and system directory

Supported OS: Win7 - Win10 x64

Additional notes:
Injector has 2 versions - x86 and x64. Apart from obvious features x86 version supports injection of x64 images into x64 processes; x64 injector supports injection of x86 and x64 images into WOW64 processes. However this is only valid for native images. If you want to inject pure managed dll - use same injector version as your target process is.

Injection of x64 images into WOW64 process is totally unpredictable. If you want to do this I would recommend to use manual mapping with manual imports option, because native loader is more buggy than my implementation in this case (especially in windows 7).

Restrictions:
- You can't inject 32 bit image into x64 process
- Use x86 version to manually map 32 bit images and x86 version to map 64 bit images
- You can't manually map pure managed images, only native injection is supported for them
- May not work properly on x86 OS versions
- Kernel injection is only supported on x64 OSes and requires Driver Test signing mode.

Process selection:
Existing - select existing process from the list
New - new process will be launched before injection
Manual launch - after pressing 'Inject' button, injector will wait for target process startup

Images:
List of images you want inject
Add - add new image to the list. Drag'n'drop is also supported
Remove - remove selected image
Clear - clear image list

Advanced options:

Injection type:
Native inject - common approach using LoadLibraryW \ LdrLoadDll in newly created or existing thread
Manual map - manual copying image data into target process memory without creating section object
Kernel(New thread) - kernel mode ZwCreateThreadEx into LdrLoadDll. Uses driver
Kernel(APC) - kernel mode APC into LdrLoadDll. Uses driver
Kernel(Manual map) - kernel manual mapping. Uses driver

Native Loader options:
Unlink module - after injection, unlink module from InLoadOrderModuleList, InMemoryOrderModuleList, InInitializationOrderModuleList, HashLinks and LdrpModuleBaseAddressIndex.
Erase PE - after injection, erase PE headers
Use existing thread - LoadLibrary and init routine will be executed in the context of random non-suspended thread.

Manual map options:
Add loader reference - Insert module record into InMemoryOrderModuleList/LdrpModuleBaseAddressIndex and HashLinks. Used to make module functions (e.g. GetModuleHandle, GetProcAddress) work with manually mapped image.
Manually resolve imports - Image import and delayed import dlls will be also manually mapped instead of being loaded using LdrLoadDll.
Wipe headers - Erase module header information after injection. Also affects manually mapped imports.
Ignore TLS - Don't process image static TLS data and call TLS callbacks.
No exception support - Don't create custom exception handlers that enable out-of-image exception support under DEP.
Conceal memory - Make image memory visible as PAGE_NO_ACESS to memory query functions

Command Line:
Process command line arguments

Init routine:
If you are injecting native (not pure IL) image, this is name of exported function that will be called after injection is done. This export is called as void ( __stdcall* )(wchar_t*) function.
If you are injecting pure managed image, this is name of public method that will be executed using ICLRRuntimeHost::ExecuteInDefaultAppDomain.

Init argument:
String that is passed into init routine

Close after injection:
Close injector after successful injection

Inject delay:
Delay before injection start

Inject interval:
Delay between each image

Menu options:

Profiles->Load - load injection profile
Profiles->Save - save current settings into profile

Tools->Eject modules - open module ejection dialog
Tools->Protect self - make injector process protected (driver required)

Command line options:
--load <profile_path> - start injector and load target profile specified by <profile_path>
--run <profile_path> - imeddiately execute profile specified by <profile_path> without GUI

Kernel injection methods require system running in Test mode.

What's different about Project-X:

Main dialog:

- interface has been tidied up
- swapped locations of eject modules/advanced config
- checkboxes added to modules listview
- added native column to modules listview
- protect self option no longer requires driver separately (still requires test signing)
- added custom dialog for processes->type->manual
- removed automatic openfiledialog when clicking processes->type->manual/auto
- process IDs are now in hex under processes->process
- swapped location of status bar parts 1 and 3
- inject/eject/remove/clear buttons are reactive and enable/disable based on selections/settings
- added menu items to try to automate the process of enabling/disabling driver test signing mode
- added confirmation dialog to let the user know injection completed successfully

Config dialog:

- interface has been dramatically tidied up and rearranged
- removed use existing thread checkbox in favor of making dedicated map method labeled thread hijack

Eject dialog:

- interface has been tidied up
- checkboxes added to modules listview
- fixed load type retrieval

What's new in this version:

Main dialog:

- added menu items to try to automate the process of enabling/disabling driver test signing mode
- added confirmation dialog to let the user know injection completed successfully

Bugfixes:

- fixed a profile related issue with the "--run" command line option that could potentially corrupt the config in question

Mostly just frontend tweaks and some much needed core improvements to top it all off. If the menu item to enable/disable driver test signing mode fails, open an elevated command prompt and return the following:

bcdedit /set testsigning on // to enable

// or

bcdedit /set testsigning off // to disable

I hope you find this tool as useful as I have. 95% of credits go directly to DarthTon, as it is almost entirely his work. All I did was change what I myself would have done differently had this been my project from the start.

Screenshots:







Virus scans:

https://www.virustotal.com/#/file/63...7320/detection
https://virusscan.jotti.org/en-US/fi...job/2qp9z6vtho

[Kevin]

/approved but untested

[jeffdelux3]

look and work nice