edxSilkroadLoader_Lite Beta 2

09/09/2009 03:06 pushedx#1
First, I'd like to say thanks to all the people who tested and offered valuable feedback for the first beta! I have went ahead and fixed a number of small things to make the tool more usable and accessible for people as the first beta thread has grown pretty large and contains a lot of outdated information. No new "features" have been added to this loader as much as just bug fixes and other minor improvements. This will be the last planned update for this version of the loader unless I broke something in this release.

Compatibility:

First, you must always update Silkroad to the latest version before using the loader. When in doubt, don't use it and ask for clarifications on any question you might have after an update. Better safe than sorry!

Unpacked Client Instructions:
1. Make a backup copy of your current sro_client.exe in your Silkroad directory
2. Copy over the new sro_client.exe into your Silkroad directory
3. Use the loader normally.

If you need the tool to unpack the client, stripper_v213b9, send me a PM.

ISRO - Fully supported. Requires an unpacked client to work properly.

KSRO - Fully supported. Requires Korean locale to be set on your PC to enter the Korean captcha. Requires an unpacked client to work properly as of 2.639. However, check out the [Only registered and activated users can see links. Click Here To Register...] project if you do not want to or cannot easily switch your PC locale to Korean.

TSRO - Not supported. As of September 10th, TSRO has blocked all foreign IPs. This means I can't really test or update to test easily.

VSRO - Not supported. VSRO has added XTrap to the game to serve as protection. Since XTrap is similar to GameGuard in a sense, the loader is not officially supported at this time until I can test to see if it still works in XP since XTrap does not work for me in Windows 7.

CSRO - Fully supported. However, CSRO has their own client based protection, so caution is advised before using any 3rd party programs on your account.

JSRO - Not supported. JSRO uses GameGuard, so edxSilkroadLoader is not compatible. However, if GameGuard were to be disabled, then it should work like the other Silkroad versions.

Unpacked Clients:

ISRO - 1.218 [Only registered and activated users can see links. Click Here To Register...]
KSRO - 1.646 [Only registered and activated users can see links. Click Here To Register...]

Instructions:

Step 1. Download and extract the edxSilkroadLoader_Lite_beta2 package. You may run it from anywhere you wish.
[Only registered and activated users can see links. Click Here To Register...]

Step 2. Run "edxSilkroadLoader_Lite.exe".
[Only registered and activated users can see links. Click Here To Register...]

Step 3. Click "Add" under Silkroad Directories. Navigate to your Silkroad directory and select your "sro_client.exe" file. (Note, it's ok if you select any file as long as it's in the Silkroad directory!) Repeat this step for all your Silkroad versions.
[Only registered and activated users can see links. Click Here To Register...]

Step 4. Choose the Silkroad directory you wish to use and click Launch after setting the Division and Login server you wish to use.
[Only registered and activated users can see links. Click Here To Register...]

Step 5. Wait until a new dialog appears. Configure your patches for this particular client.
[Only registered and activated users can see links. Click Here To Register...]

Step 6. Click "Start!" to run the client or "Terminate" to exit the client. Please wait up to a few minutes for the first client to actually start. If no client actually runs after 3 minutes, your antivirus/security programs have blocked the loader/dll.You will need to add the loader and the dll to your safe file list.

Step 7. Repeat Steps 4-6 for each client you wish to run. You may close the loader at any time you wish or just leave it open.

Updates:
  • Loader GUI invalid path logic fixed. Invalid paths will now be removed automatically.
  • Window X/ESC now terminates the client. Launch/Enter starts the client.
  • ASprotect Stripper generated clients should now be compatible (ISRO/KSRO/JSRO)
  • Packed client detection with forced exit (packed clients are not supported at this time.)
  • Added one instance support so only one Loader window can be active at a time.
  • Changed project configuration to use the static MSVCRT to eliminate the need for runtimes.
  • Project and release thread reorganization.

Help:

Leave a comment in this thread or send me a PM if you need any!

Final Notes:

Attached in the updated version along with the source code. This is just a minor update and is not the "next version" of the loader I have been talking about previously. The "next version" still has quite a bit work left on it, but is looking good so far.

[Only registered and activated users can see links. Click Here To Register...]

Enjoy :)
09/09/2009 03:12 saiyansrule#2
thanks drew! :mofo:
09/09/2009 03:28 theoneofgod#3
#Sticky

:)
09/09/2009 03:57 randomguy101#4
i keep getting

[??????]
(computer specs)

error, anyone know how to fix this?
09/09/2009 05:36 pushedx#5
Quote:
Originally Posted by randomguy101 View Post
i keep getting

[??????]
(computer specs)

error, anyone know how to fix this?
Which Silkroad version are you using? I've only seen errors like that on start up with two version: VSRO when you do not enable English patch and KSRO when there is no English patch and no korean locale enabled. Can you start that Silkroad version using Silkroad.exe normally?
09/09/2009 06:50 Kazuyaš#6
um....?

[Only registered and activated users can see links. Click Here To Register...]
09/09/2009 09:08 outsider9999#7
Hi, i become everytime this error on Tsro >

[Only registered and activated users can see links. Click Here To Register...]
09/09/2009 10:34 audi0slave#8
Quote:
Originally Posted by outsider9999 View Post
Hi, i become everytime this error on Tsro >

[Only registered and activated users can see links. Click Here To Register...]

You already have the sro_client english pacthed.Remove the english patch option from the loader.


@Drew:Works perfectly well on taiwan sro.Great job !:)
09/09/2009 11:11 outsider9999#9
Ty, it works now :D
09/09/2009 11:14 bheaven#10
working very well now.

i thought about adding some error reporting during the dll inject since it currently only "knows" two errors.
for example if LoadLibrary fails the error message "cannot find file" is return even if the file exists and another error occured whose errorcode could be retrieved by calling GetLastError().

i tried it by adding FormatMessage into the assember code inside the InjectDLL function but i think i failed :cool:
09/09/2009 13:19 _HouseMusicx3#11
works good thx
09/09/2009 14:38 pushedx#12
Thanks everyone for the feedback. :)

Quote:
Originally Posted by Kazuyaš View Post
um....?
I've not seen anything like that before. I don't know even how that's possible since that box is cleared and the contents are re-added each time you select a different Silkroad folder. I also have csro installed and no issues adding their divisions. I'll double check the code though, but for now, try just removing the csro path and readding it. Your csro divisioninfo.txt file isn't modified is it? Is the problem repeatable or was only that one time?

Quote:
Originally Posted by bheaven View Post
working very well now.

i thought about adding some error reporting during the dll inject since it currently only "knows" two errors.
for example if LoadLibrary fails the error message "cannot find file" is return even if the file exists and another error occured whose errorcode could be retrieved by calling GetLastError().

i tried it by adding FormatMessage into the assember code inside the InjectDLL function but i think i failed :cool:
This injection method is very old and primitive and trying to modify it would be really hard. FormatMessage is possible to use though since it's exported from kernel32. I would suggest writing a new custom injection method for that rather than modifying this one.

