MiGi's Notes: July 2006

Wednesday, July 19, 2006

Visual Basic Secrets

Copyright� 2002 by Kevin Wilson

• Introduction
• Using Pointers In Visual Basic
• VarPtr, StrPtr, and ObjPtr
• ByRef / ByVal
• AddressOf and Callbacks
• Accessing "Hidden" API's

Introduction:

Visual Basic is called a "Rapid Application Development (RAD) Development Tool" because it was designed to take care of the Windows "ground work" for you, thus allowing you to concentrate on the important stuff like the program's functionality and documentation.

For example, when you open VB and add a standard "Form" to your project, there's A LOT that goes into putting that form on the screen when you hit "F5" to execute the program and simply display the form. You have to call the "CreateWindow" to actually create the Form and give it it's properties that make up it's interface. You then have to modify it's text font, forecolor, backcolor, device context, etc. by calling various Win32 API's. Lastly, you have to hook into the Windows messages that are being sent to the newly created form by subclassing it and then catching and processing each Windows messages properly via a "WindowProc" callback function. More complex interfaces require more complex object creation and handling functionality to be programmed into the form. C and C++ programmers actually have to create all that object creation, message handling, and object destruction code by hand (or have a template of it generated).

Visual Basic's ability to do the "basics" for you like this is a powerful thing to programmers who know how to correctly use VB as a development tool, but also puts a lot of power into the hands of people that don't know much about programming. Visual Basic is mocked by C/C++ programmers because of this. They say, "Anyone can develop with VB, but it takes a real programmer to develop with C/C++." I say that the SMART programmer chooses Visual Basic because VB eliminates potential bugs in your object creation, message handling, and object destruction routines, VB offers easier and quicker handling of Windows events, VB gives you a more robust interface capabilities, VB gives you easier access to COM objects and third party controls, VB is easier to read because it is very close to reading English where C/C++ is VERY cryptic, VB allows you easy access to the Win32 API (which gives the programmer the ability to tap into the power of Windows), and on top of ALL THAT... Visual Basic has the ability to hook into the power and speed of C/C++ via components, libraries, and other code written in C/C++. Heh... where's the bragging rights now?

Here's the thing though... even VB programmers that have been in the industry for years don't realize the real power of VB because they don't grasp (or realize) a few key concepts and functionalities that VB offers. These concepts aren't taught, or at least are not emphasized the way they should, so I call them "VB SECRETS".

^ TOP ^

Using Pointers In Visual Basic:

I was once asked in a job interview a question that I now realize was a TRICK QUESTION. The question was, "Does Visual Basic have or use 'pointers' ?" The obvious answer to anyone that uses Visual Basic is "NO". You don't see pointer declarations and macros in VB like you do in C/C++... and that's what I think the interviewer was getting at. She accepted my answer with that reasoning. However, the correct answer should have been "YES".

Visual Basic (like just about every other programming language) does use pointers... EXTENSIVELY. The difference is, Visual Basic hides them from you whenever possible, or calls them something different so as to not burden you with the formalities and protocols required when using them.

I will proceed to explain how you can use pointers to access information held in variables directly (VarPtr / StrPtr / ObjPtr), pass information to functions by pointers (ByRef / ByVal), and retrieve and pass pointers to functions (AddressOf).

^ TOP ^

VarPtr, StrPtr, and ObjPtr:

The VB Functions "VarPtr" (Variable Pointer), "StrPtr" (String Pointer), and "ObjPtr" (Object Pointer) are UNDOCUMENTED, UNSUPPORTED functions that Microsoft has made available in Visual Basic 5.0, and 6.0. These functions (along with many others) are no longer available in VB.net. These functions allow you to get the address in memory where VB variables (pointers) are, as well as the address in memory where the actual data that the variables point to are. The reason these functions are so useful is because if you know the memory address of data, you can manipulate it, copy it, or pass it around directly instead of relying on VB to do it for you. This is MUCH faster and (in some cases) gives you the ability to do things that VB on it's own can't do.

This is what Microsoft's MSDN says about "VarPtr":

This function can be used to get the address of a variable or an array element. It takes the variable name or the array element as the parameter and returns the address. However, you should be aware that unlocked Dynamic Arrays may be reallocated by Visual Basic, so you must be very careful when you use VarPtr to get the address of an array element.

The following example gets the address of a variable:

Dim lngVariableAddress As Long
Dim dblMyVariable As Double
lngVariableAddress = VarPtr(dblMyVariable)

This example gets the address of the fourth element of an array:

Dim lngElementAddress As Long
Dim lngArrayOfLongs(9) As Long
' The following will get the address of the 4th element in the array
lngElementAddress = VarPtr(lngArrayOfLongs(3))

Limitations: The VarPtr function cannot be used to get the address of an array...

This is what Microsoft's MSDN says about "StrPtr":

Strings in Visual Basic are stored as BSTR's. If you use the VarPtr on a variable of type String, you will get the address of the BSTR, which is a pointer to a pointer of the string. To get the address of the string buffer itself, you need to use the StrPtr function. This function returns the address of the first character of the string. Take into account that Strings are stored as UNICODE in Visual Basic.

To get the address of the first character of a String, pass the String variable to the StrPtr function.

Example:

Dim lngCharAddress As Long
Dim strMyVariable As String
strMyVariable = "Some String"
lngCharAddress = StrPtr(strMyVariable)

You can use this function when you need to pass a pointer to a UNIOCODE string to an API call.

This is what Microsoft's MSDN says about "ObjPtr":

ObjPtr takes an object variable name as a parameter and obtains the address of the interface referenced by this object variable.

One scenario of using this function is when you need to do a collection of objects. By indexing the object using its address as the key, you can get faster access to the object than walking the collection and using the Is operator. In many cases, the address of an object is the only reliable thing to use as a key.

Example:

objCollection.Add MyObj1, CStr(ObjPtr(MyObj1))
...
objCollection.Remove CStr(ObjPtr(MyObj1))

Note that the "Limitations" at the end of the information about "VarPtr", it said that you can't use VarPtr to get the address of an array. That's true... to a point. You can't pass the variable "MyArray" to it (because VB stores arrays in an OLE object called a "SafeArray"), but if you get the address of the first element of the array "MyArray(0)", you have the address of the whole array because arrays elements are stored in memory contiguously (in numeric order from the first to the last). So if a Win32 API, or a C/C++ function asks for a pointer to a byte array, like this:

Option Explicit
Private Type POINTAPI
X As Long
Y As Long
End Type

'BOOL Polyline(
' HDC hDC, // handle of device context
' CONST POINT *lpPT, // address of array containing endpoints
' int cPoints // number of points in the array
');
Private Declare Function Polyline Lib "GDI32.DLL" (ByVal hDC As Long, _
ByRef lpPT As Any, ByVal cPoints As Long) As Long

You could call it like this:

Private Sub Form_Load()
Dim ThePoints() As POINTAPI
Me.AutoRedraw = True
Me.Visible = True
Me.Move 0, 0, Me.Width, Me.Height
ReDim ThePoints(1 To 5) As POINTAPI
ThePoints(1).X = 0: ThePoints(1).Y = 0
ThePoints(2).X = 100: ThePoints(2).Y = 0
ThePoints(3).X = 100: ThePoints(3).Y = 100
ThePoints(4).X = 0: ThePoints(4).Y = 100
ThePoints(5).X = 0: ThePoints(5).Y = 0
If Polyline(Me.hDC, ByVal VarPtr(ThePoints(1)), 5) = 0 Then Debug.Print "FAILED!"
Me.Refresh
Erase ThePoints
End Sub

NOTE: Be careful about storing pointers to dynamic arrays because when arrays are reallocated, resized, or redim'ed... it is very possible that you'll have a completely new memory address for the actual data.

For more information on VarPtr, StrPtr, and ObjPtr, see the following:

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q199824
http://msdn.microsoft.com/library/en-us/dnw32dev/html/ora_apiprog6_topic1.asp
http://msdn.microsoft.com/library/en-us/dnovba00/html/LightningStrings.asp
http://msdn.microsoft.com/library/en-us/dnovba01/html/Lightweight.asp

^ TOP ^

ByRef / ByVal:

By far the biggest problem VB programmers run into while working with Win32 API's (or any exported C/C++ function for that matter) is correctly passing the required parameters to the function. Inserting a "ByRef" where a "ByVal" should've been (or visa versa), or passing a value or variable when the function was expecting a pointer can be the one difference between the function being called working perfectly or causing Windows to crash and burn. Understanding how to pass parameters correctly takes an understanding of how Windows programs work with "calling stacks" and memory allocation between the calling program and the function being called.

First of all, lets discuss what a "call stack" is and how it relates to memory allocation when passing parameters to a function. The "call stack" is simply a spot in memory where the variables and values being passed to and from a function are stored. It's called a "stack" because parameter values follow one after the other in memory and are accessed with that assumption. Because of this, parameters are in a way "stacked on top of eachother" to make up all the information being given to the function. When a parameter is added to a function's call stack, it is said to be "pushed" onto the call stack. When a parameter is removed (or cleaned up) from a function's call stack, it is said to be "popped" off the call stack. The terms "stack", "push", and "pop" are assembler terms (yes, we are that low-level at this point) and if you were to decompile a program or DLL into assembly, you'd see lines with the words "push", "pop", etc.

When Visual Basic calls a Win32 API (or any exported C/C++ function), it expects the function to use the "Standard Calling Convention" ( __stdcall ) as apposed to the default C/C++ calling convention ( __cdecl ). This means that when the function is called, parameters are passed into memory (or pushed onto the stack) from right to left, and the function being called is responsible for cleaning up the memory passed to it (or popping the memory passed off of the stack). If you try to call an exported function that is declared with any other calling convention but __stdcall, Visual Basic will not know how to handle the stack and parameters being passed back and forth so you will get a message from VB saying "Bad DLL Calling Convention".

For a more in-depth and advanced explanation of how memory is allocated and deallocated when calling parameters, and what call stacks are and how they work in Windows, I strongly recommend reading an EXCELLENT book by Dan Appleman (Desaware) called "Dan Appleman's Win32 API Puzzle Book and Tutorial for Visual Basic Programmers".

Now lets back up a little and get out of the inner workings of Windows memory and get back to working with VB. When you call a function, you can pass parameters to it in one of two ways. You can pass it an explicit value that you want the function to take and work with, or you can pass it a pointer to information already present in memory. When you're passing simple information like numbers, sizes, flags, etc. you want to pass the information in ByVal (meaning By Value) because you want it to take the value of what you are passing, not the memory address of where that value is currently being held. Now when you want to pass more complex data to a function like a data type, an array of values, or an object reference, you need to pass a reference (or pointer) to the function telling it where in memory the data is. This is done by specifying the ByRef (meaning By Reference) keyword. The function will then go to that point in memory and read the data that applies. The exception to this is when you pass strings to Win32 API calls (or any C/C++ exported function). Always pass strings ByVal to API's (unless you're passing a string array... in which case you'd use ByRef, or just pass the first element of the array ByVal).

So at this point you're saying, "I already know about passing parameters ByRef/ByVal". Yes, but did you realize that what you're doing when you pass "ByRef" is passing a pointer? If you take that concept a step further, you can do things like make function interfaces more generic (thus opening them up for more broad application) by altering the "ByRef" to "ByVal" and passing an explicit pointer to the data you want to pass. So instead of declaring your function like this:

Option Explicit

Private Type RECT
Left As Long
Top As Long
Right As Long
Bottom As Long
End Type

'int FillRect(
' HDC hDC, // handle to device context
' CONST RECT *lpRC, // pointer to structure with rectangle
' HBRUSH hBR // handle to brush
');
Private Declare Function FillRect Lib "USER32.DLL" (ByVal hDC As Long, _
ByVal lpRC As Long, ByVal hBR As Long) As Long
Private Declare Function CreateSolidBrush Lib "GDI32.DLL" (ByVal crColor As Long) As Long
Private Declare Function DeleteObject Lib "GDI32.DLL" (ByVal hObject As Long) As Long

Private Sub Form_Load()
Dim hBrush As Long
Dim MyRect As RECT

Me.AutoRedraw = True
Me.Visible = True
Me.Move 0, 0, Me.Width, Me.Height
With MyRect
.Top = 0: .Left = 0: .Right = 100: .Bottom = 100
End With

hBrush = CreateSolidBrush(vbRed)
If hBrush = 0 Then Exit Sub
If FillRect(Me.hDC, VarPtr(MyRect), hBrush) = 0 Then Debug.Print "FAILED!"
Me.Refresh
DeleteObject hBrush
End Sub

If you think about it, this gives you all kinds of options when declaring functions and parameters. You're not restricted anymore to the exact variable type. You could make EVERYTHING "Long" variable types and pass pointers around to everything (as long as you were careful about how you did it). So you're having trouble passing that monster custom type around, FORGET ABOUT IT... pass it with a pointer. So you're having problems passing that object around, FORGET ABOUT IT... pass it with a pointer. VB 5.0 won't let you return variable arrays (or funky types and objects) as the return type for a function, FORGET ABOUT IT... pass back a long value representing where the array is in memory and use the CopyMemory API to copy it down into a local array. See where I'm going with this?

If you just said, "NO"... using VarPtr, StrPtr, and ObjPtr in conjunction with ByRef and Byval allows you to pass around data in ANY format if you know what you're doing.

^ TOP ^

AddressOf and Callbacks:

The "AddressOf" operator is all about callbacks. "But what is a call back?" you ask. A callback is the Windows equivalent of a VB "Event". In fact, VB events (on a very low level) are just about always triggered by callback functions that catch the original event in the form of a Windows Message. Callbacks are most often seen within the Win32 API (and other C/C++ code) where notification of user and/or Windows activity is required or desired within your application. You don't see callbacks within VB much because VB handles messaging and notification via "Events", which are much easier and safer to deal with compared to callbacks and all that goes into them.

Lets say that you wanted to receive notification of EVERY message that Windows is sending to a Form within your project (even ones that you'd never use), along with a few custom messages that may be sent to your Form via some other API call(s). What you would do is setup a callback function that is recognized by Windows ("WindowProc") and then tell Windows (via the "SetWindowLong" API) to send all of it's messages meant for your Form to your callback function instead, so you can inspect them and/or react to them... and then send them on their way (via the "CallWindowProc" API). Doing this is called "Sub-Classing" and is a very powerful (but at the same time very dangerous) technique that you can use to redraw your Form, it's menus, and/or it's contents in a custom manner (or whatever you want to do with your Form).

There two draw-backs to using "AddressOf":

1) You can only retrieve the address to a function or sub (public or private) contained within a Standard VB Module. There's no way around this.

2) It can only be called as part of a parameter list to a function or sub. The way to get around it is like this:

Option Explicit

Public Sub Main()
Dim lngProcAddress As Long
lngProcAddress = GetProcAddress(AddressOf WindowProc)
End Sub

Public Function GetProcAddress(ByVal lngAddressOf As Long) As Long
GetProcAddress = lngAddressOf
End Function

Public Function WindowProc(ByVal hWnd As Long, ByVal uMsg As Long, _
ByVal wParam As Long, ByVal lParam As Long) As Long
' <>
End Function

You'll notice that we pass the "AddressOf" with the name of the function we want to get the address (memory pointer) of to the function "GetProcAddress" which simply returns back that value. Simple concept and is very effective. The addresses of functions and subs doesn't change so you could store the address of the functions and subs you want to reference this way so you don't have to repeatedly call AddressOf, etc.

"So lets see it in action!" you say... OK!

Here's an example of "sub-classing" as mentioned above:

Option Explicit

Private Const GWL_WNDPROC = (-4)
Private lngPrevProc As Long
Private lngHWND As Long

Private Declare Function SetWindowLong Lib "USER32.DLL" Alias "SetWindowLongA" _
(ByVal hWnd As Long, ByVal nIndex As Long, ByVal dwNewLong As Long) As Long
Private Declare Function CallWindowProc Lib "USER32.DLL" Alias "CallWindowProcA" _
(ByVal lpPrevWndFunc As Long, ByVal hWnd As Long, ByVal uMsg As Long, _
ByVal wParam As Long, ByVal lParam As Long) As Long

' This is the CALLBACK function that receives the messages for the specified hWnd
Private Function WindowProc(ByVal hWnd As Long, _
ByVal uMsg As Long, _
ByVal wParam As Long, _
ByVal lParam As Long) As Long
' Display the messages and their information in the IMEDIATE window
' NOTE: You can find out what messages are being passed by comparing the value of
' "uMsg" to Windows Messages (WM_*) constant values defined in the WINUSER.H file
Debug.Print _
"hWnd=" & hWnd & ", uMsg=" & uMsg & ", wParam=" & wParam & ", lParam=" & lParam

' Forward on the messages to where they were originally supposed to go. This MUST
' here or the window will become unresponsive because it will stop recieving messages
WindowProc = CallWindowProc(lngPrevProc, hWnd, uMsg, wParam, lParam)
End Function

' This function starts a new sub-classing
Public Function Subclass_Start(ByVal hWnd As Long) As Boolean
' Stop any previous sub-class
If Subclass_Stop = False Then Exit Function
' Attempt to start a new sub-class
lngPrevProc = SetWindowLong(hWnd, GWL_WNDPROC, AddressOf WindowProc)
If lngPrevProc <> 0 Then
lngHWND = hWnd
Subclass_Start = True
End If
End Function

' This function stops any existing sub-classing
Public Function Subclass_Stop() As Boolean
' If no previous sub-class was started, just exit
If lngPrevProc = 0 Or lngHWND = 0 Then
Subclass_Stop = True
Else
' Set the message handling procedure back to what it originally was
If SetWindowLong(lngHWND, GWL_WNDPROC, lngPrevProc) <> 0 Then
Subclass_Stop = True
End If
End If
' Clear the variables used
lngPrevProc = 0
lngHWND = 0
End Function

Option Explicit

Private Sub Form_Load()
Subclass_Start Me.hWnd
End Sub

Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
Subclass_Stop
End Sub

Here's an example of "enumeration", which is a VERY popular way for Windows to give you back information about "information lists" (like a list of all windows, a list of all the objects on a window, a list of all the installed fonts, etc):

Option Explicit

Private lngWinHandle() As Long
Private lngWinHandleCount As Long

Private Declare Function EnumWindows Lib "USER32.DLL" (ByVal lpEnumFunc As Long, _
ByVal lParam As Long) As Long

' This is the CALLBACK that enumerates through all windows in the current desktop
Private Function EnumWindowsProc(ByVal hWnd As Long, ByVal lParam As Long) As Long
' Incrament the array of window handles
lngWinHandleCount = lngWinHandleCount + 1
ReDim Preserve lngWinHandle(1 To lngWinHandleCount) As Long
' Add the information to the array
lngWinHandle(lngWinHandleCount) = hWnd
' Tell the function to keep going
EnumWindowsProc = 1
End Function

Public Function GetAllWindows(ByRef Return_Handles() As Long, _
Optional ByRef Return_WinCount As Long) As Boolean
' Clear any previous information
Erase lngWinHandle
lngWinHandleCount = 0
' Start enumerating through the windows
If EnumWindows(AddressOf EnumWindowsProc, 0) <> 0 Then
Return_Handles = lngWinHandle
Return_WinCount = lngWinHandleCount
GetAllWindows = True
End If
Erase lngWinHandle
lngWinHandleCount = 0
End Function

Option Explicit
Private Sub Form_Load()
Dim lngWindows() As Long
Dim lngWindowsCount As Long
Dim lngCounter As Long
Dim strWindows As String
If GetAllWindows(lngWindows, lngWindowsCount) = True Then
If lngWindowsCount > 0 Then
For lngCounter = 1 To lngWindowsCount
strWindows = strWindows & " " & lngWindows(lngCounter) & Chr(13)
Next
End If
Me.AutoRedraw = True
Me.Print strWindows
End If
Erase lngWindows
End Sub

^ TOP ^

Accessing "Hidden" API's:

This part is definately the most "secret" of all the secrets decribed on this page. There are indeed MANY hidden Win32 API calls in Windows... the trick is to find them and find out how to call them because Microsoft sure won't tell you.

"But why hide them?" you ask? Because Microsoft adds extra functionality to the API that only they can gain access to. This gives their products an advantage when (running under Windows) over everyone else's because only they have access to more powerfull functionality, faster functionality, or extra functionality via these hidden API calls when everyone else has to make do with the regular, documented functionality exposed by Windows and the documented in the MSDN. "Unfair advantage" you say? DEFINATELY! But who ever said that Microsoft does business fairly... or ethically for that matter! These kinds of business practices are what are constantly keeping Microsoft in court and on newspaper headlines.

"What kind of hidden API's are out there, and how do I find out what they are and how to use them?" you ask? EXCELLENT question, and that's why I've included this here. There are many web pages out on the internet dedicated to finding these hidden API's and exposing their functionality to "level the playing field" and give the more cool functionality to developers like you and me! Here's a few good web pages on this:

http://www.geocities.com/SiliconValley/4942/index.html
http://www.users.qwest.net/~eballen1/nt.sekrits.html
http://www.mvps.org/vbnet/code/shell/undocshelldlgs.htm
http://www.mvps.org/vbnet/code/shell/undocformatdlg.htm
http://www.mvps.org/vbnet/code/shell/undocchangeicondlg.htm
http://www.mvps.org/vbnet/code/shell/undocshpaths.htm
http://www.ercb.com/ddj/1992/ddj.9211.html

