-
Notifications
You must be signed in to change notification settings - Fork 373
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add x86_64 support #97
base: x86_64
Are you sure you want to change the base?
Conversation
Running "make debug" will build the target with debugging symbols, low level of optimization and without NDEBUG flag. This target is meant to be used for development purposes. The "all" target remain the same.
…ch successfully check a PE (x64) header. The peloader library can be built passing the ARCH flag as argument, which allows the user to choose between x86 or x64. This flag is available for the peloader library only, but the idea is to expand it to the whole project. check_nt_hdr function has been changed in order to recognize x64 NT headers magic values. For this purpose, a Check unit test has been added.
LDLIBS variable has been modified in order to intiialize crtexports. This makes us able to map and link a .dll in the Check unit tests. test target do uses O0 and -g compiler flags.
Created the first two x64 APIs (HeapAlloc and HeapFree). The x64 APIs will have the "_x64" suffix and they will be mostly wrappers around the true APIs. An only development-purpose Makefile target (mpclient_x64) has been created.
… replaced by zydis, so now we've got a x86/x86_64 disassembler. hook.c now uses zydis to patch functions (only x86 for now)
I have just replaced Next steps:
|
…direct functions and switch calling convention
I added x86_64 support for the intercept set of libraries:
|
…n eicar.com successfully
So,
Now, the framework should be able to load, link and execute x86_64 DLLs. On the other side, I guess I am doing something wrong with one (or more than one) of the mpengine data structures we provide to the Next steps:
|
It is possible to call DLL exports using the |
…or zydis decoder constructor.
…ing addresses on the stack and overwriting some useful value on the redzone. For now, the redzone has been disabled (-mno-red-zone).
Subhook hooks were pushing values on the redzone, which led to some useful values on the stack to be overwritten. I disabled the redzone for now I managed to use loadlibrary for other x86_64 DLL - like the BitDefender engine - and I am able to perform scans on different files and binaries. Everything is working quite good I would say. Still, mpclient just works (more or less, since One thing to keep in mind:
|
Update: with the new release of mpengine.dll (Product Version Number: 1.1.18200.2) it does not work also with eicar.com. |
This is really impressive progress, I think we can try to merge this into main. Let me test it out today to make sure it's not regressing any x86 stuff, I'm a bit nervous about merging the hook and the x64 stuff in one - but maybe it will be easy... |
…ok. We can't rely on a jmp near immediate in this case.
Two notes:
I am going to open a couple of issues (assigned to me) to keep track of these bugs. I will provide a patch as soon as I can. |
…c as logging utility for all the project.
…e dead and make a good coffee (and eventually it changes the calling convention of a function to Windows x86_64 as well...)
So... I have just found out that GCC (and Clang too) implements the function's attribute Basically, all the heavy lifting with x64 NASM dispatchers and the new hook library is... USELESS. Next steps:
|
….a which now supports both HOOK_DEFAULT and HOOK_REPLACE_FUNCTION mode.
…so uses WINAPI functions.
Updates:
@taviso good news: after 1) and 2) are done, I am 99% sure we fully achieved x86_64 native (and reliable) windows execution on Linux, and we would be ready to merge everything into master! |
Added the support for the x64 Structured Exception Handling. This said, I also tested the last version of mpengine with different malicious programs: Other AVs engines/x64 programs are correctly loaded and work as expected. |
wow! 🥳 I think I don't really understand the flags even for x86, I just guessed from testing them experimentally. I think it probably just needs some reversing of msmpeng to see what it does with the flags, I'll get to it some time! Do you think we should start trying to merge it into main? |
I will start fixing the things for the x86 version and I think we can gradually merge them into main. |
…fter handler has been executed
The x86 version of mpclient works. The x64 version is still unreliable. I think we can start merging into main. |
Hi all!
|
Hello @redmed666
If you've already cloned the repository and you checked out on the x64 branch, then run: Otherwise, you should clone the repo using the |
It was indeed a stupid question. Thank you! |
Excellent job. |
after a few test, I found many faked api should change from noregmarm to ms_abi. for example crt.c |
Hello @shuxin, yeah I definetely forgot about the APIs in I'm planning to get back on this PR as soon as possible to finally make it work reliably for |
mse mpengine does not depends on msvcrt#.dll . |
Hi and thank you, in the last step of make i get this error cc -march=native -ggdb3 -std=gnu99 -fshort-wchar -Wno-multichar -Iinclude -Iintercept/include -Ilog -Ipeloader -mstackrealign -maccumulate-outgoing-args -O3 -g -O0 -fPIC mpclient_x64.o log/log.o -o mpclient_x64 -Wl,--whole-archive peloader/libpeloader.a -Wl,intercept/libhook.a -Wl,intercept/libZydis.a -Wl,intercept/libsubhook.a -Wl,--no-whole-archive -march=native -ggdb3 -std=gnu99 -fshort-wchar -Wno-multichar -Iinclude -Iintercept/include -Ilog -Ipeloader -mstackrealign -maccumulate-outgoing-args -O3 -g -O0 -fPIC -lm -Wl,--dynamic-list=exports.lst -ldl .... /usr/bin/ld: i386 architecture of input file thank you |
I cloned everything with this, as mentioned above, git clone --recurse-submodules --branch x64 https://github.com/cube0x8/loadlibrary.git |
@kh-abd-kh it looks like you have a mix x86 and x86_64 environment. Do you want to execute a 64 or 32 bit DLL? You might need to |
I leave this comment as yet another confirmation of the x86-64 implementation operability. Creating a binary file to interact with my dll took me less time than I expected. Wow! Thanks to the authors for a great job! |
@ravone thank you very much for your feedback. I appreciate it :) |
@cube0x8 any idea when this will get merged ? |
It's on my radar. I don't want to promise anything but I could get my hand
on it in the next months!
…On Tue, 11 Apr 2023, 07:20 Noteworthy, ***@***.***> wrote:
@cube0x8 <https://github.com/cube0x8> any idea when this will get merged ?
—
Reply to this email directly, view it on GitHub
<#97 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABGW4SPC6AQDJ2FHCWRXH3DXATL2NANCNFSM4YR3A3RA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
ENGINE_CONFIG EngineConfig; | ||
|
||
// Load the mpengine module. | ||
if (pe_load_library(image.name, &image.image, &image.size) == false) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there's a bug: image.size
is an int
but pe_load_library
takes a size_t*
.
The x64 support has started!