On the contrary I'm working on a fix that will run SROBot with the gameguard version intact =).
Basically silkbot.exe is just a generic loader that sits and waits for sro_client.exe to be loaded ( copy your notepad.exe and rename the copy to 'sro_client.exe' then execute it and attach ollydbg to it and you'll see that silk.dll is injected ). Basically there's 2 circumstances. Gameguard is pre-empting it and loading before it can inject its code.. thus hiding it from the process list ( like I said a loader made using windows would be more efficient since hiding the window would prevent the game from drawing ), however there's one other thing that could be happening. Silkbot is injecting silk.dll when sro_client.exe is loaded ( it can happen since sro_client.exe executes gameguard.des, which means it's 100% loaded and mapped into memory first.. ) and gameguard is unloading the module from memory.
I'm banking on the second one since gameguard is lame as hell. Since I know that silkbot.exe simply injects silk.dll ( that's it ) into sro_client, I'm going to simply make an injector similar to my gunbound one that will inject through gameguard into sro_client. The source-code will be posted along with the binary and the bot will run with gameguard intact.
There's also 1 other thing:
Reading into sro_client.exe ( the dumped one.. i TOLD you I had the source now since I have the ASM which means I can patch gameguard checks ).. I found that the source of this error:
sro_client.exe(3644) - Unhandled Exception ACCESS_VIOLATION (0xc0000005) at address 0x00550a62
in module C:\Program Files\Silkroad\sro_client.exe(2006-03-07:10-28-12).
Registers:
EAX 00000000 EBX 00000000 ECX 01F23E08
EDX 012869D8 ESI 00000000 EDI 00000011
CS:EIP 0000001B:00550A62 SS:ESP 00000023:0012D648 EBP 00000023
C:\Program Files\Silkroad\sro_client.exe at address: 550a62
C:\Program Files\Silkroad\sro_client.exe at address: 559b19
Is caused by a mov operation following a conditional jump that is not taken resulting in an unhandled exception which effectively kills the process. So simply put, patching this mov statement ( it's a jnz, mov, retn.. so the mov does nothing important ) may disable the need to run gameguard to continue playing. We shall see, as I am patching my client at this very moment to see if the more simplistic solution works.
00550A62 C605 00000000 00 MOV BYTE PTR DS:[0],0
As you can see.. that's redundantly stupid.. mov [0],0 is a sure-fire crash. I'll patch it with NOPs and see what happens.