rust x64 binary to shellcode ，and run the shellcode error

[Hello-xBugs]

Hello I build a x64 rust Demo, and use pe2shc convert to shellcode ,but the shellcode cannot execute right. Error:thread panicked while processing panic. aborting. why ? thanks

[d0wnloadtest]

I am facing exactly the same problem. I am working with a x64 Rust binary and after converting it to shellcode and test with runshc64.exe it gaves me this error. I have tried different PE to shellcode converter and I can not make it work.

Please @hasherezade would you help me?

Thanks you so much for your time and effort

[hasherezade]

Hi guys! I guess that you are experiencing the problem that was described here:
#38
I will try to figure out if it can be resolved. In the meanwhile, please have a look at the attached issue, maybe changing the compiler of your application can be a good workaround.

[Wooyme]

I am also facing some issues that may be caused by tls_callbacks. I tried modifying peloader and used the code below to "ensure" that the original PE file's tlscallbacks can be called.

// my new tls_callback
void *tls_callbacks[5] = {nullptr};

static void WINAPI tls_callback_0(HANDLE hDllHandle, DWORD dwReason, LPVOID lpReserved) {
    if (tls_callbacks[0] != nullptr) {
        void (NTAPI *callback_func)(PVOID DllHandle, DWORD dwReason, PVOID) = (void (NTAPI *)(PVOID, DWORD,
                                                                                              PVOID)) tls_callbacks[0];
        callback_func(hDllHandle, dwReason, lpReserved);
    }
    if (tls_callbacks[1] != nullptr) {
        void (NTAPI *callback_func)(PVOID DllHandle, DWORD dwReason, PVOID) = (void (NTAPI *)(PVOID, DWORD,
                                                                                              PVOID)) tls_callbacks[1];
        callback_func(hDllHandle, dwReason, lpReserved);
    }
}

_CRTALLOC(".CRT$XLB")
PIMAGE_TLS_CALLBACK __xl_b = tls_callback_0;

// modified run_tls_callbacks
bool run_tls_callbacks(IMAGE_DATA_DIRECTORY &tlsDir, BYTE *image, void *tls_callbacks[]) {
    PIMAGE_TLS_DIRECTORY tls_dir = (PIMAGE_TLS_DIRECTORY) (tlsDir.VirtualAddress + (FIELD_PTR) image);
    std::cout << tls_dir->AddressOfIndex << std::endl;
    FIELD_PTR *callbacks_ptr = (FIELD_PTR *) tls_dir->AddressOfCallBacks; // this is VA...
    if (!callbacks_ptr) return true;
    int i = 0;
    while (callbacks_ptr != nullptr) {
        FIELD_PTR callback_va = *callbacks_ptr;
        if (!callback_va) break;

        void (NTAPI *callback_func)(PVOID DllHandle, DWORD dwReason, PVOID)
        = (void (NTAPI *)(PVOID, DWORD, PVOID)) callback_va;
        tls_callbacks[i] = reinterpret_cast<void *>(callback_va);
        callback_func(image, DLL_PROCESS_ATTACH, NULL);
        callback_func(image, DLL_THREAD_ATTACH, NULL);

        callbacks_ptr++;
        i++;
    }
    return true;
}

I determined through IDA's breakpoints that these tls_callbacks were called, but the program still seems to be unable to run normally (the program did not crash, but entered an infinite loop, and I do not understand why "shellcodify" would affect the program's execution logic). Moreover, since I do not have the source code of the pe file, debugging is very difficult.
I really want to know what I have missed. If you find anything, please let me know.
Thank you very much.

[Wooyme]

After about a week of analysis, I finally found the secret of "TLS". For the program I want to "shellcodify", "tls_callbacks" is not critical; what is truly critical is the content between StartAddressOfRawData and EndAddressOfRawData in IMAGE_DIRECTORY_ENTRY_TLS. When a new thread starts, this content is copied to the address pointed to by NtCurrentTeb()->ThreadLocalStoragePointer+TlsIndex.

If anyone is still interested in this, you can refer to this link. tls_support.cpp
(The code in the link only supports 32bit, so you may need to modify it yourself)

I also found a more difficult problem to solve, which is that when the PE file uses GetModuleHandleEx and passes an address related to this PE file as the second parameter, GetModuleHandleEx will not work correctly because the memory allocated for the file after "shellcodify" does not belong to any "Module".

[DeHby]

After about a week of analysis, I finally found the secret of "TLS". For the program I want to "shellcodify", "tls_callbacks" is not critical; what is truly critical is the content between StartAddressOfRawData and EndAddressOfRawData in IMAGE_DIRECTORY_ENTRY_TLS. When a new thread starts, this content is copied to the address pointed to by NtCurrentTeb()->ThreadLocalStoragePointer+TlsIndex.

If anyone is still interested in this, you can refer to this link. tls_support.cpp (The code in the link only supports 32bit, so you may need to modify it yourself)

I also found a more difficult problem to solve, which is that when the PE file uses GetModuleHandleEx and passes an address related to this PE file as the second parameter, GetModuleHandleEx will not work correctly because the memory allocated for the file after "shellcodify" does not belong to any "Module".

Thank you, sir, my C++ class static instance code has a crash caused by TLS template data not being copied, and I solved the problem according to your idea