Re: [GUIDE] Adding Code to Client or Server via a DLL. (Part 1.)
Quote:
Originally Posted by
zaharavn
Almost i see everyone isn't interest about problem check debug :D...
Errm. I'm confused by the negatives in that statement. Are you saying that people are, or are not interested in checking for a debugger? Or are you saying that there is a problem with using DLLs in this method, related to debuggers?
I'm not sure.:?:
Anyway... yes, you can check for debuggers, and yes, it's hard to debug a DLL on it's own, but... when you have the source, and can debug it when it's loaded in your program, where is the problem really?
I admit the problem of theft when your code is a DLL, but that isn't as likely server side... and there are ways of securing DLLs to your client, and your client to specific DLLs... it just takes some brain work. :wink:
Re: [GUIDE] Adding Code to Client or Server via a DLL. (Part 1.)
1 Attachment(s)
Re: [GUIDE] Adding Code to Client or Server via a DLL. (Part 1.)
You can use function:
IsDebuggerPresent
Example:
call IsDebuggerPresent
test eax, eax
jne @DebuggerDetected
...
IsDebugged:
mov eax, fs:[30h]
mov eax, byte [eax+2]
test eax, eax
jne @DebuggerDetected
NtGlobalFlags
mov eax, fs:[30h]
mov eax, [eax+68h]
and eax, 0x70
test eax, eax
jne @DebuggerDetected
more and more.... blah blah
Re: [GUIDE] Adding Code to Client or Server via a DLL. (Part 1.)
@zahara: Oh yes, quite. I understand you now.
The API is too easy to disable before you start debugging IMHO, but there are many ways to detect debugger and many ways to deal with it.
There are even some reasonable ways to deal with basic disassemblers and decompilers, and in my experience they work better for hindering prying eyes than encrypting.
Quote:
Originally Posted by
Gregoory
Side note : the extraction of the Build Environnmnent failed with 7-zip 4.65. Had to upgrade to the 9.10 beta.
Thanks for that note Gregoo. I believe I built that one with PeaZip 2.7 and tested it also with ALZip 6.7 and WinRAR 3.80. WinRAR reads the catalogue of files, but decompression results in an "epic fail". XD WinRAR really is a sucky program.
6.7 is the last "free for all, for ever" version of ALZip IMS, and I bloged elsewhere on how to remove the most annoying banners for their other tools from it. XD
It is compressed using the newer LZMA2, but they are in final beta for the .xz format, (which should utilize LZMA2 better than 7z and be more portable) and LZMA2 (according to benchmarks) is faster and uses less memory than standard LZMA for the same compression level.
The fact that it is under the Free Software Foundations GNU license means it will always be freely available to all, and a choice of programs will always be available to deal with the archive. Which is one big reason I like to use it.
Re: [GUIDE] Adding Code to Client or Server via a DLL. (Part 1.)
Very nice guide, I like how you organized it with a Contents table.
Thanks.
Re: [GUIDE] Adding Code to Client or Server via a DLL. (Part 1.)
Thanks AB. It's nice to know these tutorials are being read and people find them useful. :D:
This one has some waffle in it, because different people come here with different levels of skills and depths of understanding. I've tried to indent and aside anything that isn't key to the tutorial, but just background info.
You can see from the edits that I do also try to maintain my tutorials... if people are still posting about them. :wink:
So are Xternal okay with using DLLs to extend future clients?
Re: [GUIDE] Adding Code to Client or Server via a DLL. (Part 1.)
It's definitely nice to start to write real code by attaching a DLL.
Though, you seem to attach a dll, then write that DLL in asm, that's just confusing. Go write it in C++! Or atleast C, but that's still stupid since PT is written in C++ ;)
offtopic: whats with the tags of this topic? 'nerd loser, retarded faggot'.
Re: [GUIDE] Adding Code to Client or Server via a DLL. (Part 1.)
:o I hadn't noticed that. I guess one of the Admins holds this opinion of me, as nobody else has the power to change my topic tags I think. :(: Maybe because I forgot to tag, or just because I multi-posted and filled in the info later (to avoid a tutorial interspersed by chat, that I could add chapter links to) or just because I hold some strong, and unusual, opinions that I will keep. (not that I insist everyone agrees with me on them) Like Object Orientation does not make code more reusable, good documentation does that. Or Instant Messengers and Mobile Phones are EVIL. :lol: I've fixed them now.
---EDIT---
Correction... I can edit DarkKnightH20s left click tags and call him names anonymously, it seems... (of course I wouldn't) :(:
---EDIT---
Hmm. Well, yes you could use C++, but I hate it, it's too Object Orientated and even COBOL is easier to read. You could use C, but I don't really see any advantage to writing C when you can build fast, clean, clear assembler. It builds quicker, is more within your own control and despite popular opinion, I find Assembler just as readable as C. I learned and used C when I needed code to run on Z80, 68000 and 80x86 CPU based systems, but if I'm targeting only one CPU family, I don't need C.
As I've already said, you could use "useful" languages, which are more readable than Assembler, like Basic, or Pascal. XD But since the first things we are likely to want to do, is export code that is already in the game.exe or server.exe, and add to it (maps, levels, items, ages, file & data formats etc. etc.) and know that our DLL is isolated, and works just as it did when it was part of the main exe, before we port that code to a higher level language... Assembler is where I shall start.
Besides, most people here wanted to write in C# or VB.net when I mentioned importing DLLs, which is clearly not practical... you want C++ or C, I want Basic or Pascal (but I'm fine with C)...
x86 Assembler is one language we all have to be familiar with if we are even going to attempt this. If we are not comfortable with Assembler, Olly will be too meaningless to achieve the connections between our DLL and the main game. So x86 Assembler it is for Part 1.
What should be Part 2?
- Using DLLs written in a variety of other languages?
- Loading DLLs, and importing their functions dynamically? (using LoadLibrary() or LoadLibraryEx())
- Exporting functions and data from game.exe to a DLL?
I have some I've built in Dev-C++, (and they are C++, rather than C as well; interestingly) and some I've built in FreeBASIC, I'd like to have some in Free Pascal and maybe VB6, as that used to be popular here before MS went all .NET on us. XD
I can build BCB DLLs, but there's too little difference between that and Dev-C++ unless you use the VCL. (There's no point for PT I think) I don't have Delphi or Visual Studio, and don't see any reason to pollute my existing Development Environment (Borland / GNU) with MS nonsense. Lazarus is sufficient for my Pascal needs. :wink:
I have exported some sections with ease. I've Implemented most of the common KPTTrans code section patches in DLL form. I've written up patch code others have suggested putting in the exe as a DLL... but probably exporting all SQL functions in the server to a new PTSQL.dll that reads registry or ini configuration and doesn't need "hexing" and / or could be re-targeted at a different SQL database engine would be far more useful and interesting as a study.
If you're concerned with the client and the way it looks and feels on a users PC, then the LoadLibrary() routine, and a means of locking to specific DLL checksums would be far more useful to you. The ability to choose software, Direct3D or OpenGL as the rendering engine, setting volume levels and number of channels on sound, dynamic resolution and render (fog) distance all spring to mind and would make a great difference to performance vs. quality decisions for the users.
Each of these things needs discussing... but which should be given the greater priority for Part 2, I'm not yet sure... I hope the comments here will give me an idea of what people want most. Certainly, there is too much there to place in a single thread. No???
Re: [GUIDE] Adding Code to Client or Server via a DLL. (Part 1.)
i cannot download the GoASM, GoRC and GoLink..can you give me any other link? thank you..bobsobol
Re: [GUIDE] Adding Code to Client or Server via a DLL. (Part 1.)
Posted mirrors of the present releases using DepositFiles... hope that's okay for you rxaicy. :)
Re: [GUIDE] Adding Code to Client or Server via a DLL. (Part 1.)
i am so sorry ,bobsobol,i cannot download them from Deposit..can you use rapidshare? thank you very much..thank you.
Re: [GUIDE] Adding Code to Client or Server via a DLL. (Part 1.)
I'm afraid I can't / won't use RapidShare on principal... they won't let me upload any 1 file to more than 10 persons without me giving them much personal information and money. (That's uncalled for)
Please try these links, using hosts I know are popular among my Far East Asian friends.
Goasm.zip
Golink.zip
Gorcjorg.zip
GoASM
GoRC
GoLink
I also like http://uploading.com, http://www.zshare.net/, http://www.mediafire.com/ (thought they can mess you around long term moving their servers:(:), http://www.megaupload.com/ (though many people complain about the commercials on that one. I tried to use it from IE once and saw what they meant, but with my setup they all get filtered. XD)
Re: [GUIDE] Adding Code to Client or Server via a DLL. (Part 1.)
I was offline for the last weeks, only now I noticed..
this is so usefull and so interesting, I never had a clue how to add a dll to my server.
I think this is the most usefull guide in the tutorial section.
really thank you bobsbol.
Soon when my school tests will be finished I will work on that.
off topic: I've saw that UserName said that pristontale was writen in c++.
If I want to edit the client/server exe with C + + this is not possible in the current situation. What to do with the EXE? Need to convert it?
Sorry about the lack of knowledge on the subject, thanks.
Re: [GUIDE] Adding Code to Client or Server via a DLL. (Part 1.)
You need to buy the source code from Triglow. There is no way you are ever going to get C++ back from the exe, the compiler optimizer has destroyed the reversibility. Besides, you would struggle to understand C++ code with all the "formatting" removed. (new lines, indentation etc, not to mention code comments)
I've had several attempts at re-writing a complete client from scratch, using Olly as my template, and even from Assembler, it's clear that most of the code is C, not C++. C++ is used for the Component Object Model (DirectX and OLE) and very little else.
I don't "know" this because I've seen the source, I "smell" it in the library routines (part of the C runtime in all Visual C programs) which are, and are not called.
You can, of course, rename a C file CPP and it will still compile as C++... but it's still C code. XD
Re: [GUIDE] Adding Code to Client or Server via a DLL. (Part 1.)
Ok the how a c++ or c progrommar can help in the pristontale world?only build a launcher..
so c and c++ is useless for pt am I right?
and just wondering, triglow will sell the sources?and if they does you have any idea what is the range?just wondering.
thanks..