lazy_importer/shadow_syscall/inline_syscall in plain C?

[ghost]

Sorry for going off-topic, but I don’t trust third-party Discussions boards like #333. They tend to appear and disappear suddenly, just like the one mentioned in #305 (the maintainer left GitHub and their repositories vanished). So I’ll post it here instead. Ideally, it would be best to have a Discussions board enabled directly on this repository, as I proposed in #305.

Here are the projects I mentioned in the title of this thread:

https://github.com/JustasMasiulis/lazy_importer

https://github.com/annihilatorq/shadow_syscall

https://github.com/JustasMasiulis/inline_syscall

Of course, I don’t do any hacking like the developers of these projects. But I think the idea is cool (at least to me). I don’t want to include a large windows.h. Instead, I can load the shared library and call functions directly without a function pointer prototype or strict type correctness. I’ve seen something similar in some Go code I came across, though I can’t remember exactly where. This is very cool.

[skeeto]

I don’t want to include a large windows.h

I'm also unhappy with the windows.h situation. There seem to be just two escapes:

• Pre-compiled headers. Include windows.h in your own header, include that header first in your sources, and pre-compile it. The extra setup generally requires a not-dumb build system, even if simple. That interferes with my goals of single file projects with one-shot builds.
• Declare the Win32 interfaces yourself. It's tedious, but you can choose better types and names than Microsoft. This is what I usually do.

As for "lazy importing" I've have a little experiment along these lines here in u-config:

skeeto/u-config@master...no-imports

It technically imports and exports nothing (check it with peports), and instead interrogates the PEB to find the handful of needed Win32 functions. It's not meant for obfuscation, and the string names (unhashed) are still present in the PE image.

They tend to appear and disappear suddenly

Yeah, don’t build your castle in other people’s kingdoms and all. Though of course we're here in GitHub's kingdom. It comes with lots of benefits and freebees so I'm willing to make the trade-off building, in part, within this kingdom.

it would be best to have a Discussions board enabled directly on this repository

Done.

[Peter0x44]

Though of course we're here in GitHub's kingdom. It comes with lots of benefits and freebees so I'm willing to make the trade-off building, in part, within this kingdom.

#292 is an easy freebie we could be taking.

[ghost]

@skeeto You still have to define function pointer prototype:

https://github.com/skeeto/u-config/blob/c0f49812f1e55c4e9d73ca6f0d4bd03c03092c6d/miniwin32.h#L29

Lazy Load a DLL in Go doesn't need a function pointer prototype.

[ghost]

@skeeto You can convert this issue to a discussion. The button is right there on the sidebar.

[skeeto]

You can convert this issue to a discussion.

Thanks, I just did that. I'm still learning this interface.

Lazy Load a DLL in Go doesn't need a function pointer prototype.

Hmm, I suppose if you wanted similar semantics you could do this:

typedef uintptr_t Syscall(...);

Go treats Win32 functions like system calls, passing everything as uintptr because the interfacing is really that dumb (in a good way). So you can do basically the same in C. I'd even use a helper like this to pass full-width "empty" parameters:

#define nil ((uintptr_t)0)

Then maybe:

typedef struct {
    Syscall *ExitProcess;
    Syscall *GetCommandLineW;
    Syscall *GetProcAddress;
    Syscall *GetStdHandle;
    Syscall *LoadLibraryA;
    Syscall *WriteConsoleW;
} Kernel32;


typedef struct {
    Syscall *CommandLineToArgvW;
} Shell32;

And then:

static Kernel32 new_kernel32()
{
    Syscall LoadLibraryA, GetProcAddress;  // bootstrap
    uintptr_t h = LoadLibraryA("kernel32");
    return (Kernel32){
        .ExitProcess     = (Syscall *)GetProcAddress(h, "ExitProcess"),
        .GetCommandLineW = (Syscall *)GetProcAddress(h, "GetCommandLineW"),
        .GetProcAddress  = (Syscall *)GetProcAddress(h, "GetProcAddress"),
        .GetStdHandle    = (Syscall *)GetProcAddress(h, "GetStdHandle"),
        .LoadLibraryA    = (Syscall *)GetProcAddress(h, "LoadLibraryA"),
        .WriteConsoleW   = (Syscall *)GetProcAddress(h, "WriteConsoleW"),
    };
}

static Shell32 new_shell32(Kernel32 kernel32)
{
    uintptr_t h = kernel32.LoadLibraryA("shell32");
    return (Shell32){
        .CommandLineToArgvW =
            (Syscall *)kernel32.GetProcAddress(h, "CommandLineToArgvW"),
    };
}

No type safety at the call sites of course, though likely those call sites are already wrappers presenting a higher level interface. Usage example:

static ptrdiff_t char16len(char16_t *s)
{
    ptrdiff_t len = 0;
    for (; s[len]; len++) {}
    return len;
}

void mainCRTStartup()
{
    Kernel32 kernel32 = new_kernel32();
    Shell32  shell32  = new_shell32(kernel32);
    char16_t  *cmd  = (char16_t *)kernel32.GetCommandLineW();
    int        argc = {};
    char16_t **argv = (char16_t **)shell32.CommandLineToArgvW(cmd, &argc);
    uintptr_t  out  = kernel32.GetStdHandle(-11);
    for (int i = 1; i < argc; i++) {
        kernel32.WriteConsoleW(out, u"hello, ", 7, nil, nil);
        kernel32.WriteConsoleW(out, argv[i], char16len(argv[i]), nil, nil);
        kernel32.WriteConsoleW(out, u"\n", 1, nil, nil);
    }
    kernel32.ExitProcess(0);
}

Then:

$ cc -nostartfiles -o hello.exe hello.c
$ ./hello world skeeto
hello, world
hello, skeeto
$ peports hello.exe
KERNEL32.dll
	0	GetProcAddress
	0	LoadLibraryA

Though this technique does not work on x86 because stdcall is incompatible with these variadic calls, and you'd need to dispatch through custom assembly. Looks like the libraries you linked struggle with this, too.

[ghost]

w64devkit GCC is configured to enable GNU extensions by default? Because the syntax used requires GNU extensions and will not compile with ISO C. It will also not work in C++ mode. So in general it's kind of undefined behavior.

[Peter0x44]

It's not a decision w64devkit made. Gcc enables GNU extensions by default.
The way you select them is by using -std=gnuxy or -std=gnu++xy. Instead of cxy and c++xy.

[ghost]

It's not a decision w64devkit made. Gcc enables GNU extensions by default. The way you select them is by using -std=gnuxy or -std=gnu++xy. Instead of cxy and c++xy.

It seems that’s not the case. Only the GCC in w64devkit implicitly enables GNU extensions by default. GCC on other distros required me to add -std=gnu23. This trick doesn’t work in C++ mode, even with -std=gnu++23.

[Peter0x44]

Only the GCC in w64devkit implicitly enables GNU extensions by default.

This is false. I don't know what you're observing, but it's something else.

[skeeto]

https://gcc.gnu.org/gcc-15/changes.html#c

C23 by default: GCC 15 changes the default language version for C compilation from -std=gnu17 to -std=gnu23.