[Tutorial][Guide] What is HanDes.dll for?

What is HanDes.dll for?

Contents

Introduction
How to Use the DLL
Code Analysis
Dispelling Myths

Introduction
http://img200.imageshack.us/img200/1354/logohangame.gif 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:-

1. /ENC=
2. /ID=
3. /PWD=

These options will only be analysed if the argument /HANGAME is also passed.

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=dcb

---

What happened? Nothing? Crash? Depends how the exception handlers are set up in your game.exe.

What 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.

How to Use the DLL
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);

---

So you can see how easy it is to write a program to use them.

My program HanDes_Text.exe can be downloaded with full source in freeBASIC from the following locations:-

RapidShare
MEGAUPLOAD
depositfiles
hotfile
zSHARE
UPLOAD☇NG

You can run the program by simply double clicking it... but you need to copy your HanDes.dll into the same folder.

Code Analysis
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 .Quit

---

There are some offsets in there from my 1977 KPT client that I've not named yet, because I don't fully understand them, The important point is that the memory location [bHanGame] which is normally 0 is set to 1.

There 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.

1. Change URL from "http://pristontale.ndolfin.com" to "http://pristontale.hangame.com"
2. 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"
3. Major change to jump tables when looking up UserName and Password.

So if you are keen to dump HanDes... seeing it as pointless waste of space, then remember there are large sections of code and data that can be cleaned out in those areas too. ^_^ Just label the location of bHanGame in your client, and look for references to it.

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

---

Each of the three switches is processed in the same way. Basically:-

1. Look for the switch in the remaining command line
2. 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.
3. Pass that, and another buffer in the stack to DecryptFunc()

It's inside HanDes.dll that any of these switches will cause an exception. The code of HanDes it's self is too complex for me to get a good handle on analysing... maybe it romanises Han symbols, and you'd have to pass some Hangul to it for it not to crash... I'm not sure.

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. ^_^

Dispelling Myths
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:-

1. it doesn't work (as it is)
2. it isn't a good implementation
3. it is only used at login
4. it usually crashes (part of point b)
5. it's nothing to do with files or packets
6. 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.)
7. it's the client that starts it (so you decrypt before you encrypt???)
8. 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)

IMHO there are only 2 useful things you could do with it.

1. remove it, and free up some space both in your client and server
   Note: 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!
2. 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.

i.e.

1. You keep players mobile number in database. (Securely, of course)
2. Players log in on website (without password) or sends an SMS text to your server
3. Your web / SMS server sends SMS to the players phone.
4. They type the SMS into the launcher, which gives it to game.exe
5. game.exe decodes it with HanDes.dll and sends the special login packet to server
6. Server encodes it back to unique login ID with HanDes.dll
7. 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.

This is how I believe it was meant to work. (I've seen other Asian games do something similar, as mobile phones are very popular, and so is account theft / password stealing and "key logging". Remember, they often play in arcades or cyber-café, using "public access" computers.)

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.

Can you write similar info about 4 functions in server that crypt (decrypt? encrypt?)?
If you don't know what I am talking about I can upload those functions here.

Quote:

---

Originally Posted by Vormav

Can you write similar info about 4 functions in server that crypt (decrypt? encrypt?)?
If you don't know what I am talking about I can upload those functions here.

---

I don't think I can do a better job than I already did with my Protocol / Encryption Library Guide (which I'm sure you have already read and tried out) though I admit, that most of the documentation of the working code is in the source code download rather than the thread.

I also know that the changes in compiler over the years, and probably some changes to the source code have made these 4 routines look very different in different clients. I have great difficulty tracking them down.

I'm going to check the download is "up to date" with my current source, as I know it missed a routine when it was first posted.

If there is more you know, or think I know that you would like explained in that thread, I suggest you drop me a post there, or a PM with pointers on how I can improve it.

Cheers. :wink:

what do you want to do with them vormav? I already have "converted" them to C#. Well, I could say 99% of it, I just cant handle with that "not random code anymore" stuff xD

(ty bob, I really have to try it again.)

Private correspondence suggests to me that Vormav is talking about the Header corruptions in BMPs and TGAs (which I've posted source to fix) or more likely the binary caches of the ASE files as SMD / SMB (animations) and INI files as INXs.

These are also a similar level of "obfuscation", although it doesn't make sense to store a large ASE text file in memory, and process it as such while playing... and the SMD and SMB are just a "dump" of the "in memory" form.

Actually SQL packets passing through same function but (probably) one of function variables set to for example 0 make them pass without encrypting them. I need to test that too, maybe tomorrow.
SMD formats are different story but maybe not so diff ;)
The stack pointer have positive value in functions that are connected to SMD conversion. Right now I am testing conversion from ASE to CAM (camera object in opening), I know how it work, I can animate it and it work with opening. Maybe I should rewrite that in C and see if I can create ASE to SMD converter.

I agree SMD is different story, but no so different.

But SQL isn't sent as "packets" TCP/IP is sent via packets, and if you use TCP/IP to communicate with remote SQL server then that will happen, but it can't go through these routines unless you have another PT server running on the remote server set as "DataServer"... if you just ask the SQL engine to do it for you, then SQL over TCP/IP has nothing to do with PT Server or Client executable, and should be secured by RSA/SSL encryption, possibly (preferably) over a VPN, unless it is internal LAN only.

Network "Named Pipes" are transmitted packeted by SMB (CIFS to the non-Windows world) over the hidden network share \\MyComputer\$IPC\name-of-my-pipe, (or smb://mycomputer/$ipc/name-of-my-pipe from SAMBA or CIFS based, non-Windows systems) which would also account for RPC transmissions. (Again different, but not so different :wink:)

On to SMD again... "heap" memory is used to create the SMD in memory from the ASE files. This usually looks like "Local.52" or something in Olly. They create a "stack frame" to access a private "heap", and restore the stack frame before returning to the primary function that called them.

Personally, I've looked at this code with a very critical eye on how the BMPs and TGAs are loaded... you can reduce the space on disk considerably if you convert them all to DDS or PNG files... either of which are excellent for this purpose.

I tried it with a installer, and reduced the setup.exe size by a massive amount getting it under 700Meg for the full 1.8Gig install. But of course, I had to turn them back into BMPs and TGAs for the game to use them.

If the game would use PNGs (or preferably DDS, which is native to DirectX and hardware accelerated anyway) then presumably the reduced size on disk would translate to considerably less IDE channel lock-up during mesh loading. (most noticeable when you approach a new field)

PNG is interesting, because the Zip compression library zlib by Mark Adler and Jean-loup Gailly is built into the executable already (linked as a .lib) leading to the string " inflate 1.1.4 Copyright 1995-2002 Mark Adler " and presumably connected to the exported functions SetExtChangeZip(), UnZipData(), UnZipDataToDirectory(), UnZipDataToFile(), UnZipFile(), ZipData() and ZipFile().

This would suggest they where considering some form of compression on the assets, but since it's never used (you can strip those exports and all the code related to them, and I see no change in the game) I presume either the idea was scrapped, or the person implementing it was fired because they didn't document what they where doing, so now nobody knows how to remove the dependencies on zlib.lib. XD

Of course, the PNG format has a similar etymology as they where using Zip compression (GZip & Deflate) to replace the patented Lempel-Ziv-Welch (LZW) compression used in GIF files and patented (now expired) by Compuserve, who where thinking of charging everyone who used a GIF on any web page at one point. :thumbdown:

Spoiler:

If you weren't heavily into computers in 1985 ask Wikipedia to tell you all about it.]http://en.wikipedia.org/wiki/Graphic...rchange_Format

Imagine having to pay 5 cents for every smiley, avatar or sig you ever posted on RZ!!! It caused quite a media stir, I can tell you.

Quote:

---

Originally Posted by bobsobol

But SQL isn't sent as "packets"[...]

---

O yes sorry you are quite correct it was late when I was writing that so I went to wrong address. I was planing to post this in your other thread too =P

So on client HanDes.dll encrypt and decrypt packets alone?

Quote:

---

Originally Posted by bobsobol

Personally, I've looked at this code with a very critical eye on how the BMPs and TGAs are loaded... you can reduce the space on disk considerably if you convert them all to DDS or PNG files... either of which are excellent for this purpose.

---

How about rewriting function that read .bmp and .tga to png/DDS? (both have alpha channel for transparency)
That would be odd?


In SMD something fishy going on, change of one small value lead to changing whole file from point where it was changed to bottom.

Quote:

---

Originally Posted by Vormav

So on client HanDes.dll encrypt and decrypt packets alone?

---

HanDes is one way. The client uses DecryptFunc() only, from the DLL, the Server uses EncryptFunc() only. Which is odd, since the server doesn't use it unless it gets a special login packet from the client (I guess, as I've not been able to create that packet) and the client only ever uses it when passed the arguments shown above in it's command line. :?: (I'll add that to the OP, it should be stated more clearly.)

It doesn't really have anything to do with packets either, though the UserID and Password (passed through HanDes or not) will be turned into a login packet.

Quote:

---

Originally Posted by Vormav

How about rewriting function that read .bmp and .tga to png/DDS? (both have alpha channel for transparency)
That would be odd?

---

I don't think it would be "odd". You can replace all the .BMPs in you meshes with .TGA, then save all your .BMPs as TGAs (that PT can read) and not use the .BMP loading routine at all.

I was interested by this, because TGA does support compressed froms... though fairly basic ones. In those forms, PT cannot read them at all... and if you are going to modify the code to accept a compressed image form, it may as well be a good one, no?

At that point I stopped messing with the texture and image loading routines, noticing that the uncompressed PCM wave files where an even bigger waste of space... and (as I've said elsewhere) worked on getting the client to load... well, most sound forms actually.

I got it to load MP3s and OGGs and XM Mod files and AC3s and AAC/MP4/M4A files... but only when used as "Background Music"... I wanted 3D control over the sound effects, and the library I used could give me that, but the game is normally static... Event happens sound is requested to play. If sound has not been loaded, load it first, if it is already in memory, just play from memory.

The sound library I pulled in as a DLL (and there are a number of good, and freely available ones you could use) actually allowed me to stream the sound in the background off the drive, so I didn't need to "load" anything "into memory". Then I could bypass that whole "asset already cached in memory" thing.

Spoiler:

That routine seems to be the same for every asset. Image, mesh, texture, sound, animation, whatever. So I guess it would leave more memory free for caching other things as well... but since I only did the background music, which outside these tests I usually disable anyway, I didn't see much improvement there.

I also discovered the base client I had modified wasn't a good one. And that's where that development stopped. I plan on re-introducing it to Butchered. At the very least, what I learned should go into a guide, I just need the time.

Quote:

---

Originally Posted by Vormav

In SMD something fishy going on, change of one small value lead to changing whole file from point where it was changed to bottom.

---

If you are not taking alignment / offsets into account, that's quite common. In a text file, if a line (or just a character) is added, comparison shows an inserted "thing", when the data is binary, comparators often compare offset against offset... and of course everything is different.

The file is still essentially a sequential stream, despite being in a binary form. I also note (from looking at cSelect SMDs) that each element points to the offset of the next element... so all the offsets will change if you increase, or decrease the size of one element in the middle.

HanDes.dll isnt used to decrypt packets vormav. :)

So what encrypt packets in client?

You guys cant tell me that this packet that was sent to server:

Code:

---