You can find a few of these "hidden API's" in the modCOMDLG32.bas module under the "VB Standard Modules". They look like this:

Public Declare Function DLG_FindFile Lib "shell32.dll" Alias "#90" _
(ByVal pidlRoot As Long, ByVal pidlSavedSearch As Long) As Long
Public Declare Function DLG_FindComputer Lib "shell32.dll" Alias "#91" _
(ByVal pidlRoot As Long, ByVal pidlSavedSearch As Long) As Long

You'll notice that they are aliased by a number "#90", "#91", etc. These are called "Ordinal Numbers" and they are a way for you to expose API's through a DLL without exposing it's name. So if you wrote a function, and you wanted to use it but didn't want anyone else to, you could expose it by a number. This doesn't give anything away as to what it does or why it's there, but at the same time gives you access to it.

Sneaky, huh?!

WELL! That's all folks. If I think of any other "secrets" or neat "hidden" or "obscure" functionality within VB (or remember any that I meant to put here), I'll add them. Happy coding! =)

Tuesday, July 18, 2006

World of Game Hacking - Breaking the packet encrypting in Tibia 7.72

Breaking the packet encrypting in Tibia 7.72

Written by Arne Banan

Friday, 16 June 2006

Discuss this article on the forums. (5 posts)

This tutorial will show you how to use Tibia's own encryption routines from an injected
DLL, this will require som reversing and assembly coding, if you have not done any of
that before this tutorial probably isn't for you but I'll try to explain things as best I
can.This tutorial will not cover the packet format, mainly because I don't know it.
Neither will I include what encryption routine it uses or how to code it, if you want to
make an .EXE you can just rip the encryption routine and include it as inline asm in
your program...
This is the first tutorial I have EVER written, so bare with me .

Tools used: WPE Pro 0.9a, OllyDbg 1.10 and MASM 8.2

First, let's see how these packets looks like, so hook up Tibia with WPE and start
capturing. I wrote some random letters in the chat and this is what I got:

wpe

The first two bytes are, quite clearly, the size of the data. But there are no letters in
the rest which means that it's probably encrypted, which further means that we got
some reversing to do.

Now, what would be the easiest way to find the encryption routine? Let's take a look
at the send()'s prototype from MSDN:

int send(
SOCKET s,
const char* buf,
int len,
int flags
);

Tibia will surely write to that buffer during or shortly after the encryption routine, let's
put a breakpoint on it.

Start Olly, open tibia.exe from Olly and log in, the first packet sent by Tibia is
unencrypted and probably exchanges the key so we should not break here. When
you're logged in open up the command plugin (it can be found at www.ollydbg.de)
and write "bp send" which puts a breakpoint on the first instruction of send() in
ws2_32.dll. Write something in the chat and watch Olly break. Watch the stack and
you'll see Olly's neatly formatted arguments:

0012E5BC 0052F255 /CALL to send from Tibia.0052F24F
0012E5C0 0000010C |Socket = 10C
0012E5C4 00719540 |Data = Tibia.00719540
0012E5C8 00000012 |DataSize = 12 (18.)
0012E5CC 00000000 \Flags = 0

So, the send data is at 00719540? Then let's check it, this is what I got:

00719540 10 00 EA D6 02 D5 6B 58 29 44 88 E5 25 48 ED DE .êÖ ÕkX)Dˆå%HíÞ
00719550 23 26 #&

Yours is probably different. These are the first 18 bytes, since that was all it's going to
send (DataSize = 12 (18.). We can see the unencrypted first two bytes and then the
rest of the packet. Strange though, I wrote something shorter when I captured the
packet with WPE but the size is still 10 in hex. It still makes sense that the first two
bytes is the size because all the bytes after the first two are 16 (10 in hex). So what
does this mean? It could be that it is some kind of padding to make all the packets a
certain length or that the encryption routine needs a certain length, it's something we
have to find out. But now, let's put a breakpoint on memory access. Write something
more in the chat and it breaks!

Hmm... There's nothing at 00719540 yet and if you scroll up we can't see any
mathematical computations or anything of the like, which often shows that it's a
encryption routine, but it might be in one of those calls up there. Let's go back and
check there later if we don't find anything by running again.

00508CD0 /$ 8B4424 04 MOV EAX,DWORD PTR SS:[ESP+4] ; MOVs the first argument into EAX. The first argument happens to be 00719542, that's right after the packet size!
00508CD4 |. 8B08 MOV ECX,DWORD PTR DS:[EAX] ; MOVs four bytes from EAX (00719542) into ECX.
00508CD6 |. 8B50 04 MOV EDX,DWORD PTR DS:[EAX+4] ; MOVs four bytes from EAX+4 (00719546) into EDX.
00508CD9 |. 53 PUSH EBX
00508CDA |. 55 PUSH EBP
00508CDB |. 56 PUSH ESI ; Save som registers on the stack.
00508CDC |. 8B7424 14 MOV ESI,DWORD PTR SS:[ESP+14] ; MOVs the second argument into ESI.
00508CE0 |. 57 PUSH EDI ; Save EDI too...
00508CE1 |. 33C0 XOR EAX,EAX ; Nulls EAX
00508CE3 |. BF 08000000 MOV EDI,8
00508CE8 |> 8BDA /MOV EBX,EDX ; Start of a big loop full of XORs, ADDs, SUBs, SHRs and SHLs, probably the encryption.
; After the loop.
00508DEF |. 8B4424 14 MOV EAX,DWORD PTR SS:[ESP+14] ; MOVs the first argument into EAX, again.
00508DF3 |. 5F POP EDI
00508DF4 |. 5E POP ESI
00508DF5 |. 5D POP EBP ; POPs the registers off the stack.
00508DF6 |. 8908 MOV DWORD PTR DS:[EAX],ECX ; MOVs ECX to the first four bytes in EAX (00719542).
00508DF8 |. 8950 04 MOV DWORD PTR DS:[EAX+4],EDX ; MOVs EDX to the fours bytes at EAX+4 (00719546)
00508DFB |. 5B POP EBX ; POP EBX too...
00508DFC \. C3 RETN ; Return to the calling function.

void 00508CD0(char*,char*);

Well, my friend, I think we just stumbled upon the encryption routine! This function
takes the eight bytes from the first argument and does some long computations, some
using the second argument, on them an then puts them back. You can see that the
first eight bytes are now completely different than from before, it seems that the
encryption routine only encrypts eight bytes at a time which explains the packet
lengths. This is not a normal calling convention and the arguments are only MOVed
from the stack, not removed from it so the calling function must remove the
arguments from the stack after the call. If we want to use this function we need to
have a buffer with the data to be encrypted and the second argument which seems
to be some sort of key. Let's see in more detail what the second argument is by
following the RETN back to the calling function.

00508F60 /$ 8B4424 04 MOV EAX,DWORD PTR SS:[ESP+4] ; MOVs the first argument into EAX.
00508F64 |. 85C0 TEST EAX,EAX ; Checks if the argument is null.
00508F66 |. 74 0D JE SHORT Tibia.00508F75 ; If it is, return.
00508F68 |. 83C1 04 ADD ECX,4 ; Else add ECX with 4.
00508F6B |. 51 PUSH ECX ; PUSHes the second argument, the key, to the encryption function.
00508F6C |. 50 PUSH EAX ; PUSHes the first argument to the encryption function.
00508F6D |. E8 5EFDFFFF CALL Tibia.00508CD0 ; CALLs the encryption function.
00508F72 |. 83C4 08 ADD ESP,8 ; Removes the arguments from the stack by adding 8 to ESP.
00508F75 \> C2 0400 RETN 4 ; Returns to the calling function.

This didn't make the whereas of the key any clearer. But it shows that we have to
manually remove the arguments from the stack after calling the encryption function.
The first argument here is the buffer to be encrypted and ECX should contain the
address of the key - 4. You can use this function instead of the on at 00508CD4 if you
want to. Let's go to the calling function and check how ECX get it's value:

004CBEB0 > 8D4F 02 LEA ECX,DWORD PTR DS:[EDI+2]
004CBEB3 . 3BF1 CMP ESI,ECX
004CBEB5 . 0F8D B0000000 JGE Tibia.004CBF6B
004CBEBB . 8D96 40957100 LEA EDX,DWORD PTR DS:[ESI+719540] ; The address to the bytes to be encrypted are stored in EDX.
004CBEC1 . 52 PUSH EDX ; PUSHes the first argument.
004CBEC2 . B9 749D7100 MOV ECX,Tibia.00719D74 ; 00719D74 + 4 is the address to the key.
004CBEC7 . E8 94D00300 CALL Tibia.00508F60 ; CALLs the function before the encryption routine.
004CBECC . 83C6 08 ADD ESI,8 ; ADDs 8 to ESI to encrypt the next 8 bytes, or end the loop.
004CBECF .^EB DF JMP SHORT Tibia.004CBEB0 ; Continue looping.

We land in the middle of a long function, in a short loop. The first three instructions are
used to see if the necessary bytes are encrypted and it's time to end the loop. The
address to the key is hardcoded at 00719D74 and is increased by 4 in the function it
calls which makes the address to the key 00719D78.

Now we have all the information needed to encrypt a packet, the decryption routine
can be found the same way but by putting a brakpoint at recv and then a memory
breakpoint on that buffer. The decryption function is located at 00508E00 and uses
the same arguments as the encryption function at 00508CD0, the first argument
should be a pointer to the buffer and the second a pointer to the key. The functions
en/decrypts 8 bytes every function call so we need to add 8 to the pointer and call it
again until the whole buffer is encrypted. They don't remove the arguments from the
stack which means we have to ADD 8 to ESP after every a CALL or else we'll mess the
stack up.
We also want to try if our functions work by sending a packet to the server, but we
need to find the address to the socket for that. The address is DMA though, so put a
breakpoint on the send function using bp send again and make it brake. Press Alt + F9
to get back to tibia.exe and step through the RETN.

0052F240 . FF7424 0C PUSH DWORD PTR SS:[ESP+C] ; /Flags
0052F244 . FF7424 0C PUSH DWORD PTR SS:[ESP+C] ; |DataSize
0052F248 . FF7424 0C PUSH DWORD PTR SS:[ESP+C] ; |Data
0052F24C . FF71 04 PUSH DWORD PTR DS:[ECX+4] ; |Socket
0052F24F . FF15 0CB65500 CALL DWORD PTR DS:[<&WS2_32.#19>] ; \send
0052F255 C2 0C00 RETN 0C

And you get here:

004CBFBA . 8B0D 509D7100 MOV ECX,DWORD PTR DS:[719D50] ; MOVs the first four bytes from [00719D50] into ECX.
004CBFC0 . 8B11 MOV EDX,DWORD PTR DS:[ECX] ; MOVs the first four bytes from [ECX] to EDX.
004CBFC2 . 6A 00 PUSH 0 ; PUSHes the last argument to [EDX+18], which is also the last argument used in the call to send.
004CBFC4 . 83C6 02 ADD ESI,2 ; ESI is the size of the packet to send minus the first two bytes which are added here.
004CBFC7 . 56 PUSH ESI ; PUSHes the third argument to [EDX+18] and also to send.
004CBFC8 . 68 42957100 PUSH Tibia.00719542 ; PUSHes the data to be sent.
004CBFCD . FF52 18 CALL DWORD PTR DS:[EDX+18] ; CALLs the function before send, which resolves the socket from [ECX+4]

We should mimic this code when we want to send our packets, or just take the socket
from [ECX+4].

Now we can start coding our DLL, it will be really short, simple and just send a packet
making you say: "It works...". Here it is:

.486
.model flat, stdcall
option casemap :none

include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
include \masm32\macros\macros.asm

includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib ; The usually includes and options...

.data
packetsize db 18h,00h ; The packet header with the size.
packet db 0Fh,00h,96h,01h,0Bh,00h,49h,74h,20h,77h,6Fh,72h,6Bh,73h,2Eh,2Eh,2Eh ; The main packet, you can easily find those by breaking at the encryption routine.
padding db 00,00,00,00,00,00,00 ; Padding to make our packet 24 bytes and thus encryptable if we didn't do this we would overwrite our code, I think...

.code
DllEntry proc hInst:DWORD, reason:DWORD, unused:DWORD ; The usually arguments passed to DllEntry...
.if reason == DLL_PROCESS_ATTACH ; Check if we're just getting attached using the .if macro.
push 00719D78h ; PUSH the address to the key.
push offset packet ; PUSH the first 8 bytes to be encrypted.
mov edi, 00508CD0h ; Load the functions address into EDI.
call edi ; CALL the encryption function.
add DWORD PTR[esp], 8 ; ADDs 8 bytes to the first argument to the encryption function.
call edi ; And CALL it again using the same arguments.
add DWORD PTR[esp], 8 ; ADDs 8 bytes to the first argument again.
call edi ; And CALLs it.
add esp, 8 ; Clear the stack of the arguments.
push 0 ; The last arguments to the send function.
push 1Ah ; The total size to send.
push offset packetsize ; The address to the buffer to send.
mov eax, DWORD PTR[00719D50h]
mov ecx, DWORD PTR[eax]
mov eax, DWORD PTR[ecx] ; Finds the address to the socket and the function to call.
call DWORD PTR[eax+18h] ; CALL the function used to send the packet.
.endif
ret ; Return.
DllEntry endp
end DllEntry

I think the comments are quite self explainable. Use a DLL injector to inject it, there is
one in the tools section by Max_Power. A simple DLL injection tool isn't very hard to
code though, I think you can get quite alot of info on it using Google.

Thanks goes too:
g3nuin3 & hunter for their great tutorial on breaking the packet enryption in Water
Margin, that's what got me going on breaking the Tibia packet enryption.
And all the members of WOGH!

That wasn't a lot of thanking...

>

Wednesday, July 12, 2006

test

Why no posts on the site?

BCB - VC compatibility : 探訪動態連結函式庫

探訪動態連結函式庫

探訪動態連結函式庫 (Dynamic Linking Libraries,DLLs)

蕭永哲 martins1@ms3.hinet.net

打Windows 從娘胎出生後，動態連結函式庫(Dynamic Linking Libraries,DLLs) 宛如這個新生兒的血液一般的重要，DLLs 一直扮演著Windows 的基石這個角色。到了Win32 雄霸一方的世紀，DLLs 的威風更是不減當年，幾乎所有的Win32 API 都以隱身在DLLs 中的形式存在，Windows 血液裡流的盡乎都是DLLs 。在Windows 下DLL 通常是以『副檔名為DLL 的檔案』存在，DLL 內可以包含提供外部呼叫的函式、資源（Resource ）以及各種的變數，當DLLs 被應用程式載入時這些DLLs 內含的資料都會變為應用程式所屬行程的一部份。我們可以把DLL 當成一個函式庫（Library ），但因為還要能夠被動態載入，這個函式庫自然比傳統的函式庫複雜些。

DLL 一二說

DLLs 的出現提供了程式設計師一個將程式模組化的方法，別於C++ 類別的建構時期模組化，DLL 乃是執行時期模組化，因此程式設計師可以在建構程式時將所需要用到的函式分門別類的製造成DLLs 的形式。但為什麼我們要使用DLLs 呢？DLLs 充其量不就你把程式碼、資源等獨立到另一個檔案裡頭去，到底有什麼好處值得我們大費周章地把部份程式寫成DLLs 的形式呢？使用DLL 的好處大致可以如下歸類：

1 、有效率的重複使用程式碼

當程式設計師所撰寫的程式碼一多起來，必然地會發現有很多程式碼是在做相同的事情，通常當程式設計師遇到這些重複的程式碼，最平常不過的方法就是把這些重複的程式碼大則獨立成『函式』（Function ）小則獨立成『巨集』（Marco ）。但是，當這些函式不單單只在單一應用程式內會用到，而是在撰寫許多應用程式時都得用到時，這些常用的函式通常就會被製作成函式庫來使用，例如C 語言的Runtime Library （RTL ）；但編譯器在編譯應用程式遇到函式庫時，會把這些隱身在函式庫裡頭的函式實體內容如同我們在程式裡頭撰寫這些函式的原始碼般地加進應用程式的執行檔中，也就是說當你所用的函式庫越多時，你的執行檔也就相對的會越來越龐大，這個做法也就是我們所謂的靜態連結（Static Linking ）。因此為了避免應用程式的過分龐大，有人提出了動態連結（Dynamic Linking ）的做法，所謂動態連結就是提供了一個做法讓我們不需要把應用程式的執行檔變得如此龐大，但一樣可以享用這些使用頻率高的函式。也就是說這些函式會在程式執行時才被載入，而不是直接編譯在執行檔中。這樣一來可以讓我們更有效率使用這些函式。但相對的，當你所撰寫的程式得交給他人使用時，你除了得把你所編譯好的EXE 檔交給他之外，還得一併把編譯好的DLLs 檔交給他，否則執行起來一定會產生不可預期的錯誤。

2 、區分程式碼

依據先前的第一點，若有朝一日發現這些被包裝在DLLs 之中的函式的實作方法有點錯誤或是發現有更好的做法時，需要更動僅只有部份的DLLs 原始碼，重新將修改過的DLLs 給編譯後就可以達成更新程式的目的，至於應用程式端連動都不需要動一下；當然了，前提是這些個修改過的函式名稱與傳入的參數型別宣告都不能夠更動。根據這些個特性，咱們可以把整個應用程式中的函式依照功能或目的分類，並將這些分類好的函式組合成許多個DLLs 模組，將執行檔給分割城數個小檔案，讓這些DLLs 模組分工合作來完成應用程式所要達到的目的。這樣一來，對於應用程式的維護以及更新就不需要大費周章地從頭再編譯一次了，僅需把要有修改到的DLLs 從新編譯就可以達成程式的更新。

3 、節省記憶體的使用量

先前提到：DLLs 的載入是在應用程式執行時才被載入，甚至還可以是可以在應用程式所需用到函式時才被載入。此外DLLs 還有一個很重要的特性：若不同的應用程式但需要相同的DLL 中的函式時，DLL 僅在第一個使用到DLL 的應用程式執行時載入，只要這個應用程式尚未結束而其他的應用程式又正好需要使用到同一DLL 中的函式時，DLL 不需要再重新被載入到記憶體中就可以供第一個應用程式以外需要用到DLL 的應用程式使用，一直到沒有任何應用程式使用這個DLL 時，DLL 才會跟著最後一個使用DLL 的應用程式一起從記憶體裡頭消失，因此使用DLLs 來包裝常用的函式是個不錯能夠節省記憶體與系統資源的做法。

4 、將程式推向國際舞台

DLL 在設計時，就已經被設計不只是能夠放入函式而已，還能夠被放入許多的資源（Resource ），如：可以放入選單資料、字串資料、圖形資料等等 … 。也因此DLL 很常被拿來作為應用程式邁向國際舞台的一個墊腳石。你可以在應用程式被執行時檢查執行應用程式的作業系統語言版本，之後把當地語言版本的Resource DLL 給載入，讓所有的文字及畫面都達到當地語言化的目的。而這個功能在C++Builder 3 當中經由Borland C++Builder 部門工程師的努力，已經幫我們把這些煩人的步驟給簡化了許多，我們僅須按下選單上的New 並選擇Resource DLL Wizard ，並將將需要更改的文字給更改成不同的語言，並不須在執行時檢查執行平台的語言為何。其餘煩瑣的工作都已經被Borland 工程師給完成了。我們最後只需要重新編譯這個Resource DLL 並附在應用程式中就可以完成一個國際化的應用程式了。

既然DLLs 在Windows 上頭是那麼的重要且使用DLLs 還有那麼多的好處，當然值得咱們來好好的了解一下。先來討論DLLs 的基本架構。

Import 還是Export ？

我們已經知道當DLL 被應用程式載入時，DLL 內所含有的資料都會成為應用程式所屬行程中的一部份，這到底怎麼辦到的？其實在DLL 被應用程式載入時，DLL 會被先設定一個基底位址（Base Address ），若這個基底位址並沒有和應用程式中的其他資源互相衝突，則這個DLL 檔會被映射到載入端行程內的相同位址上讓載入端應用。那DLL 中到底有多少資訊可以被載入呢？先看看圖一：

圖一是使用C++Builder 內附上的tdump.exe 工具列出一個DLL 檔內所有的Section ，tdump 是個非常好用的工具，之後使用次會不少，先說明用法，用法很簡單：

tdump inputfile outputfile

這樣就可以把inputfile 裡頭的資料給格式化輸出到outputfile 裡頭，當然了，你的inputfile 得是tdump 認得的檔案：DOS 下的執行檔、PE 格式執行檔（註1 ）、.OBJ 檔、.LIB 檔，其餘的檔案若為文字格式就直接輸出，而Binary 格式的檔案就以HEX Dump 格式輸出。此外，在Microsoft Visual C++ 裡頭的dumpbin.exe 也提供相同功能來分析這些檔案。

圖一中的這些Section 表示著：

Section	包含	意義
.text	應用程式或DLL 的程式碼	這個section 包含了一般性的程式碼，就是先前提到的除了自己所撰寫的程式碼外還有Runtime Library 的程式碼。
.data	具有初始值的資料	這個section 存放了在編譯時期就已經具有初始值的資料；包括了全域變數（global variable ）、靜態變數（static variable ）以及 ”Hello World ” 這一類字串等等 … 。
.tls	執行緒內部儲存空間	thread local storage
.idata	輸入名稱表	這個section 包含了有『從其他DLLs 中輸入過來的函式與資料』的相關資訊。
.edata	輸出名稱表	這個section 恰好與.idate 相反，是存放了由此EXE 或DLL 輸出給外頭使用的函式與資料的相關資訊。
.rsrc	資源	若你使用過Microsoft Visual C++ 或是Borland Resoure Workshop 來觀察過EXE 或DLL ，你所看到的那些resource date 就是儲存在這個section 裡。也就是編譯器將應用程式所需要用到的resource date 都整理好一起放到這個section 裡頭。
.reloc	修正表資訊	這個section 裡頭含有一個base relocationsg 是一個調整值，先前說過當 …. 會，但若無法載入到預設的位址，就會依據這個調整值來作調整。

除了了解這些section 之外，你還必須知道的另一個觀念是所謂的相對虛擬位址（Relative Virtual Address ，RVA) 。PE 格式執行檔中有許多資料的位址都是以RVA 表示。簡單的來說RVA 是某一項資料從檔案被映射進來的起點算起的偏移值（offset ）。舉個例子，我們說Windows 載入器把一個PE 格式執行檔檔映射到虛擬位址空間0x400000 處，如果在此執行檔中有一個函式的函式指標起始於0x40C000 ，那麼這個函式指標的RVA 就是0x C000 ：

虛擬位址（0x40C000 ） ─ 基底位址（0x400000 ） = RVA （0xC000 ）

只要把相對虛擬位址加上基底位址，相對虛擬位址就可以被轉換為一個有用的指標。『基底位址』(Base Address) 也是另一個重要名詞，通常基底位址是用來描述被映射到記憶體中的EXE 或DLL 的起始位址。

另外圖一中『Key to section flags 』是這些section 的屬性旗標種類，如：唯讀、共享或可寫入等等 … 每個section 的屬相可以從『Object table 』最後一欄的『Flag 』中看出。

了解這些基本知識後，再回頭詳細看一看在圖一中的輸出輸入section ，我們已經知道，製作DLL 的主要目的是製造一個模組化的函式或資料供其他的程式應用，而這種提供給其他EXE 和DLL 使用的方式就稱為輸出（export ），反之若取用其他的EXE 或DLL 中的函式，就稱為輸入。在DLL 中，你可以輸出任何想要輸出的資料，如函式、類別（class ）或是資源等等 … ，我們把重點放在輸出輸入函式的部份，我們先來觀察一般的輸出函式：

一樣可以使用先前提到的tdump 來觀察DLL 中的輸出表格，由圖二中可以看到輸出函式表格包含了Ordinal 、RVA 以及Name 三個欄位表示。Name 就是輸出的函式名稱而RVA ─ 相對虛擬位址在前頭已經介紹過了，至於Ordinal 則是輸出表格中輸出函式的序號。這些輸出函式透過這個表格上的函式名稱與函式序號讓外界認得。當載入端最初在載入DLL 時並不知道DLL 內的輸出函式的正確位址只知道函式的序號與名稱，但在動態連結的過程中會建立起一個連連看表格將載入端的函式呼叫與被載入端內的函式正確位址給連結起來。

那我們要怎樣才能夠達成輸出的動作，其實很簡單，你只要在你的應用程式中需要輸出的函式前頭加上：__declspec(dllexport) 即可，如：

__declspec(dllexport) void Function(void);

這樣一來就會把Function(void) 這個函式給放到輸出表格上頭了。

先前還有提到還可以將C++ 類別透過DLL 來輸出，可以的一樣是加上__declspec(dllexport) ，如：

class __declspec(dllexport) __stdcall MyClass : public TObject{ … …};

當我們在看輸出表格時，會發現函式的輸出表格前頭好像有個如圖三一般的資料：

這就是函式的輸入表格，這裡列出來的是USER32.DLL 裡頭被我們使用到的函式。一樣的怎樣建立輸入表格呢？一般的Win32 API 都已經在其所屬的Header File 裡頭定義好了，我們只需加上#include 就可以安心使用了，而對於自行打造的DLL 中的輸出函式我們在載用此DLL 的載入端就得在函式的宣告前面加上__declspec(dllimport) ，如：

__declspec(dllimport) void Function(void);

目的是告訴編譯器Function(void) 這個函式是由外部輸入的。

Name Mangling

嗯！經過了先前的說明，讀者們應該知道若要在DLLs 中將函式輸出，僅需要在函式的宣告中加上__declspec(dllexport) 即可，若要載入別的DLLs 中的函式則須在函式的宣告中加上__declspec(dllimport) ，但這僅止於C 編譯器，在C++ 編譯器裡頭是行不通的，怎麼說呢？就拿一個多載（overloading ）的例子來說，如果函式的名稱都相同（當然所傳的參數型別不同），編譯器應該會如何處理？到底那個才是我們真正使用到的函式呢？其實在編譯器做編譯動作時，對這些同名的函式都動了點手腳讓同名的函式偷偷地變成不同名稱，以下面同名的三個函式為例：

int Func(int X);

int Func(float X);

void Func(double *d);

使用C++Builder 3.0 所編譯出來的函式名稱為：（註2 ）

@Func$qf

@Func$qi

@Func$qpd

而使用Visual C++ 6.0 所編譯出來的函式名稱為：（註3 ）

?Func@@YAHH@Z

?Func@@YAHM@Z

?Func@@YAXPAN@Z

編譯器這個偷偷修改函式名稱的行為稱為『name mangling 』，但除了函式名稱被改變外你是否發現還現另一件很嚴重的事情，就是同的編譯器竟然有著不同的name mangling 做法，這表示著若咱們若使用Borland C++Builder 編譯器來開發應用程式時將無法使用一個經由Microsoft Visual C++ 所編譯器完成的函式庫。此外，Naming Mangling 的作用不止於多載的函式上，C++ 程式中所有的global 函式以及class 中所有的成員（members ）都會被name mangling 這個動作給整型一下。那這樣不就沒戲唱了！若要在C++Builder 下使用Visual C++ 所編譯的DLLs 豈不都得擁有DLLs 的原始碼才能囉？其實不然，有方法可抑制name mangling 的作用，就是在函式的宣告錢加上extern “C ” 這個修飾詞，強制將函式以C 語言的行台重現，而非以C++ 語言的形態出現。但是要注意，多載函式可不能加上extern ”C ” 這個修飾詞，因為這個會造成一堆名稱相同的函式，若你硬是要使用extern “C ” 在多載含上，編譯器一定會送你一個ERROR （如下）做獎品。

in C++Builder ：

[C++Error]Project1.cpp(13): Only one of s set of overloaded functions can be “C ”.

in Visual C++

error C2733 : Second C linkage of overloaded function ‘Func ’ not allowed

因此若拿原先多載的例子給加上extern “C ” ：

extern “C ” int Func(int X);

則會被編譯器給編譯成：

in Visual C++ ：

_Func

in C++Builder ：

_Func

似乎兩個編譯器已經達成了一致的輸出。嗯！這樣一來就可以把DLLs 互相使用了，不不不！還沒有那麼簡單，還有一個重要的議題『Call Conventions 』，不過這個問題在此先不提，放到後頭在提，先談談怎樣使用C++Builder 來建立DLLs 吧！

建立DLL

使用C++Builder 來建立DLL 並不是什麼難事，只需要按下幾下滑鼠的左鍵即可。在C++Builder 下建立DLLs 大致分成兩種方法，先按選單上的File|New 後會出現New Items 對話盒（Dialog ）（圖四）：

選擇New Items 對話盒中的Console Wizard 選項按下OK 後再選擇DLL 即可。（圖五）
選擇New Items 對話盒中的DLL 那個選項按下OK 即可。

方法一是建立一個標準的DLL Project ，不允許使用任何VCL 類別，而方法二所打造出來的DLL 則是可建立包含了VCL 類別的DLL （當然你也可以不使用VCL 類別），而這兩個功能在Visual C++ 中差可比擬的是Win32 Dynamic-Link Library 與MFC AppWizard(dll) 。

按完OK 或Finish 後你會看到DLL Project 與些許程式碼的產生，這段由C++Builder 自動產生的程式碼中分兩大部分，第一部份是個很長一串的註解，最後就是所謂的DLL 進入點。先來了解這一長串的註解，由方法一與方法二製造出來的DLL Project 註解有點不相同，不過內容大致上差不多，內容如是說：如果我們的DLL 內使用到了字串物件如：AnsiString ，或是在輸出函式的參數或回傳值使用到長字串的話，就必須加入MEMMGR.LIB 這個函式庫。另外，若我們在另一個模組（如DLL ）中使用了例如new 或GetMem 等方法來配置記憶體，而在不同的模組（如EXE 應用程式）中使用了這塊記憶體或呼叫FreeMem 等方法來釋放記憶體，則MEMMGR.LIB 也是必須被加入的。此外還有一個值得注意的，就是MEMMGR.LIB 必須加在所有要用到函式庫的最前頭，以便在其他函式庫之前優先載入並接手相關的記憶體維護。同時要記住的是若你使用了MEMMGR.LIB 這個函式庫，那麼當你移交DLL 或是應用程式時，你必須連同BORLNDMM.DLL 一併移交給使用者。不過在這段聲明的倒數第二段中有提到，若要避免額外的檔案付給使用者（越多的檔案對使用這來說是一種負擔），你可以將有關字串的資料改由char * 或是shortstring 來傳送，這樣可以不動用到BORLNDMM.DLL 與MEMMGR.LIB 來作記憶體的配置。另外，聲明的最後一段中有提到，若你在 Project\Options 裡頭的Link 一頁勾選了Use Dynamic RTL 一項時，就不須額外手動將MEMMGR.LIB 給加到Project 裡頭了，因為C++Builder 會自動幫你做這個動作。

緊接著咱們來看一下DLL 的進入點

DLL 的進入點：DLLMain

以下是由方法二生產出來的DLL 原始碼：

//---------------------------------------------------------------------------
#include
#pragma hdrstop
//---------------------------------------------------------------------------
int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void*)
{
return 1;
}
//---------------------------------------------------------------------------