My other (real) injection method is really nice, but not released at this time (it's overkill for most people). I wrote it quite a while ago that I'd probably change a few things in how it works now. Later, when I have some time, I'll write an article about it and how it was done because it's powerful, pretty simple to use, and can be used for all sorts of fun things. The concepts used for the injection method originate from this article: [Only registered and activated users can see links. Click Here To Register...].

The actual injection function would look like this:
Code:
// New function for injecting a DLL into a process using a asm stub in the process
void InjectDLL(HANDLE hProcess, DWORD injectAddress, const char * dllName, const char * funcName)
{
	// Max size of data section
	DWORD dataSize = 512;

	// Max size of code section
	DWORD codeSize = 512;

	// Pointer to the stub
	LPVOID lpBuffer = 0;
	
	// Size of the stub
	DWORD dwSize = 0;

	// Generate a memory block in the target process to write to (our asm stub uses this address too)
	LPVOID allocAddress = VirtualAllocEx(hProcess, 0, dataSize + codeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);;

	// Setup an asm generator
	AsmStubGenerator asmStub(dataSize, codeSize);

	// Call our function to store the pointer to the code and size
	AsmLoaderStub(lpBuffer, dwSize);

	// Initialuze the asm stub generator with the data
	asmStub.Initialize(lpBuffer, dwSize, 0xDEADF00D);

	///////////////////////////////////////////////////////////////////////////////
	// This is the section that we fill in the asm stub's place holder data		 //
	///////////////////////////////////////////////////////////////////////////////

	// STRING's

	CHAR error1[1024] = {0};
	_snprintf(error1, 1023, "The DLL \"%s\" was not able to be loaded successfully.", dllName);

	CHAR error2[1024] = {0};
	_snprintf(error2, 1023, "The function \"%s\" was not able to be loaded from the DLL successfully.", funcName);

	DWORD string_User32DLLName		= asmStub.AddString("user32.dll");
	DWORD string_MessageBoxAName	= asmStub.AddString("MessageBoxA");
	DWORD string_InjectDLLName		= asmStub.AddString(dllName);
	DWORD string_ErrorMsgTitle		= asmStub.AddString("Fatal Error");
	DWORD string_InjectDLLFunc		= asmStub.AddString(funcName);
	DWORD string_Error1				= asmStub.AddString(error1);
	DWORD string_Error2				= asmStub.AddString(error2);

	asmStub.SetPlaceHolder( 0, string_User32DLLName);
	asmStub.SetPlaceHolder( 2, string_MessageBoxAName);
	asmStub.SetPlaceHolder( 5, string_InjectDLLName);
	asmStub.SetPlaceHolder( 7, string_ErrorMsgTitle);
	asmStub.SetPlaceHolder( 8, string_Error1);
	asmStub.SetPlaceHolder(12, string_InjectDLLFunc);
	asmStub.SetPlaceHolder(14, string_ErrorMsgTitle);
	asmStub.SetPlaceHolder(15, string_Error2);

	// DWORD's

	DWORD dword_LoadLibraryA		= asmStub.AddDword(PtrToUlong(GetProcAddress(LoadLibrary("kernel32.dll"), "LoadLibraryA")));
	DWORD dword_GetProcAddress		= asmStub.AddDword(PtrToUlong(GetProcAddress(LoadLibrary("kernel32.dll"), "GetProcAddress")));
	DWORD dword_ExitProcess			= asmStub.AddDword(PtrToUlong(GetProcAddress(LoadLibrary("kernel32.dll"), "ExitProcess")));
	DWORD dword_MessageBoxA			= asmStub.AddDword(0);
	DWORD dword_DLLHandle			= asmStub.AddDword(0);
	DWORD dword_OEP					= asmStub.AddDword(injectAddress);
	DWORD dword_Alloc				= asmStub.AddDword(PtrToUlong(allocAddress));

	asmStub.SetPlaceHolder( 1, dword_LoadLibraryA);
	asmStub.SetPlaceHolder( 3, dword_GetProcAddress);
	asmStub.SetPlaceHolder( 4, dword_MessageBoxA);
	asmStub.SetPlaceHolder( 6, dword_LoadLibraryA);
	asmStub.SetPlaceHolder( 9, dword_MessageBoxA);
	asmStub.SetPlaceHolder(10, dword_ExitProcess);
	asmStub.SetPlaceHolder(11, dword_DLLHandle);
	asmStub.SetPlaceHolder(13, dword_GetProcAddress);
	asmStub.SetPlaceHolder(16, dword_MessageBoxA);
	asmStub.SetPlaceHolder(17, dword_ExitProcess);
	asmStub.SetPlaceHolder(19, dword_OEP);
	asmStub.SetPlaceHolder(20, dword_Alloc);

	// ARRAY's

	// This will save the original 6 bytes at OEP to the asm stub so the DLL can restore them
	BYTE oepBytes[6] = {0};
	DWORD read = 0;
	ReadProcessMemory(hProcess, UlongToPtr(injectAddress), oepBytes, 6, &read);

	DWORD addr_OepBytes = asmStub.AddArray(oepBytes, 6);

	asmStub.SetPlaceHolder(18, addr_OepBytes);

	// Write the workspace to the process now
	WriteProcessBytes(hProcess, PtrToUlong(allocAddress), asmStub.GenerateAsmStub(allocAddress), asmStub.GetTotalSize());

	// Calculate the OEP of the workspace
	DWORD oep = PtrToUlong(allocAddress) + dataSize;

	// Now that the patch is written into the process, we need to make the process call it
	BYTE patch2[6] = {0xE8, 0x00, 0x00, 0x00, 0x00, 0x90};

	// Calculate the JMP offset +5 for the FAR JMP we are adding)
	DWORD toCC = oep - (injectAddress + 5);

	// Write the offset to the patch
	memcpy(patch2 + 1, &toCC, sizeof(toCC));

	// Make the patch that will JMP to the codecave
	WriteProcessBytes(hProcess, injectAddress, patch2, 6);
}
while the code to inject would look like this:
Code:
// This is the user function to assemble - a dll loading stub
void AsmLoaderStub(LPVOID & lpBuffer, DWORD & dwSize)
{
	// This is the required macro we need to place in this function
	// to setup the aseembly code.
	ASSEMBLE_MACRO(lpBuffer, dwSize);

	__asm
	{
// The assembly code needs to have this code start marker
buffer_begin:

// Attach debugger loop
//START:	JMP START

		// Save registers
		PUSHAD

		// User32 DLL Loading
			// user32.dll string address
			PUSH 0xDEADF00D							// 0
			// LoadLibraryA address
			MOV EAX, 0xDEADF00D						// 1
			MOV EAX, [EAX]
			// Call LoadLibraryA
			CALL EAX

		// MessageBoxA Loading
			// MessageBoxA function name
			PUSH 0xDEADF00D							// 2
			// User32.dll address
			PUSH EAX
			// GetProcAddress address into eax
			MOV EAX, 0xDEADF00D						// 3
			MOV EAX, [EAX]
			// Call GetProcAddress
			CALL EAX
			// Move the address of MessageBoxA into the user stored address
			MOV ECX, 0xDEADF00D						// 4
			MOV [ECX], EAX

		// DLL Loading
			// DLL name
			PUSH 0xDEADF00D							// 5
			// Move the address of LoadLibraryA into EAX
			MOV EAX, 0xDEADF00D						// 6
			MOV EAX, [EAX]
			// Call LoadLibraryA
			CALL EAX

		// Error Checking
			CMP EAX, 0
			JNZ CONTINUE1

			// MessageBox Error
			PUSH 0x10
			PUSH 0xDEADF00D							// 7
			PUSH 0xDEADF00D							// 8
			PUSH 0
			MOV EAX, 0xDEADF00D						// 9
			MOV EAX, [EAX]
			CALL EAX

			// ExitProcess
			PUSH 0
			MOV EAX, 0xDEADF00D						// 10
			MOV EAX, [EAX]
			CALL EAX

CONTINUE1:
			// Move the handle into our own variable
			MOV ECX, 0xDEADF00D						// 11
			MOV [ECX], EAX

			// GetProcAddress
			PUSH 0xDEADF00D							// 12
			PUSH EAX
			MOV EAX,0xDEADF00D						// 13
			MOV EAX, [EAX]
			CALL EAX

		// Error Checking
			CMP EAX, 0
			JNZ CONTINUE2

			// MessageBox Error
			PUSH 0x10
			PUSH 0xDEADF00D							// 14
			PUSH 0xDEADF00D							// 15
			PUSH 0
			MOV EAX, 0xDEADF00D						// 16
			MOV EAX, [EAX]
			CALL EAX

			// ExitProcess
			PUSH 0
			MOV EAX, 0xDEADF00D						// 17
			MOV EAX, [EAX]
			CALL EAX

CONTINUE2:
		// Pointer to origianl bytes
		MOV ECX, 0xDEADF00D							// 18
		PUSH ECX

		// OEP of process to write original bytes to
		MOV ECX, 0xDEADF00D							// 19
		MOV ECX, [ECX]
		PUSH ECX

		// Allocation buffer of the stub to free
		MOV ECX, 0xDEADF00D							// 20
		MOV ECX, [ECX]
		PUSH ECX

		// Call Initialize
		CALL EAX

		// Add ESP, C, since we have 3 parameters
		ADD ESP, 0xC

		// Restore registers
		POPAD

		// Return to OEP
		POP EAX
		SUB EAX, 5
		PUSH EAX
		RET

// The assembly code needs to have this code end marker
buffer_end:
	}
}
That setup is a lot easier to work with, but I never really explored the uses of the idea. I only wrote one example for loader dll injection code and didn't touch it since then. I will eventually look into adding a more customized error message though since the two simple ones I have aren't that telling, but I am confident in the reliability of the injection method I am using and it working across multiple OSs, which is why I use it rather than the alternatives generally known using DLLMain and LoadLibrary, CRT, etc...
09/09/2009 18:16 r7slayer#13
Hi Drew. Like to say thanx for the updated edxloader. but theres a little problem ive got. I think its similar to tha problem before. everytime i restart my pc and try to start edxSilkroadLoader i get the error i told you about before. So i goto the folder listed "%appdata%/edxLabs/edxSilkroadLoader" and delete the .ini file. This allows me to start the app. But whenever i try to add the Tsro sro_client.exe i get this error which is the same as the error i get when trying to start the loader.


Not sure whats causing this. somtimes it will allow me to add the sro_client.exe and allow me to use the loader most times it keeps giving me that error.
09/09/2009 18:55 glialka#14
thank you..2nd time with your loader, that my client goes form v1.207 to 1.175..yay...

now i have to reinstall the client(10 minutes) do the update (1 hour ) then have to try out the loader again ( will faill again )


FUCK THIS !(i dont give a damn for a freaking warning now )
But this loader is fucking my tsro whole the time..
09/09/2009 20:07 pushedx#15
Quote:
Originally Posted by r7slayer View Post
Hi Drew. Like to say thanx for the updated edxloader. but theres a little problem ive got. I think its similar to tha problem before. everytime i restart my pc and try to start edxSilkroadLoader i get the error i told you about before. So i goto the folder listed "%appdata%/edxLabs/edxSilkroadLoader" and delete the .ini file. This allows me to start the app. But whenever i try to add the Tsro sro_client.exe i get this error which is the same as the error i get when trying to start the loader.
Can you send me your "edxSilkroadLoader.ini" file as soon as it causes the crash before you delete it? That should not be happening at all. I'll try to think of why that could be happening by checking over my code, crashes like that mean something is really messed up.

Quote:
Originally Posted by glialka View Post
thank you..2nd time with your loader, that my client goes form v1.207 to 1.175..yay...

now i have to reinstall the client(10 minutes) do the update (1 hour ) then have to try out the loader again ( will faill again )


FUCK THIS !(i dont give a damn for a freaking warning now )
But this loader is fucking my tsro whole the time..
Sorry to hear you are having problems, but the loader makes absolutely no changes to any of your Silkroad files. It is a "loader", not a "patcher", all changes are done in memory at run time each client launch. The source code is included if you don't believe me. ;) There have been a lot of TSRO testers that have not had any problems using the loader and any issues with the version getting messed up that have reported so far. I have been testing heavily on TSRO and ISRO myself as well, so if it was changing anything, I'd notice it for sure.

I see that you made [Only registered and activated users can see links. Click Here To Register...]:
Quote:
thanks to your patcher..my client is v1.175..ty..
So it looks like you are using other programs that do make changes to your Silkroad files, which could be messing up your install.

All I can suggest to you is to make backup copies of your TSRO install folder before trying anything that makes changes or does PK2 editing. I have seen the error myself when not even using any other 3rd party programs, so I don't think it's specific to any 3rd party tools. I think it has to do with a messed up Media.pk2.

If you are on Vista/Win7, try running Silkroad.exe as admin or if you usually run it as admin, run it without the admin to see if the correct version comes up. Your Silkroad version simply can't revert back to such an old version on its own, so I suspect something else is going on.