Shellcode is imploding on wine/lutris.

[daemitus]

var shellcode = new Reloaded.Injector.Shellcode(thisProcess); <- kaboom.

I've got really no idea why this is happening. I was troubleshooting why our Linux folk couldn't run my .NET 5 test builds. I can allocate just fine with ExternalMemory.

Linux rlpc 5.8.0-59-generic #66~20.04.1-Ubuntu SMP Thu Jun 17 11:14:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

2021-07-04 20:21:40.016 -04:00 [ERR] A fatal error has occurred.
System.Exception: Failed to allocate memory using VirtualAlloc/VirtualAllocEx
   at Reloaded.Memory.Buffers.MemoryBufferHelper.Run[T](Int32 retries, Func`1 function)
   at Reloaded.Memory.Buffers.MemoryBufferHelper.Allocate(Int32 size, Int32 minimumAddress, Int32 maximumAddress, Int32 retryCount)
   at Reloaded.Assembler.Assembler.AllocateResult(Int32 resultSize, Int32 retryCount)
   at Reloaded.Assembler.Assembler..ctor(Int32 textSize, Int32 resultSize)
   at Reloaded.Injector.Shellcode..ctor(Process targetProcess)
   at Dalamud.Injector.EntryPoint.Inject(Process process, DalamudStartInfo startInfo)
   at Dalamud.Injector.EntryPoint.Main(Int32 argc, IntPtr argvPtr)

[Sewer56]

Hard to really see what's going on here, I really think the best course of process is to try debugging here. Of course, with Wine, that'd be a bit difficult, so you probably want to do your Console/Debug/Trace writelines.

Quick question: Have you tried using Reloaded.Memory.Buffers standalone? Just use the same MemoryBufferHelper.Allocate() API. It may be good to debug the failing component on its own.

[daemitus]

In my brief time before I need to head out to the gym this morning:

buffers get allocated just fine with the helper methods when created manually, but however the assembler does it blows up.

More to follow later.

[daemitus]

Although my sample buffers were on the target process, meanwhile the assembler uses the host process. Maybe there's a difference somehow.

[daemitus]

AllocateText(0x10, 3);
AllocateResult(0x10, 3);

Apparently it can't allocate a 2nd time on the same buffer. Order of the above 2 lines doesn't matter. Size doesn't matter. Using a different buffer for the result works fine.

Looks like I'm headed into the buffer implementation itself next.

(edit) well its not quite right to say the same buffer. but the bufferHelper.allocate twice.

[daemitus]

Marshal.LastWin32Error is returning 487.

AllocateText...
Alloc into 0x67FE0000 11000

AllocateResult
(Fail1) Alloc into 0x7B000000 9000
(Fail2) Alloc into 0x7B000000 9000
(Fail3) Alloc into 0x7B000000 9000

Looks like subsequent allocations are going into wacky addresses for some reason.

[daemitus]

Going to close this. There's clearly way more going on that I don't understand at the moment. Copied most of your injector out so that I could debug things, LoadLibraryW is straight up throwing access violations now when run from a remote thread (even in the same process as the injector).