在Win32 平台的程式設計中，明言規定DLL 的進入點函式定義為DllMain ，可是我們怎麼看到的是DllEntryPoint 呢？這是Borland 對於標準的DLL 所動的一點點手腳，當然你若執意把DllEntryPoint 給改成DllMain 也是可以的，但是你要注意，當你更動DllEntryPoint 時，C++Builder 工具列上頭的Run 會被Disable 喔！這是就是擺明了不給你編譯，即使你使用Project\Build All 也會送給你錯誤訊息，不過你可以在DllMain 函式之後加上#define WinMain 就可以編譯了，不過筆者並不建議在C++Builder 下這麼用。

早在討論輸入輸出表時就已經知道若不考慮到各個編譯器間DLL 的互相引用，我們大可把輸出函式這麼寫：

__declspec(dllexport) int MyFunc (void);

若要輸出整個類別則可以這樣寫：

class __declspec(dllexport) MyClass : public TObject{...};

但是注意，這若這樣寫僅可以在自己寫作DLL 的編譯器中來使用這個DLL 了，並沒辦法達到其他編譯器也可以使用的目的，大大的抹殺了軟體元件的構想，更何況DLL 是採用模組化的設計。當然了！類別的輸出當然不在考慮範圍內，但若對函式的輸出咱們還是乖一點，加上extern “C ” 來遏止name mangling 對我們函式名稱所動的手腳：

