- Joined
- May 26, 2007
- Messages
- 5,545
- Reaction score
- 1,315
[SIZE=+2]What is HanDes.dll for?[/SIZE]
[SIZE=+1]Contents[/SIZE]
Introduction
How to Use the DLL
Code Analysis
Dispelling Myths
[SIZE=+1]Introduction[/SIZE]How to Use the DLL
Code Analysis
Dispelling Myths
You must be registered to see links
HanGame provide secure logins for a number of popular on-line games. The HanDes.dll was created by them to aid users logging in securely from public access points.The only time game.exe will use HanDes.dll is if you pass it the right parameters from the command line (or your launcher). It takes 3 optional parameters / arguments:-
- /ENC=
- /ID=
- /PWD=
Whatever text follows these arguments is passed to HanDes.dll along with a clear response buffer. What should happen is that the text that goes in should be decrypted and placed in the output buffer.
What actually does happen, is that a fatal exception occurs within the DLL when it is called upon to do the decryption.
Try this from the command line in your game folder:-
Code:
C:\Personal Priston Tale>KPT1977NoXTrap2b.exe /HANGAME /ENC=adc /ID=abd /PWD=dcbWhat is always true is that it doesn't work, and I don't know why. I've never seen a launcher that provides arguments which HanDes.dll will accept without crashing.
From the code, I can see that the responses from HanDes should be put into the login packet, and the login screen (up until character selection) is largely bypassed.
[SIZE=+1]How to Use the DLL[/SIZE]
I have created a program which will take information from the user and pass it to the DLL, then it will tell you what the DLL sent back. (or, more likely, just crash)
game.exe only ever calls the DecryptFunc() of HanDes.dll. And the server (upon recieveing a HanDes Login packet) will call the EncryptFunc() of HanDes.dll.
The function prototypes for these exports are:-
Code:
int __stdcall DecryptFunc(char *,char *);
int __stdcall EncryptFunc(char *,char *,long,unsigned char);My program HanDes_Text.exe can be downloaded with full source in freeBASIC from the following locations:-
You must be registered to see links
You must be registered to see links
You must be registered to see links
You must be registered to see links
You must be registered to see links
You must be registered to see links
[SIZE=+1]Code Analysis[/SIZE]
This is how game.exe actually uses HanDes.dll. First lets look at that /HANGAME parameter. Here's how it's processed:-
Code:
subHanDesProc:
sub esp,200 ; Make 512 bytes free on the stack
push edi
xor eax,eax
mov ecx,20
mov edi,offset game.0336C9D8
rep stos dword ptr [edi]
push 100 ; /Arg4 = 100
lea eax,[local.127] ; |
push eax ; |Arg3 => offset LOCAL.127
push offset game.005E49DC ; |Arg2 = ASCII "/HANGAME"
push offset game.szCmdLine ; |Arg1 = game.szCmdLine
mov dword ptr [336F3B8],0 ; |
call subStrInStr ; \game.subStrInStr
add esp,10
test eax,eax
je short .NoHANGAME
mov dword ptr [bHanGame],1
jmp short 00511D48
.NoHANGAME:
mov eax,[bHanGame]
test eax,eax
je .QuitThere is some "waste code" in here between .NoHANGAME and je .Quit where the je short .NoHANGAME could simply be a je .Quit. (it doesn't "bum" much of a code cave, but if you're keen to try, remember that a "long" jump takes up more space than a "short" one, so you'd have to shift the instructions following it down by 3 bytes or so.)
Aside from that first check on bHanGame, all the others are associated with the login screen. Here is a summery of the changes to the game if bHanGame is 1 and not it's normal 0.
- Change URL from "http://pristontale.ndolfin.com" to "http://pristontale.hangame.com"
- Change URL from "http://members.ndolfin.com/Mypage/FindUserID/UserIDFind.aspx" to "http://member.hangame.com/permissionDeniedView.nhn?code=bbswrite&next=http://pristontale.hangame.com&homeurl=http://pristontale.hangame.com"
- Major change to jump tables when looking up UserName and Password.
Now lets look at how the other parameters are processed.
Code:
.HANGAME:
push 100 ; /Arg4 = 100
lea ecx,[local.127] ; |
push ecx ; |Arg3 => offset LOCAL.127
push offset game.005E49D4 ; |Arg2 = ASCII "/ENC="
push offset game.szCmdLine ; |Arg1 = game.szCmdLine
call subStrInStr ; \game.subStrInStr
add esp,10
test eax,eax
je .Quit
lea edx,[local.63]
push edx ; /Arg2 => offset LOCAL.63
lea eax,[local.127] ; |
push eax ; |Arg1 => offset LOCAL.127
call [<&HanDes.DecryptFunc>] ; \HanDes.DecryptFunc- Look for the switch in the remaining command line
- Get a pointer to the value which follows "=" (no more than 0x100, or 256 bytes to be returned in the space set aside on the stack.
- Pass that, and another buffer in the stack to DecryptFunc()
In any event, with the function prototypes, rather than doing away with HanDes.dll, you could simply write your own, which you know won't cause an exception to anything and try to use it with your client to get more secure logins. ^_^
[SIZE=+1]Dispelling Myths[/SIZE]
I'm writing about HanDes.dll, not because it's interesting, but because it's a giant "Red Herring" for people looking for all sorts of things.
Despite anything else you have read here on the forums, these things are fact:-
- it doesn't work (as it is)
- it isn't a good implementation
- it is only used at login
- it usually crashes (part of point b)
- it's nothing to do with files or packets
- it only works in one direction (client decrypt, server encrypt... however, as our 4096 server is a modified client, is only imports decrypt too... so there is modification that needs to be done there too.)
- it's the client that starts it (so you decrypt before you encrypt???)
- it will only handle up to 16 characters of information, (game.exe limit) and return no more than 256. (maximum buffer given to HanDes.dll)
- remove it, and free up some space both in your client and serverNote: the vulnerability here. If someone knows how to use it and can use a client which has it, and if your server doesn't, they could crash your server by sending a /HANDES login request. So be very careful how you remove it from your server.
Also Note: that the tendency for HanDes.dll to crash what-ever process is hosting it means this is a server vulnerability already! - re-write the DLL used both ends to actually give each player a unique one time login code... via some method that doesn't go via internet.
- You keep players mobile number in database. (Securely, of course)
- Players log in on website (without password) or sends an SMS text to your server
- Your web / SMS server sends SMS to the players phone.
- They type the SMS into the launcher, which gives it to game.exe
- game.exe decodes it with HanDes.dll and sends the special login packet to server
- Server encodes it back to unique login ID with HanDes.dll
- Server looks up which account the web / SMS server assigned that ID to and sends server and character data back to the client for that account.
Using this method, any key-logger on the players machine will not get any information that an identity thief can use to log in to the players account, and if you use SMS entirely (with no web request) then no packet information will be of use either. If players request a code via a web page, their login details for that page must not be the same as their non-HANDES login.
You could send a Fax, MMS message or Email to them instead of an SMS on their mobile, but must assume they have a fax machine wherever they play or that their Email account is secure.
You may ask them to enter the code by clicking characters or symbols off a display, to stop a key-logger too. So the SMS / Email could be "Ball Cat Snake Apple Cocktail Dragon", and they click those icons from a pad with lots of random but easily discernible symbols.
You can (like capcha / humaniser) do this securely on web page too, but don't display a number of separate images, merge them into a single temporary image with imagemagick or a flash program or something. The url for the embedded image should not be meaningful.
Oh yes... you must also ensure that you never send the same code to two players. It must be very strictly an one time password. And with no more than 16 characters, you will run out of free passwords quickly. There must also be no serialisation of these passwords when given out, or a cheat can guess which one might be given out soon that has not yet been used.:O:
Unless I discover, or someone donates more information, that's all I'm going to say on the subject for this guide. I hope it proves useful, either in helping you decide how to make better use of the library, or how to remove all traces of it cleanly.
Good luck to you all.
Last edited:
