Converting this code to support Windows 98

[Dark Pallys]

Hey there everyone..
I'm pretty new in this forum and also with Assembly, to be honest I haven't programmed anything in Assembly.
I'm a VB Programmer and I work with some C/C++
But well that's not the reason I'm here hehe.

On the forum I work at one of our old staff members released a DLL for the community to help them.
What the DLL does is, encrypt the data that has been input with XTEA Encryption, and then inject itself into the process of the game and then hook the winsock send function and send the encrypted data through it.

The problem is the DLL isn't compatible with Windows 98, and the creator of the DLL has retired sometime ago.
It would be of great help if anyone of you could help me on making this DLL Windows 98 compatible.

I'm attaching the source code of the project.

Thank you

[sanzilla]

I really don't know anything about vb , anyway ,
when calling a windows API you have different two versions of same API , UNICODE and ASCII version , this may be to problem at most time , anyway I does not read your code . In win9x the UNICODE API are not working , then you have to fix them .

/* This code may can make some compile errors */
#ifdefine UNICODE
#undef UNICODE
#endif

most of the time this can be the case , but there are some other cases, you can find some list of importing APIS that are using by your dll file . I really does not know very deatial knowledge about reengineering , however you can use a tool like PEExplore or dumpbin that comes with the microsoft visual studio 6.0 . The reverse enginering is another subject , and there are many other tools as well shuch as IDA pro . Anyway what you should do is get a list of import API names that importing by the dll file and then find for UNICODE ones , if there are UNICODE onces , the problem is this . And you not find it the problem is clearly not the one that I mentioning .
please note that is the problem is this I cannot future help you on reverse engineering and make a sugary to your dll file and fix it . anyway somebody will help you here .

anyway let me ask you a question , why bother win9x back ?what are the advantages that you find that does not in winNT let me know !

[Dark Pallys]

The creator of this DLL in MASM said that the reason that the DLL only worked on Windows NT and up is because of the hooking and injecting functions that the DLL uses.

I don't think you really got what I meant in the first post..
or maybe i just didnt understand ur post :p

basically what i want to do is..
i have the sources of this dll made in masm.
i need to make it compatible to windows 98..
the reason is because in my stats, windows 98 is the 2nd most used OS for my programs.

please help

[Ancient Dragon]

My advice: rewrite it in C or C++. If the data is sent across serial port then use MSCom1 dll for the communications -- I thik its probably compatible with Win98. Use sokets if the data is sent across the internet.

[Dark Pallys]

My advice: rewrite it in C or C++. If the data is sent across serial port then use MSCom1 dll for the communications -- I thik its probably compatible with Win98. Use sokets if the data is sent across the internet.

But apparently the only thing I need to change is the hooking and injection method, can't any of you guys help me on that? Rewriting the DLL in C/C++ is the very last option that I will take because the main reason it was made in MASM is because of the size of the file and also the speed in which it works, and C/C++ wont really give us the same performance as MASM does

[sanzilla]

But apparently the only thing I need to change is the hooking and injection method, can't any of you guys help me on that? Rewriting the DLL in C/C++ is the very last option that I will take because the main reason it was made in MASM is because of the size of the file and also the speed in which it works, and C/C++ wont really give us the same performance as MASM does Writing the whole software componment (the whole dll file ) again is a good advice ,but this is not the only choice , the net one is using reengineering method to change and do a sugary to your dll file . This sounds like something harder . You may feel writing the whole DLL once again easy than that .

To be more clear for this problem , let us know what is the full prototype of your call . What is that call ? then we can clear what's the problem . or you can you use the errorlook program for the etract error number and the relevant information for the error .

One of a main difference between the C++/C and the VB is that VB code is linked with it's own framework (its own dll files) . But C/C++ is calling to the Windows APIs . Anyway this won't the trouble in here . Thus beacuse The OP said that the DLL is written using MASM.

Thank you for your interest in MASM anyway !

[Ancient Dragon]

But apparently the only thing I need to change is the hooking and injection method, can't any of you guys help me on that? Rewriting the DLL in C/C++ is the very last option that I will take because the main reason it was made in MASM is because of the size of the file and also the speed in which it works, and C/C++ wont really give us the same performance as MASM does

I realize that rewriting a dll can be a difficult and time consuming task, especially if you paid someone to write the original and now find yourself redoing what he did. That often happens regardless of who writes the program -- been there and done that too.

>>and C/C++ wont really give us the same performance as MASM does
Untrue in most programs today. Use a compiler with very good optimizing (such as Microsoft Visual C++) and it can often outperform any code you write manually. C++ code tends to be larger than C, but if it is running on modern desktop computers it doesn't really make much of a difference. 20 years ago I could have agreed with you, but not any more.

[Dark Pallys]

Writing the whole software componment (the whole dll file ) again is a good advice ,but this is not the only choice , the net one is using reengineering method to change and do a sugary to your dll file . This sounds like something harder . You may feel writing the whole DLL once again easy than that .

To be more clear for this problem , let us know what is the full prototype of your call . What is that call ? then we can clear what's the problem . or you can you use the errorlook program for the etract error number and the relevant information for the error .

One of a main difference between the C++/C and the VB is that VB code is linked with it's own framework (its own dll files) . But C/C++ is calling to the Windows APIs . Anyway this won't the trouble in here . Thus beacuse The OP said that the DLL is written using MASM.

Thank you for your interest in MASM anyway !

I'm not sure about what you meant by "prototype of your call" but these are the functions which are used and aren't available in Windows 98...

INVOKE VirtualAllocEx,Process,NULL,TotalLength,MEM_COMMIT+MEM_RESERVE,PAGE_EXECUTE_READWRITE
INVOKE VirtualFreeEx,Process,AllocatedMemory,0,MEM_RELEASE
INVOKE CreateRemoteThread,Process,NULL,NULL,AllocatedMemory,PacketInfo,NULL,NULL
INVOKE CloseHandle,RemoteThread <-- don't know if this one exists in Window 98
INVOKE WaitForSingleObject,RemoteThread,INFINITE <-- don't know if this one exists in Window 98

The users in Windows 98 say the program doesn't return any errors at all, it just doesn't do anything when they activate the functions...
I might have put some error handling so the errors wouldn't show up, but still..

I realize that rewriting a dll can be a difficult and time consuming task, especially if you paid someone to write the original and now find yourself redoing what he did. That often happens regardless of who writes the program -- been there and done that too.

>>and C/C++ wont really give us the same performance as MASM does
Untrue in most programs today. Use a compiler with very good optimizing (such as Microsoft Visual C++) and it can often outperform any code you write manually. C++ code tends to be larger than C, but if it is running on modern desktop computers it doesn't really make much of a difference. 20 years ago I could have agreed with you, but not any more.

I don't think I could possibly rewrite this DLL neither in MASM or C/C++, to be honest I don't know much of this languages, I know VB6 the most and I can understand most C/C++..
I assume it's not much to change to adapt the DLL to Windows 98, as I mentioned above its only a few API calls which can't be done in Windows 98.
Injecting a DLL into a process can't be that hard in Windows 98, or can it?

[Dark Pallys]

*bump*
please help me, I'd really appreciate it