extern “C ” __declspec(dllexport) int MyFunc (void);

有了這些基礎知識後，咱們來來真正撰寫一個有用的DLL 試試看吧！那要做些什麼呢？咱們就做個簡單的訊息視窗即可，怎麼做，其實說穿了就是把Windows API MessageBox 給稍微包裝一下，不過還是用MessageBox 這個函式來實作內容，讀者們可能覺得，這麼無聊還在包裝一次MessageBox 函式幹嘛？這個嘛！不過做個測試嘛！

先使用Consol Wizard 來產生DLL Project ，並將此Project 儲存為ShowMsg.bpr ，在DLL 的進入點DllEntryPoint 之後加上以下的程式碼：

extern “C ” __declspec(dllexport) int ShowMsg(char *pText,HWND hWnd)
{
return MessageBox(hWnd,pText,"Information",MB_OK);
}

嗯！這樣一來咱們只要呼叫ShowMsg() 函式，並將要秀出來的文字與視窗代碼當作參數來傳即可。緊接著只需按下Ctrl+F9 就開始編譯了並產生出ShowMsg.dll 了。

使用DLLs 中的函式 ─DLLs 的載入

知道了怎樣建立起一個DLL 後，接著就是了解如何使用DLL 裡頭所提供的函式的時候了，在使用這些函式之前還必須做個更重要的動作，就是將DLL 給載入。載入DLLs 的方法大致上可以分成兩個：

Implicit Linking 與Explicit Linking 。

Implicit Linking

Implicitly Link （隱式聯結）又稱靜態載入，所謂靜態載入是指程式在聯結時期即與DLLs 所對應的import libraries 做靜態鏈結，於是可執行檔中便對所有的DLL 函式都有一份重定位表格(relocation table) 和待修正記錄(fixup record) 。當程式被Windows 載入器載入記憶體中，載入器會自動修正所有的fixup records ，而這個fixup records 就是記錄由DLL 中所有輸出資源的正確位址，也就是先前提到的RVA 加上DLL 被載入的基底位址，經過這樣的程序動態聯結便順利產生。也就是說，程式開始執行時，會用靜態載入方式所使用到的DLLs 都載入到行程的記憶體裡。先來看看靜態載入放是的優點：

1 、靜態載入方式所使用到的這個DLL 會在應用程式執行時載入，然後就可以呼叫出所有由DLL 中匯出的函式，就好像是包含在程式中一般。

2 、動作較為簡單，載入的方法由編譯器負責處理，咱們不須動腦筋。
而缺點是：

1 、當這個程式靜態載入方式所使用到的這個DLL 不存在時，這個程式在開始時就出現無法找到DLL 的訊息而導致應用程式無執行。

2 、編譯時需要加入額外的import library 。

3 、若是要載入的DLLs 一多，載入應用程式的速度會便慢。

4 、若遇到不同品牌的C++ 編譯器時，靜態載入可就沒有這麼簡單處理了，因為當函式經過Calling Conventions 的處理後，若要使用其他品牌編譯器所致造出的DLL 須得大動干戈才行。
Implicit Linking 範例：

以先前建立的ShowMsg.DLL 為例子，我們已知這個DLL 僅輸出一個函式：ShowMsg ，且知道這個函式的原始定義：

extern “C ” __declspec(dllexport) int ShowMsg(char *pText,HWND hWnd);

因此，若我們要載入這個函式則必須在應用程式中加入此輸入函式的宣告：

extern “C ” __declspec(dllimport) int ShowMsg(char *pText,HWND hWnd);

此外，還要加上這個DLL 的import library File ，要產生import library 的方法有兩個：

1 、Project\Options 的Linker 中的Geretate import library 勾選，在正常情況下，預設值是勾選起來的。

2 、若不小心把lib 檔案給刪除掉了，也可以利用implib.exe 這個C++Builder 所附上的工具來產生lib 檔，implib 是文字模式下的程式，因此必須到文字模式下使用，以我們現在的例子來說，使用方式為：implib ShowMsg.lib ShowMsg.dll ，這樣就會產生ShowMsg.lib 檔了。
緊接著就是加入這個lib 檔到咱們的Project 裡頭，可以使用【Project\Add to Project … 】來加入lib 檔。如此一來就可以在應用程式的任何地方使用ShowMsg 函式了。

不過在此我們發現一個小問題，若每次要匯入DLL 裡頭的函式，還必須把函式的原始定義給抄過來（雖然說複製 ─ 貼上這個動作很簡單），但有沒有更好的辦法呢？有的，咱們可以在DLL 原始碼的Header File 裡動點手腳，讓要使用DLL 的應用程式只需include 這個Header File 就可以了，怎麼做呢？就是使用前置處理符號，若是使用Borland C++ 或是Borland C++Builder 來編譯DLL 都必須加上#define __DLL__ 這個宣告，但是我們從C++Builder 所幫我建立的Project 裡面看不到這個，原因是C++Builder 已經在Make file 裡幫我們加上-WD 這個編譯參數來達成#define __DLL__ 所要的目的了。所以我們可以把ShowMsg.h 給改成：

程式列表一、ShowMsg.h

//---------------------------------------------------------------------------
#ifndef ShowMsgH
#define ShowMsgH
//---------------------------------------------------------------------------
#ifdef __DLL__
#define DLLAPI extern "C" __declspec(dllexport)
#else
#define DLLAPI extern "C" __declspec(dllimport)
#endif
DLLAPI int ShowMsg(char *pText,HWND hWnd);
#endif

程式列表二、ShowMsg.cpp

#include
#pragma hdrstop
#include
USEFILE("ShowMsg.h");
//---------------------------------------------------------------------------
#pragma argsused
int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void*)
{
return 1;
}
//---------------------------------------------------------------------------
int ShowMsg(char *pText,HWND hWnd)
{
return MessageBox(hWnd,pText,"Information",MB_OK);
}

這樣一來，只需要在應用程式裡加入這個Header File 並將ShowMsg.lib 檔給加入這個Project 裡頭，就大功告成了

Explicit Linking

而所謂Explicitly link （顯式聯結）又稱動態載入，若是使用動態載入就是需要時才載入DLL ，然後在使用過後即釋放DLL ，嗯！似乎是很不錯的選擇，這種方法的優點有：

1 、DLL 只要需要時才會載入到記憶體中，可以更有效的使用記憶體。

2 、應用程式載入的速度較使用隱式鏈結時快，因為當程式開始載入時並不需要把DLL 給載入到行程中。

3 、編譯時不須額外的import library 檔。

4 、讓我們可以更清楚DLL 的載入流程。
但不光只有優點也是點缺點的，缺點就是必須寫多一點程式碼。首先，必須使用LoadLibrary 這個Windows API 來手動載入DLL ，並使用GetProcessAddress 來取得所要使用的函式的函式指標，最後不需要用到此DLL 時使用FreeLibrary 將DLL 釋放。所以，在學會動態載入DLL 時，必須先知道函式指標的用法。

Explicit Linking 範例：

咱們就拿一個常見的DLL ─ 控制TWAIN32 界面的DLL ：『Eztw32.dll 』來作動態載入的示範：

eztw32.dll 裡頭有四十多個輸出函式可以使用，不過只有以下這四個函式是我們所要用到的：

1 、void __stdcall TWAIN_SelectImageSource(HWND hwnd);

功能：用來選擇所要使用的TWAIN 介面裝置

2 、int __stdcall TWAIN_AcquireToClipboard(HWND hwnd, unsigned int pixmask);

功能：經由TWAIN 介面將資料置放到剪貼簿中

3 、int __stdcall TWAIN_LoadSourceManager(void);

功能：呼叫TWAIN 介面裝置程式

4 、int __stdcall TWAIN_UnloadSourceManager(void);

功能：關閉TWAIN 介面裝置程式

再度使用tdump 來觀察eztw32.dll 裡頭的輸出函式表：

Exports from EZTW32.dll

50 exported name(s), 50 export addresse(s). Ordinal base is 1.

Ordinal RVA Name

------- -------- ----

0000 00001000 DllMain

...

0003 000012c0 TWAIN_AcquireToClipboard

...

0029 00001650 TWAIN_LoadSourceManager

...

0038 000010a0 TWAIN_SelectImageSource

...

0046 00001980 TWAIN_UnloadSourceManager

...

先確認函式的名稱以及函式的序號，等一下會用到。

接著就是開始將DLL 載入了，Win32 API 有兩個函式提供了將DLL 載入的功能，分別是LoadLibrary 與LoadLibraryEx 。通常都使用LoadLibrary ，先看看LoadLibrary 的原始定義：

HINSTANCE LoadLibrary(

LPCTSTR lpLibFileName // address of filename of executable module

);

嗯！只需要傳入檔案名稱即可，若以我們所要使用的Eztw32.dll 為例：

HINSTANCE hDLL;

hDll = LoadLibrary( “Eztw32.dll ”);

若我們沒有指定副檔名，則自動會以『.DLL 』為副檔名，或許會感到納悶，那我還沒有指定DLL 的路徑啊！正確的做法應該是要指定路徑的，但是天曉得使用者會把DLL 給放到哪裡去呢？所以使用LoadLibrary 這個函式時，若參數中沒有指明路徑，系統會依特定的次序來找尋DLL 的存在與否，若不存在則LoadLibrary 函式則會回傳NULL ，以下就是搜尋次序：

1 、被執行的應用程式所存在的路徑。

2 、目前的目錄。

3 、Windows 系統目錄，對Windows 95/98 說是Windows\System ，而Windows NT 則是Winnt\System32 。目錄名稱可以使用GetSystemDirectory 這個API 來取得。

4 、Windows 目錄。目錄名稱可以使用GetWindowsDirectory 這個API 來取得。

5 、最後由設定的PATH 環境變數來尋找。
這也就是為什麼我們的Windows\System 目錄下有這麼多DLL 的原因之一了。

把DLL 載入記憶體後最重要的工作就是把函式指標指向函式在記憶體中正確的位址，要做到這個動作得透過GetProcAddress 這個API 來幫忙：

