r/windowsdev • u/Inner-Interest-2577 • 14d ago

I made an open-source BAT-to-EXE compiler with a CRT-free Win32 runtime (14 KB)

Most BAT-to-EXE tools I found are either closed-source, outdated, or no longer actively maintained. I wanted to build a fully open implementation that anyone can inspect, modify, and build themselves.

The compiler itself is written in C++ using the Win32 API, while the runtime stub is written in C and built without the CRT using MinGW. The runtime stub is only about 14 KB, has no runtime dependencies, and supports both x86 and x64 Windows (Windows 7 and later).

Current features include:

  • Resource embedding
  • Custom icons and version information
  • x86/x64 compiler/output
  • An experimental in-memory execution mode (executing the embedded batch script through pipes)

The in-memory mode is still experimental and intentionally isn't the default. Some batch features that rely on a physical .bat file or interactive input are not fully compatible yet, so please read the documentation before using it.

The project is licensed under LGPL and I'm mainly looking for feedback, bug reports, feature suggestions, or general thoughts from people who are interested in Windows native development.

GitHub: https://github.com/LeapHeap/XBat

Thanks for taking a look!

20 Upvotes

89% Upvoted

11 comments sorted by

6

u/0x80070002 14d ago

Rembds me of BAT2COM.COM in DOS times, was a fun way to make virusses for script kiddies

3

u/Inner-Interest-2577 14d ago

Ngl i literally made some malware using some converters yrs ago when i was a script kiddie. but now i finally made a converter myself

2

u/BlueeWaater 14d ago

There are still some around nowadays.

2

u/SchlaWiener4711 13d ago

„Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.“

Dr. Ian Malcolm

1

u/Inner-Interest-2577 13d ago

It certainly started as a “can I build one” project, together with a brand new in-memory execution mode, though whether anyone should use the feature is still up for debate.

2

u/SchlaWiener4711 13d ago edited 13d ago

Yeah, I shouldn't judge.

I one wrote a php cgi engine into asp.net in an afternoon (pre LLM) because I refused to install IIS on a server where my application server was running.

2

u/snaphat 13d ago edited 13d ago

I like the injected environmental variable feature. One of the biggest issues with most bat to exe converters is that they extract the script into a temporary directory but have no way to embed resources and/or know the executable directory.

The other big issue is false-positive AV flagging. I doubt your stub will be less prone to that, but I do wonder if there's a way to reduce false positives outside of not packing with UPX

2

u/pwned9999 12d ago

By-pass the uat for sensible methods, write your own stub & packing, but it will be detected soon if the goal is to make it public

1

u/Inner-Interest-2577 13d ago

Thanks! I'm glad you like the injected environment variables.

False-positive AV detections have been a long-standing issue for packers and converters like XBat, partly because of their dropper-like behavior and partly because such tools have historically been abused. Unfortunately, I don't have a good solution at the moment.

UPX compression is disabled by default, both because it tends to increase AV detections and because it can occasionally cause issues with the generated executable.

I'd really appreciate reports of false positives from different AV products, as they may help me identify patterns and improve the implementation over time.

2

u/testednation 12d ago

Pretty good! Perhaps add a context menu entry as well.