go-winloader

KO | EN

gitlite — search

#hacktoberfest #react #ai #android #rust #deep-learning #windows #awesome #cli #kubernetes #awesome-list #pytorch #ios #mcp

(★ 88)

[WIP] Implementation of the Windows module loader in pure Go, with no CGo.

File Explorer

Download Latest Version (.zip)

- - main.go
- - loader.go
  - machine.go
- - cache.go
  - loader.go
- - export.go
  - format.go
  - format_test.go
  - import.go
  - module.go
  - module_test.go
  - reloc.go
  - util.go
- - common.go
  - memory_other.go
  - memory_windows.go
  - memory_windows_test.go
- - hacks_other.go
  - hacks_windows.go
  - loader_windows.go
  - machine_windows.go
  - nativearch_386.go
  - nativearch_amd64.go
  - nativearch_arm64.go
- export.def
- Makefile
- README.md
- tiny.c
- tiny.dll
common.go
go.mod
go.sum
LICENSE.md
loader_other.go
loader_windows.go
README.md

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# go-winloader

**Note:** This library is still experimental. There are no guarantees of API stability, or runtime stability. Proceed with caution.

go-winloader is a library that implements the Windows module loader algorithm in pure Go. The actual Windows module loader, accessible via `LoadLibrary`, only supports loading modules from disk, which is sometimes undesirable. With go-winloader, you can load modules directly from memory without needing to write intermediate temporary files to disk.

This is a bit more versatile than linking directly to object files, since you do not need object files for this approach. As a downside, it is a purely Windows-only approach.

Note: Unlike native APIs, in place of processor register sized values go-winloader uses `uint64` instead of `uintptr` except when calling native host functions. This allows it to remain neutral to processor architecture at runtime, which in the future may allow for more esoteric use cases. (See TODO for more information on potential future features.)

## Example

```go
// Load a module off disk (for simplicity; you can pass in any byte slice.)
b, _ := ioutil.ReadFile("my.dll")
mod, err := winloader.LoadFromMemory(b)
if err != nil {
    log.Fatalln("error loading module:", err)
}

// Get a procedure.
addProc := mod.Proc("Add")
if proc == nil {
    log.Fatalln("module my.dll is missing required procedure Add")
}

// Call the procedure!
result, _, _ := addProc.Call(1, 2)
log.Printf("1 + 2 = %d", result)
```

## TODO

* WinSXS support

* Some binaries have manifests requesting a specific version of a library.
      There is an undocumented library at sxs.dll. Since it's undocumented,
      it might be difficult to work out how to use it.
    
    * It'd be nice to have a reimplementation of the whole SXS algorithm, just
      for completeness sake. (It might even be useful to Wine.)

* Additional compatibility hacks

* Because we are not Windows loader, Windows loader's internal structures
      do not update when we load binaries into the address space.

* Because of this, our HINSTANCE value may not always work properly.

* There's a hack that sends the process HINSTANCE instead.

* There's a stub for a hack that would inject the library into the PEB
        loader data linked lists.

* This might fail catastrophically or have worse consequences, but it
            would be interesting to explore.

* Another useful hack would be one that can override calls to important
        Windows functions and implement their functionality for cases when our
        own false HINSTANCE is used. This could be done on a process-wide level
        (for best compatibility) or directly on the import table (usually enough,
        but tricky modules will bypass this.)

* Better support for loading executable images.

* Right now, if you attempt to load an executable, it executes the
      entrypoint eagerly when it tries to send the DLL attach message.

* Threading support.

* Perhaps have a helper function that can run a function in a new thread,
      automatically calling `DLL_THREAD_ATTACH`/`DLL_THREAD_DETACH` as needed
      on memory loaded modules.
    
    * While it may not be necessary for all libraries, it is likely necessary
      for libraries that have statically linked the MSVC runtime, and for
      libraries that use thread-local storage. Otherwise, calling functions on
      threads other than the initial one is likely to crash.

* Even better: if we can find a place to hook new threads, this would be a
      nice hack to support.

* Versatility

* Operating systems other than Windows:

* Need to figure out how to make MSABI calls. Maybe CGo with msabi
          function pointers, or maybe we need to write out the asm by hand.

* Emulator would need the ability to generate stub addresses that call
          back into Go code, so we can use them to handle imports and whatnot.
        
        * Would need a custom loader that lets you emulate calls to other
          libraries.

* CPU emulation

* Should be possible implement virtual machines with emulated CPUs.

* Similar to the outside Windows case, we need a custom loader to
          emulate library calls. Although we *can* use the host system's
          libraries, we need to translate API calls so that they work
          correctly, like translating addresses and marshaling/unmarshaling
          data as necessary, and of course calling conventions are entirely
          different.

* We should provide shims at least for running 32-bit binaries in
          64-bit processes using emulation. How much of the API to emulate
          would be hard to guage, but at least for documented APIs it should
          be relatively straightforward work.

* Legacy formats

* Currently go-winloader only supports loading PE32 or PE64 binaries.

* It might be useful to someone to implement loading very old legacy
        binaries, like NE or LX.

* Expose lower level APIs

* In order to allow this library to be useful while it is still in
          heavy flux, a very small surface area is exposed today. As it
          matures, more of these internal libraries should be exposed as
          public API.

go-winloader

File Explorer

Today's picks

Was this content helpful?

Recent Feedback

go-winloader

File Explorer

Today's picks

Was this content helpful?

Recent Feedback

Download README