FARPROC GetProcAddress(

HMODULE hModule, // handle to DLL module

LPCSTR lpProcName // name of function

);

GetProcAddres 函式的第一個參數是經由LoadLibrary 所取得的DLL 的Handle ，而第二個參數是函式的名稱或是函式的輸出序號經由函式名稱取得函式的指標，以eztw32.dll 中的TWAIN_SelectImageSource 函式為例，應由函式名稱取得函式的位址的方法為：：

GetProcAddress(hDLL, ”TWAIN_SelectImageSource ”);

若經由函式輸出序號取得函式的位址則為：

GetProcAddress(hDLL, MAKEINTRESOURCE (39));

在此要注意序號的起始值是1 不是0 ，經由 tdump 所列出來的Ordinal 是由起始值開始的位移植，而Ordinal Base 為1 ，因此TWAIN_SelectImageSource 的序號是39 而不是 38 。

接著在此先複習一下函式指標的使用方式，一樣TWAIN_SelectImageSource 函式為例，TWAIN_SelectImageSource 函式的原始定義為：

void __stdcall TWAIN_SelectImageSource(HWND hwnd);

那就可以用：

void (__stdcall *TWAIN_SelectImageSource)(HWND hwnd);

來宣告TWAIN_SelectImageSource 為一個函式指標，之後再用：

TWAIN_SelectImageSource = (void (__stdcall *)(HWND hwnd))

GetProcAddress(hDLL, ”TWAIN_SelectImageSource ”);
來取得函式的位址，之後就在程式中若要使用TWAIN_SelectImageSource 這個函式就可以像是靜態載入般使用了。但這樣似乎得打蠻多字的，偷懶的我通常都使用另一個方法，就是使用typedef 來自訂型別。方法如下：

typedef void (__stdcall *_TWAIN_SelectImageSource)(HWND hwnd);

_TWA IN_SelectImageSource TWAIN_SelectImageSource;

TWAIN_SelectImageSource = (_TWAIN_SelectImageSource)

GetProcAddress(hDLL, ”TWAIN_SelectImageSource ”);

先使用typedef 把_TWAIN_SelectImageSource 給定義成一個特殊的型別，之後就可以直接引用，的確是可以少打點字。

最後當DLL 裡頭的函式不再需要使用時，咱們就得使用FreeLibrary 將DLL 從記憶體裡頭卸下來：

BOOL FreeLibrary(

HMODULE hLibModule // handle to loaded library module

);

使用方法很簡單只需將LoadLibrary 所傳回來的DLL Handle 當參數傳給FreeLibrary 傳入即可。

懂得這些動態載入DLL 的流程後，就可以實際動手來做做看。筆者發現TWAIN32 這些功能實在很適合包裝成一個物件，當物件誕生時，立即自動去LoadLibrary 並將函式指標的位址給連結起來，當這個物件被摧毀時，就自動去FreeLibrary ，嗯！似乎不錯，不過詳細的做法就不多做解釋了，相信讀者看了下面的程式列表應該就懂了。

程式列表三、CTWAIN.h ：

//---------------------------------------------------------------------------
#ifndef CTWAINH
#define CTWAINH
#include
//---------------------------------------------------------------------------
// 用typedef 自訂函式指標的型別
typedef int (__stdcall *_TWAIN_AcquireToClipboard)
(HWND hwnd, unsigned int pixmask);
typedef int (__stdcall *_TWAIN_LoadSourceManager)
(void);
typedef void (__stdcall *_TWAIN_SelectImageSource)
(HWND hwnd);
typedef int (__stdcall *_TWAIN_UnloadSourceManager)
(void);
class CTWAIN
{
public:
__fastcall CTWAIN(void);
__fastcall ~CTWAIN(void);
void __fastcall SelectImageSource(HWND hWnd);// 選擇TWAIN32 設備
void __fastcall Acqure(HWND hWnd);// 經由TWAIN32 設備取得資料
Graphics::TPicture *Picture;
protected:
private:
// 宣告函式指標
_TWAIN_AcquireToClipboard TWAIN_AcquireToClipboard;
_TWAIN_LoadSourceManager TWAIN_LoadSourceManager;
_TWAIN_SelectImageSource TWAIN_SelectImageSource;
_TWAIN_UnloadSourceManager TWAIN_UnloadSourceManager;
HINSTANCE hDLL;
};
//---------------------------------------------------------------------------
extern bool __stdcall CheckTWAINDLL();// 檢驗DLL 檔案是否存在的函式
#endif

程式列表四、CTWAIN.cpp ：