0000  64 00 00 00 B4 2D 01 80 1B 00 05 7F 7D D5 65 59    d....-......}.eY
0010  AF 59 17 66 96 D9 C5 E3 AA 20 EA 79 E9 55 2E 08    .Y.f..... .y.U..
0020  D5 BB 10 91 A4 7E 44 40 3A 78 AB 78 E7 A7 AA 26    .....~D@:x.x...&
0030  F5 98 25 3D BB A4 1F E1 74 2B 53 3A 86 62 00 94    ..%=....t+S:.b..
0040  8E 9E 8C D0 66 0C DA F3 FA D8 6C BC F0 65 D8 DB    ....f.....l..e..
0050  1C C5 92 8E 3C 07 6C 42 17 FC 7D CC 24 55 F4 5B    ....<.lB..}.$U.[
0060  E8 05 E6 87

---

is not encrypted... unless those are only X Y Z of you, NPC, other players location?

Client "am I clan?" question is not encrypted... I see plain text.

But when I sent 1118481 gold to other player I should see 111111 in hex and I don't.

I see this

Code:

---

0000  4C 00 00 00 50 00 47 48 01 00 00 00 01 00 00 00    L...P.GH........
0010  01 00 00 00 69 71 41 00 00 01 01 05 00 60 08 00    ....iqA......`..
0020  00 49 01 00 00 6C B7 FF 31 31 31 38 34 38 31 BF    .I...l..1118481.
0030  F8 00 00 00 01 00 00 00 84 90 0F 47 00 00 00 00    ...........G....
0040  03 00 00 00 00 00 00 00 4C 89 70 64                ........L.pd

---

What is rest? XY?

Packets obfuscation? UFO?

Some packets after you login are not encrypted. Mostly, I'd say.

The first packet you showed, yes, it is encrypted.

Quote:

---

Originally Posted by Vormav

So what encrypt packets in client?

---

Exact same routines as I posted in the protocol thread. GFantasy took those routines from KPT client.

It has changed as the developers changed C++ compiler, that is all.

Quote:

---

Originally Posted by Vormav

Client "am I clan?" question is not encrypted... I see plain text.

---

That is not sent to the game server, but the web server. :wink: Different port, different protocol, different program, as you know from your work with the Clan.dll and SQL.dll of GFantasy team.

Quote:

---

Originally Posted by Vormav

But when I sent 1118481 gold to other player I should see 111111 in hex and I don't.

I see this

Code:

---

0000  4C 00 00 00 50 00 47 48 01 00 00 00 01 00 00 00    L...P.GH........
0010  01 00 00 00 69 71 41 00 00 01 01 05 00 60 08 00    ....iqA......`..
0020  00 49 01 00 00 6C B7 FF 31 31 31 38 34 38 31 BF    .I...l..1118481.
0030  F8 00 00 00 01 00 00 00 84 90 0F 47 00 00 00 00    ...........G....
0040  03 00 00 00 00 00 00 00 4C 89 70 64                ........L.pd

---

What is rest? XY?

---

It's basically just XORed, except for the OpCode "not random bit blanking" thing we still don't really get. Client logically ANDs the OpCode with the current Real Time Clock counter on the machine... doesn't seem to transmit the RTC code... server "somehow" knows what the clients clock is, and puts the bits back... Don't get it.

Quote:

---

Originally Posted by Vormav

Packets obfuscation? UFO?

---

Yes... it's either marsh gas or a weather balloon. Definitely not an ETI. :wink:

XOR 43 with 50, then XOR that with 50, and you get 43. Do the same with plain text and it becomes unreadable, yet you only need 1 byte to "overlay" on to it, and it's all readable again. This is how MS-Word 5 password protected documents and Zip passwords worked back in the days of DOS. A dumb attack could usually crack them in a couple of hrs on a 486 SX 25Mhz CPU, and that was a variable length "string" XOR encryption not just a 1 byte / character XOR.

That's why I say "that's not encrypting it's obfuscating". (hiding in plain view "I'm not a safe, I'm a chest of draws. Honest.")

The alternate view? The ASCII (American "Standard" Code for Information Interchange) character codes where based on a U.S. military code used to send messages numerically via Morse code and paper and pen during WWII, and that was considered a sufficient Cypher to protect national secrets in a time of war. :scared: Now, it is a standard form of communication referred to as "plain text". :lol:

Reading Cuneiform was standard practice in times that we consider almost "pre-history", and today our best scientists have great difficulty deciphering it, even with the worlds greatest super-computers. :?:

What is "Encrypt" and "Decrypt"? Largely, understanding the language it was written in I guess.

Quote:

---

Originally Posted by bobsobol

[...]as you know from your work with the Clan.dll and SQL.dll

---

I know its just example.


Would not be better if you force client to use
int __stdcall DecryptFunc(char *,char *);

to decrypt packets that are sent to server? Or server will not understand that?


So packets are just XORed only before they go to server?

Well, HanDes can't encode or decode a message longer than 16 characters, and crashes if those characters are English or numerical... or anything I can actually type...

Do you really think this is a "better" encryption than the Protocol DLL?

Implementing Protocol.dll in both Client and server, and then rewriting it in C or C++ with a "real" encryption (SSL, PGP, RSA even ROT13) would be a great protection for your players. Yes.

That was why I posted it.

--- INSERT ---
I've amended this for clarity and in more depth in the OP.
---/INSERT ---

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. I'm trying to dispel myths about it.

1. it doesn't work
2. it isn't good
3. it is only used at login
4. it usually crashes (part of point b)
5. it's nothing to do with files or packets
6. it only works in one direction (one half client, one half server)
7. it's the client that starts it (so the vulnerable end is the one hackers can get at easiest... it's on their own PC)

IMHO there are only 2 useful things you could do with it.

1. remove it, and free up some space both in your client and server
   Note: the vulnerability here. If someone knows how to use it and can use a client which has it, and your server doesn't, they could crash your server by sending a HANDES login request. Be very careful how you remove it from your server.
   
   Also Note: that that tendency to crash handes.dll host process means this is a server vulnerability already!
2. 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.

i.e. You keep players mobile number in database, they log in on website, and it sends SMS to their phone. They type the SMS into the launcher, which gives it to game.exe and that decodes it with handes.dll and sends the special login packet to server, which encodes it back to unique login ID, looks up which account the web / SMS server assigned that ID to and sends server and character data back the client for that account.

This is how I believe it was meant to work. (I've seen other Asian games do something similar, as mobile phones are very popular, and so is account theft / password stealing and "key logging". Remember, they often play in arcades or cyber-café, using "public access" computers.)