64-bit programs will crash in this situation, why is this?

[editso]

** ......

DWORD offset = 1;
LPBYTE* lpBuffer = (LPBYTE*)VirtualAlloc(0, 1024 * 1024, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

fread(lpBuffer + offset, 1, size, file);

((void (*)())(lpBuffer + offset))();

**

[hasherezade]

but what is the content read into the the buffer?

[editso]

Sorry ! After compiling to 64-bit, I used pe2sch.exe to generate shellcode, and finally read it in my buffer

this is my test code Duplicate of #

#include <Windows.h>
int main(int argc, char** argv) {
    HANDLE hProcess;
    hProcess = GetCurrentProcess();

    MessageBoxA(NULL, "Hello World", "Test", MB_OK);

    ExitThread(0);
}

[hasherezade]

can you zip your payload, along with the loader, and attach it here? I will check... I mean the compiled executables.

[hasherezade]

BTW - did you try to run the converted program with runshc64.exe from the package? https://github.com/hasherezade/pe_to_shellcode/releases/tag/v0.9 Are you sure that your loader is also compiled as 64 bit? If the loader has different bitness than the payload, for sure it will crash.

[editso]

顺便说一句 - 您是否尝试runshc64.exe从包中运行转换后的程序？ https://github.com/hasherezade/pe_to_shellcode/releases/tag/v0.9 您确定您的加载器也编译为 64 位吗？如果加载器的位数与有效载荷不同，它肯定会崩溃。

It can run normally without offset

[editso]

shellcode.zip

[hasherezade]

well, of course it will not run with the offset, because adding the offset destroys the code alignment. it needs to run from the beginning. why do you need the offset?

[editso]

I want to pass parameters through the first address

[editso]

well, of course it will not run with the offset, because adding the offset destroys the code alignment. it needs to run from the beginning. why do you need the offset?

It won't crash under 32-bit program, why

[editso]

well, of course it will not run with the offset, because adding the offset destroys the code alignment. it needs to run from the beginning. why do you need the offset?

Is there any way to solve the alignment problem

[hasherezade]

I want to pass parameters through the first address

you can't do it this way. and anyways those bytes that you changed at the beginning will not be passed to your main function.

[editso]

I want to pass parameters through the first address

you can't do it this way. and anyways those bytes that you changed at the beginning will not be passed to your main function.

After I got the first address through VirtualQuery, I got my parameters

[editso]

I want to pass parameters through the first address

you can't do it this way. and anyways those bytes that you changed at the beginning will not be passed to your main function.

After I got the first address through VirtualQuery, I got my parameters

The 32-bit program is the same as I thought, but I encountered this problem in the 64-bit program

[hasherezade]

I want to pass parameters through the first address

you can't do it this way. and anyways those bytes that you changed at the beginning will not be passed to your main function.

After I got the first address through VirtualQuery, I got my parameters

This is not a good way of passing parameters. Neither in 32 nor in 64 bit. Also, by this way you are destroying the PE header of your payload, which may cause undefined behavior in some programs.

[editso]

I want to pass parameters through the first address

you can't do it this way. and anyways those bytes that you changed at the beginning will not be passed to your main function.

After I got the first address through VirtualQuery, I got my parameters

This is not a good way of passing parameters. Neither in 32 nor in 64 bit. Also, by this way you are destroying the PE header of your payload, which may cause undefined behavior in some programs.

Do you have a good way?

[hasherezade]

There are various, ways, but for example: https://docs.microsoft.com/en-us/windows/win32/memory/creating-named-shared-memory

[editso]

There are various, ways, but for example: https://docs.microsoft.com/en-us/windows/win32/memory/creating-named-shared-memory

okay, thank you.