//---------------------------------------------------------------------------
#include
#pragma hdrstop
#include "CTWAIN.h"
//---------------------------------------------------------------------------
#pragma package(smart_init)
__fastcall CTWAIN::CTWAIN()
{
hDLL = ::LoadLibrary("Eztw32.dll");// 載入DLL 到行程的記憶體內
// 取得所需函式的函式指標
TWAIN_AcquireToClipboard = (_TWAIN_AcquireToClipboard)
::GetProcAddress(hDLL,"TWAIN_AcquireToClipboard");
TWAIN_LoadSourceManager = (_TWAIN_LoadSourceManager)
::GetProcAddress(hDLL,"TWAIN_LoadSourceManager");
TWAIN_SelectImageSource = (_TWAIN_SelectImageSource)
::GetProcAddress(hDLL,"TWAIN_SelectImageSource");
TWAIN_UnloadSourceManager = (_TWAIN_UnloadSourceManager)
::GetProcAddress(hDLL,"TWAIN_UnloadSourceManager");
Picture = new Graphics::TPicture;
}
//---------------------------------------------------------------------------
__fastcall CTWAIN::~CTWAIN()
{
delete Picture;
::FreeLibrary(hDLL);// 從記憶體中釋放DLL
}
//---------------------------------------------------------------------------
void __fastcall CTWAIN::SelectImageSource(HWND hWnd)// 選擇TWAIN32 設備
{
TWAIN_SelectImageSource(hWnd);
// 使用DLL 裡頭的TWAIN_SelectImageSource 函式
}
//---------------------------------------------------------------------------
void __fastcall CTWAIN::Acqure(HWND hWnd)// 經由TWAIN32 設備取得資料
{
if (TWAIN_LoadSourceManager() > 0)
// 使用DLL 裡頭的TWAIN_LoadSourceManager 函式
{
if (TWAIN_AcquireToClipboard(hWnd,0)>0)
// 使用DLL 裡頭的TWAIN_AcquireToClipboard 函式
{
Clipboard()->Open();
if (Clipboard()->HasFormat(CF_PICTURE))
Picture->Assign(Clipboard());
Clipboard()->Clear();
Clipboard()->Close();
}
TWAIN_UnloadSourceManager();
// 使用DLL 裡頭的TWAIN_UnloadSourceManager 函式
}
}
//---------------------------------------------------------------------------
bool __stdcall CheckTWAINDLL()// 檢驗DLL 檔案是否存在的函式
{
HANDLE hDll = ::LoadLibrary("EZTW32.DLL");
if(hDll == NULL)
{
::MessageDlg("Error! Could not found EZTWtw32.dll",
mtInformation,TMsgDlgButtons()<
return false;
}
::FreeLibrary(hDll);
return true;
}
//---------------------------------------------------------------------------

當建構好這個CTWAIN 類別後，若我們要使用這剛剛建好的類別，我們可以寫成兩個函式：

1 、void SelectSource(HWND hWnd);

選擇TWAIN32 設備的來源

2 、void Acquire(HWND hWnd);

經由選定的TWAIN32 設備來源將資料取得

//---------------------------------------------------------------------------
void SelectSource(HWND hWnd)// 選擇TWAIN32 設備的來源
{
if (CheckTWAINDLL())
{
CTWAIN TWAIN;
TWAIN.SelectImageSource(hWnd);
}
}
//---------------------------------------------------------------------------
void Acquire(HWND hWnd)// 經由選定的TWAIN32 設備來源將資料取得
{
if (CheckTWAINDLL())
{
CTWAIN TWAIN;
TWAIN.AcqureScanner(hWnd);
if (TWAIN.Picture->Graphic != NULL)
{
//Do the processing that you want to do with the TWAIN.Picture
TWAIN.Picture->Graphic = NULL;
}
}
}
//---------------------------------------------------------------------------

相形之下，似乎靜態載入的方式方便多了，不用下這麼多工夫在手動載入DLL 並手動分派各函式的實際位址，若遇到一大堆輸出函式豈不光Keyin GetProcAddress 那一段就得花上許多時間。但若用到不同品牌的C++ 編譯器所產生的DLL 時，採用動態載入加上以函式輸出序號來取得函式指標的方式，僅需利用TDUMP 製造初一張序號表再加上勤勞的打字即可無須再動什麼腦筋。稍後會提到怎麼樣在C++Builder 下使用靜態載入來載入Visual C++ 所編譯出來的DLL 。這樣相形之下，反而又會覺得用動態載入方便些。

Calling Conventions

因為不同的語言間有不同的傳遞參數的方法，而C/C++ 編譯器為了能夠使用由其他語言開發出來的函式庫加上了這些參數傳遞方式不同的方式稱為calling conventions （呼叫慣例），如在C++Builder 裡頭常常看到的__fastcall ；一般常用的呼叫慣例有以下四種：

呼叫慣例	說明	參數傳遞方式
__cdecl	傳遞的參數由呼叫函式清除。	由右往左的次序將參數傳遞到堆疊之中。
__stdcall	傳遞的參數由被呼叫函式清除。一般使用於Win32 的標準呼叫，在DLLs 間的呼叫大部分都使用__stdcall 。	由右往左的次序將參數傳遞到堆疊之中。
__fastcall	傳遞的參數由被呼叫函式清除。在C++Builder 中__fastcall 為VCL 元件使用的內定呼叫慣例。	in C++Builder ：由左往右的次序傳遞參數，第一個參數由EAX 傳遞，第二個由EDX 傳遞，第二個由ECX 傳遞，其餘操超過的參數再交由堆疊傳遞。 in Visual C++ ：由左往右的次序傳遞參數，第一個參數由ECX 傳遞，第二個由EDX 傳遞，其餘操超過的參數再交由堆疊傳遞。
__pascal	傳遞的參數由被呼叫函式清除，在Windows 3.1 時期__pascall 為標準用法，但到了Windows 95/NT 後以鮮少使用。	由左往右的次序將參數傳遞到堆疊之中。Visual C++ 已經不支援__pascal 此呼叫方式。因此在此不做__pascal 的討論。

但光是說說很難了解到這些參數傳遞方式有何異同，以下函式分別使用__cdecl 、__stdcall 與__fastcall 三種呼叫慣例當做範例：

void calltype MyFunc(char c, shorty s, int i , double f);

當我使用這個函式：

MyFunc( “x ”,12,8192,2.7183);

時會被編譯器編譯成如以下四圖：

由圖八與圖九中可以看出__fastcall 在兩個編譯器中有顯著的不同，C++Builder 使用了三個暫存器來存放參數，讓傳遞的速度更為加快，這也就是VCL 類別中的預設呼叫慣例為__fastcall 的原因。暫且撇開__fastcall 的不同，呼叫慣例造成的還不只這一樣差異，還有著與name mangling 有點類似的麻煩，就是函式的名稱更動問題。當你使用不同的呼叫慣例時，編譯器還是對動點手腳，動什麼手腳，筆者用以下的範例做觀察，先定義四個函式分別使用__fastcall 、__stdcall 與__cdecl 與不指定四種呼叫慣例：

#define DLLEXP extern "C" __declspec(dllexport)
DLLEXP int MyFunc_Default(char *c,int X)
{
return X;
}
DLLEXP int __fastcall MyFunc_Fast(char *c,int X)
{
return X;
}
DLLEXP int __stdcall MyFunc_Std(char *c,int X)
{
return X;
}
DLLEXP int __cdecl MyFunc_Cdecl(char *c,int X)
{
return X;
}

定義好後分別使用C++Builder 與Visual C++ 將這四個函式編譯成DLL 檔，編譯完成後使用tdump 與impdef 來觀察這些函式的輸出結果：（IMPDEF 的用法為 IMPDEF def_file dll_file ）

）

經由上述簡單的實驗可以將兩者的差異列出，並且可以找出編譯器預設的呼叫慣例：

呼叫慣例	原始函式	Borland C++Builder	Microsoft Visual C++
__cdecl	MyFunc_cdcel	_MyFunc_cdcel	MyFunc_cdcel
__stdcall	MyFunc_std	MyFunc_std	_MyFunc_std@8
__fastcall	MyFunc_fast	@MyFunc_fast	@MyFunc_fast@8
─	MyFunc_default	_MyFunc_default	MyFunc_default
預設呼叫慣例	─	__cdecl	__cdecl

由表上可以看出兩者間的差異還不少呢！而為什麼要討論到這一點呢？因為接著就要討論到如何拿Visual C++ 所編譯的DLL 到C++Builder 裡頭使用。

在Borland C++Builder 下使用Microsoft Visual C++ 所編譯的DLLs

若已經解決了name mangling 與calling convention 的理想狀況下，由C++Builder 下來呼叫Visual C++ 所編譯出來的DLLs 應該不是難事才對。但不幸的，只對了一半，怎麼說，幸運的那一半是，咱們可以利用先前提過的『動態載入』方式來載入DLLs 中的函式，即使因為calling convention 的問題導致函式名稱在編譯後會被更動，但是只要知道函式的輸出序號就可以照樣載入；不幸的那一半是若採用『靜態載入』的方法就又會遇上了個大難題：Borland 與Microsoft 所使用的OBJs 檔案格式不相同；Borland 採用Intel 所訂定的OMF （Object Module Format ）格式而Microsoft 採用COFF （Common Object File Format ）格式，因此若要拿Visual C++ 所編譯的DLLs 與LIBs 來使用，僅有DLLs 能夠用而已，LIBs 毫無用武之地，但謝天謝地，Borland 提供了一個工具IMPLIB.EXE ，可以直接從任何編譯器所編譯出的DLLs 裡頭將OMF 格式的LIBs 給製造出來。因此製造C++Builder 相容的OMF 格式LIBs 不算是個大問題了。但對於Calling Convention 所產生的問題就比較麻煩些，接下來咱們就來討論如何使用靜態載入來載入Visual C++ 所製造出來的DLLs 。

要將Visual C++ 所製造出了DLLs 搬到C++Builder 來用大致上分三個步驟：

A 、檢驗輸出函式的設呼叫慣例

由先前呼叫慣例的實驗裡看得出來，兩種編譯器的預設呼叫慣例皆為__cdecl ，而__cdecl 與__stdcall 的參數傳遞方式兩個編譯器也相同，但是在C++Builder 下__fastcall 為VCL 的標準呼叫慣例，而且為了加速參數的傳遞，參數傳遞的方法與Visual C++ 不同，若是硬搬到C++Builder 來使用，恐有問題出現；因此若要拿Visual C++ 所編譯的DLL 來使用，切記只能使用__cdecl 與__stdcall 這兩種呼叫慣例。

B 、查驗經過編譯器編譯後的函式名稱

由呼叫慣例的實驗結果裡看出，__cdecl 與__stdcall 在兩個編譯器下所編譯出的正式名稱稍有不同，以一個簡單的 void MyFunction(void); 為例：

呼叫慣例	Borland C++Builder	Microsoft Visual C++
__cdecl	_MyFunction	MyFunction
__stdcall	MyFunction	_MyFunction@4

我們必須檢查看看哪些函式是使用__stdcall 而哪些函式是使用__cdecl ，接下來下一個步驟就是轉換這些名稱，將名稱由C++Builder 不認得變成認得。

C 、製作OMF 格式的LIBs

由於經過編譯器處理過後的函式名稱已經與原先函式名稱不相同了，因此若直接轉換成LIBs 檔也無啥效用，必須動點手腳。先前已經學過IMPDEF 的使用方法，先前是用在觀察輸出函式，現在也是，但還多了動手腳的部份。

利用先前測試的那個VC6TEST.DLL 來製造DEF 檔案：（__fastcall 的呼叫慣例部份記得要先除去）

IMPDEF VC6TEST.DEF VC6TEST.DLL

製造出來的DEF 檔：

LIBRARY VC6TEST.DLL

EXPORTS

MyFunc_Cdecl @1

MyFunc_Default @2

_MyFunc_Std@8 =_MyFunc_Std @3

這時候我們就來動手腳，把C++Builder 不認得給改承認得的。改成如下：

EXPORTS

;use this type of aliasing

;(Borland name) = (Name exported by Visual C++)

MyFunc_Std = _MyFunc_Std@8

_MyFunc_Cdecl = MyFunc_Cdecl

_MyFunc_Default = MyFunc_Default

最後再將DEF 檔給還原成LIB 檔，什麼？你有沒有說錯把DEF 這個文字檔變回LIB 檔？是的，其實靜態載入所需要用到的LIB 檔案只是個函式表格罷了，並沒有真正函式內容在裡頭，因此我們可以經由動過手腳的DEF 檔給還原成LIB 檔：

IMPLIB VC6TEST.lib VC6TEST.def

動完手腳後不忘還要去檢查一下是否函式輸出，可以使用TLIB 來觀察最後的test.lib 是否正確輸出：

TLIB VC6TEST.lib,VC6TEST.txt

Publics by module

_MyFunc_cdecl size = 0

_MyFunc_cdecl

_MyFunc_default size = 0

_MyFunc_default

MyFunc_std size = 0

MyFunc_std

可以由觀察test.txt 來檢驗輸出的正確與否，在確定輸出名稱無誤後就可以直接拿進C++Builder 做先前已經說明過的靜態載入測試了。我的測試方法為建立一個Console Application 來載入這個DLL 做測試。

#pragma hdrstop
#include
//---------------------------------------------------------------------------
USELIB("VC6test.lib");
//---------------------------------------------------------------------------
#pragma argsused
#define DLLIMP extern "C" __declspec(dllimport)
DLLIMP int MyFunc_default(char *c,int X);
DLLIMP int __stdcall MyFunc_std(char *c,int X);
DLLIMP int __cdecl MyFunc_cdecl(char *c,int X);
#include
#include
int main(int argc, char **argv)
{
printf("int x = MyFunc_std(\"x\",123);\n");
int x = MyFunc_std("x",123);
printf("Result : x = %d\n",x);
printf("int y = MyFunc_cdecl(\"x\",2323);\n");
int y = MyFunc_cdecl("x",2323);
printf("Result : y = %d\n",y);
getch();
return 0;
}

輸出結果：

int x = MyFunc_std("x",123);

Result : x = 123

int y = MyFunc_cdecl("x",2323);

Result : y = 2323

這樣一來算大功告成，但在筆者的經驗中使用Visual C++ 來寫作DLL 供Borland C++Builder 使用，有以下幾點是值得注意的：

抑制name mangling 的行為
一定要記住為輸出函式加上 extern “C ” 來抑制 name mangling 的動手腳。
禁止輸出類別

為什麼要禁止類別的輸出呢？因為Visual C++ 處理類別的方式與C++Builder 有著很大的不同。所以少用為妙。
結語

這次筆者大多著墨於DLLs 的使用，怎麼建立DLLs 的方法卻只大略一題，因為製造DLLs 的方法有很多，也有很多的技巧，若把這些通通都給寫出來，可能這個主題就要變成連載小說般分成好幾期來刊載了，一期為時一個月，討論這個主題的時間會拖得太久，且相差時間會過久，造成讀者的無法連貫，筆者只好忍痛割捨，不過筆者在此還是列出數本對於製作DLLs 一題著墨相當詳細的書籍：

1 、Adcanced Windows 3/E, Microsoft Press, Jeffrey Richter Chapter 12

2 、Programming Windows 95, Microsoft Press, Charles Petzold Chapter 19

3 、Multithreading Application in Win32, Addison Wesley, JimBeveridge, etc . Chapter 14

4 、Borland C++Builder 3 Unleashed, Sams Publishing, Charlie Calvert, etc. Chapter 35

註1 、PE 格式的執行檔：PE ，Portable Executable ，是Microsoft 設計用於其所有Win32 作業系統（Win32s 、Windows NT 及Windows 95/98 ）的可執行檔格式。

註2 、在C++Builder 下觀看編譯器產生的真正名稱方法：

選單上『Project/Options 』裡的『Linker 』一頁中的Map File 選項中勾選derailed ：

註3 、在Visual C++ 下觀看編譯器產生的真正名稱方法：

選單上『Project/Settings … 』中『Link 』一頁且Category 為General 時將Generate mapfile 選項勾選。

參考資料、

Windows 95 System Programmung SECRETS, IDG BOOKS, Matt Pietrek
Adcanced Windows 3/E, Microsoft Press, Jeffrey Richter
Programming Windows 95, Microsoft Press, Charles Petzold
Borland C++Builder 3 Unleashed, Sams Publishing, Charlie Calvert
High Preformance Borland C++Builder, Coriolis Group Books, Matt Telles

MiGi's Notes

Wednesday, July 19, 2006

Visual Basic Secrets

Tuesday, July 18, 2006

World of Game Hacking - Breaking the packet encrypting in Tibia 7.72

Wednesday, July 12, 2006

test

BCB - VC compatibility : 探訪動態連結函式庫

notes

##HIDEME##

Blog Calendar

Language Selector

Labels

My Flickr Photos

Blog Archive

Recent Comments

Plaxo Badge