将X64 Windows升至LLVM比特码,然后编译回X32 ONE?

发布于 2025-02-04 03:57:59 字数 3161 浏览 4 评论 0 原文

因此,我的想法是“提起” 64位Windows可以执行到LLVM比特码(或任何高于汇编),然后将其编译回32位可执行文件。

我发现 retdec and mcsema 可以将PE二进制提升到LLVM IR(以及可选的C),但是McSema需要IDA Pro,所以我还没有尝试过。

我已经安装了MSVC V143 和Windows SDK版本 10.0.19041.0

“

clang版本:

clang version 13.0.1 (https://github.com/llvm/llvm-project 75e33f71c2dae584b13a7d1186ae0a038ba98838)
Target: x86_64-pc-windows-msvc
Thread model: posix

所以我使用clang在c中编译了此Hello World Code:

#include <stdio.h>

int main()
{
        printf("Hello, world!\n");
}

然后> clang hello.c -o hello.exe

检查 hello.exe wsl:

$ file hello.exe
hello.exe: PE32+ executable (console) x86-64, for MS Windows

您可以下载

Then I use RetDec to lift it to LLVM IR:

python retdec-decompiler.py --no-memory-limit hello.exe

Output: here

之后我们得到了:

“文件”

编译比特代码返回可执行文件:

clang hello.exe.bc -m32 -v -Wl,/SUBSYSTEM:CONSOLE -Wl,/errorlimit:0 -fuse-ld=lld -o hello.x86.exe

在这里

我猜我想诸如 _writeConsolew 之类的功能是win32 apis,但是 ____________dempiler_undefined_function_0 可能是从empompiler中生成的。

另外,分解代码没有 main 函数,但是它具有 entry_point 函数。来自 hello.exe.ll

​main :

”

以及 hello.exe.c 没有 ____________undefined_functine_function_0

我也尝试使用<<代码> lli :

lli --entry-function=entry_point hello.exe.bc

输出:此处

在这里

如何进行编译?谢谢!

So my idea is to "lift" 64-bits Windows executable to LLVM bitcode (or whatever is higher than assembly) and then compile it back to 32-bit executable.

I found that RetDec and McSema can lift PE binary to LLVM IR (and optionally C), but McSema requires IDA pro so I haven't tried it yet.

I have installed MSVC v143 and Windows SDK version 10.0.19041.0:

vs

Clang version:

clang version 13.0.1 (https://github.com/llvm/llvm-project 75e33f71c2dae584b13a7d1186ae0a038ba98838)
Target: x86_64-pc-windows-msvc
Thread model: posix

So I compile this Hello World code in C using Clang:

#include <stdio.h>

int main()
{
        printf("Hello, world!\n");
}

then clang hello.c -o hello.exe

Check hello.exe file type with WSL:

$ file hello.exe
hello.exe: PE32+ executable (console) x86-64, for MS Windows

You can download it here.

Then I use RetDec to lift it to LLVM IR:

python retdec-decompiler.py --no-memory-limit hello.exe

Output: here

After that we get:

files

Compile bitcode back to executable:

clang hello.exe.bc -m32 -v -Wl,/SUBSYSTEM:CONSOLE -Wl,/errorlimit:0 -fuse-ld=lld -o hello.x86.exe

Output: here

I guess functions like _WriteConsoleW are Win32 APIs, but ___decompiler_undefined_function_0 might be generated from the decompiler by some way.

Also, the decompiled code has no main function, but it had entry_point function. From hello.exe.ll:

hello.exe.ll

hello.exe.c also has entry_point instead of main:

hello.exe.c

And also, hello.exe.c doesn't have ___decompiler_undefined_function_0

I also tried running the bitcode with lli:

lli --entry-function=entry_point hello.exe.bc

Output: here

Here is the link to the files.

How to make this compile? Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

影子的影子 2025-02-11 03:58:00

那很雄心勃勃。

我要肢体出去,说每个Windows应用程序都包含系统标头文件的千> -bit Systems和许多包含 #ifdef 或其他与平台相关的差异。您将拥有一个大的.ll文件,其中包含Windows64特定类型和代码。

如果Microsoft的开发人员将Windows64视为丢弃W95代码所需的一些黑客的好机会,那么您也将在那里拥有W32不兼容的代码。

您要做的是 wine 开发人员做到了 - 又添加代码又添加了每个问题。将有成千上万的案件要处理。其中一些将非常困难。当您在.ll文件中看到数字128时,是原始源中的sizeof(this_w64_struct),sizeof(that_other_struct)还是其他东西?您应该将数字更改,如果是这样,什么?

您应该期望这个项目至少需要数年,甚至十年或更长时间。祝你好运。

That's very ambitious.

I'm going to go out on a limb and say that every windows application includes thousands of system header files, most of which use types whose size differs between 32- and 64-bit systems and many of which contains #ifdef or other platform-dependent differences. You'll have a large .ll file full of windows64-specific types and code.

If the developers at Microsoft saw windows64 as a good chance to drop some hacks that were needed for w95 code, then you'll have w32-incompatible code there, too.

What you have to do is what the wine developers did — add code to cater to each problem in turn. There will be thousands of cases to handle. Some of it will be very difficult. When you see the number 128 in the .ll file, was it sizeof(this_w64_struct) in the original source, sizeof(that_other_struct) or something else entirely? Should you change the number, and if so, to what?

You should expect this project to take at least years, maybe a decade or more. Good luck.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文