Why do you want that? ---> Lots of reasons
- Less AV detection for exe compiled by Go from Virustotal
- More control on the IAT in exe (I can fine tune detection)
- Combined with -buildmode=pie I am closer on getting a shellcode
About the last point, I am studying if it is possible to compile a go exe
--> extract .text ---> run the thing in memory. Basically I know it will be
impossible unless I really modify the toolchain to have
1. no pdata ---> still haven't done it
2. no .data ---> still haven't done it
3. no IAT ---> doing now
4. pie code ---> already done with buildmode
Basically what I am trying to simulate is something like the donut project
but in native go ...
It is all for educational purposes and fun and learn how go works ofc.
Anyways for my problem above , I found a solution that works.
I just declared a function in os_windows.go
```
func InitalizeImports() {
println("Started Init")
_AddVectoredContinueHandler =
stdFunction(unsafe.Pointer(GetProcAddressReplacement(GetModuleHandleReplacement("ntdll.dll"),
"RtlAddVectoredContinueHandler")))
_AddVectoredExceptionHandler =
stdFunction(unsafe.Pointer(GetProcAddressReplacement(GetModuleHandleReplacement("ntdll.dll"),
"RtlAddVectoredExceptionHandler")))
_CloseHandle =
stdFunction(unsafe.Pointer(GetProcAddressReplacement(GetModuleHandleReplacement("kernel32.dll"),
"CloseHandle")))
_CreateEventA =
stdFunction(unsafe.Pointer(GetProcAddressReplacement(GetModuleHandleReplacement("kernel32.dll"),
"CreateEventA")))
}
```
That I call in signal_windows.go (seems the first place where winapi call
are needed for now)
```
func initExceptionHandler() {
InitalizeImports()
stdcall2(_AddVectoredExceptionHandler, 1, abi.FuncPCABI0(exceptiontramp))
if GOARCH == "386" {
// use SetUnhandledExceptionFilter for windows-386.
// note: SetUnhandledExceptionFilter handler won't be called, if debugging.
stdcall1(_SetUnhandledExceptionFilter, abi.FuncPCABI0(lastcontinuetramp))
} else {
stdcall2(_AddVectoredContinueHandler, 1, abi.FuncPCABI0(firstcontinuetramp))
stdcall2(_AddVectoredContinueHandler, 0, abi.FuncPCABI0(lastcontinuetramp))
}
}
```
Then I can delete the cgo_import_dynamic of the defined api call, and all
the exe compiled with the new toolchain are working and does not contain
_AddVectoredContinueHandler,
_AddVectoredExceptionHandler, _CloseHandle, _CreateEventA in the IAT.
Thanks
Rudeus Greyrat
Le dimanche 20 octobre 2024 à 05:27:14 UTC+2, Ian Lance Taylor a écrit :
> On Sat, Oct 19, 2024 at 8:11 PM rudeus greyrat
> <rudeusqu...@gmail.com> wrote:
> >
> > I want to have an empty IAT when I compile go exe.
>
> Why do you want that?
>
>
> > I noticed that all the imports in the IAT are because of a file in go
> runtime package called
> https://github.com/golang/go/blob/master/src/runtime/os_windows.go
> >
> > So having ```//go:cgo_import_dynamic runtime._CloseHandle CloseHandle%1
> "kernel32.dll"``` will result in the address of CloseHandle winapi being in
> the local variable _CloseHandle and resulting in CloseHandle appearing in
> the import table.
> >
> > I was not able to understand what cgo_import_dynamic really does (nor
> find the code behind it).
>
> The //go:cgo_import_dynamic directive is documented in the long
> "implementation details" comment in cmd/cgo/doc.go.
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/7894fa9b-ce57-4a0e-b3d5-2f515f184a80n%40googlegroups.com.
