[Download] Tibianic DLL Sources (Client Injection)

dranskr

New Member
Joined
Aug 11, 2015
Messages
7
Best answers
0
Reaction score
0
I don't think bro that's why i suggested to uninstall, re-download and install all over again.
Being carefully on what you write in the lib part etc
I did just that using devcpp from the topic but the error is still the same, I really don't know what happens
 

kay

Veteran OT User
Joined
Apr 23, 2013
Messages
346
Best answers
1
Reaction score
386
You may want to use Orwell's Dev-Cpp instead. The one you're using hasn't been updated for 15 years and comes with old MinGW.
 

Felipe93

Ghost Member
Joined
Mar 21, 2015
Messages
1,567
Best answers
9
Reaction score
237
Location
Chile
You may want to use Orwell's Dev-Cpp instead. The one you're using hasn't been updated for 15 years and comes with old MinGW.
I did just that using devcpp from the topic but the error is still the same, I really don't know what happens
I'm using the one from here without problem at all and most of the users too
 

dranskr

New Member
Joined
Aug 11, 2015
Messages
7
Best answers
0
Reaction score
0
You may want to use Orwell's Dev-Cpp instead. The one you're using hasn't been updated for 15 years and comes with old MinGW.
I tried with this other Devcpp but this error happens now, I don't know if it's just here that doesn't work
1575585081286.png
 

fabian766

Active Member
Joined
Apr 22, 2008
Messages
59
Best answers
8
Reaction score
48
Location
Poland
I tried with this other Devcpp but this error happens now, I don't know if it's just here that doesn't work
As the error tells you, you don't have libboost installed.
About errors on the other dev-c++ you didn't even make screenshot of the error(warnings aren't errors).

About this .dll I don't recommend to use it because it has a lot of bugs and author(iryont?) don't even understand calling conventions so after some time client will get crashed by stack overflow because the stack memory aren't getting cleaned as should(it produces undefined behaviors like what happens with drawing skulls too) or code that depends on asm calls which can be fucked up by compiler because asm should be used to write whole functions not only parts of them.
 

kay

Veteran OT User
Joined
Apr 23, 2013
Messages
346
Best answers
1
Reaction score
386
I'm using the one from here without problem at all and most of the users too
I didn't mean it would necessairly fix that specific problem (there are only some warnings we can see), but in my opinion it's better to use that version overall. Of course, unless you have a reason why you'd want to use to the old one.

@dranskr
You did not install the libs, there's error including them "so such file or directory".
 

Iryont

medivia.online
Joined
Jun 11, 2008
Messages
284
Best answers
0
Reaction score
114
About this .dll I don't recommend to use it because it has a lot of bugs and author(iryont?) don't even understand calling conventions so after some time client will get crashed by stack overflow because the stack memory aren't getting cleaned as should(it produces undefined behaviors like what happens with drawing skulls too) or code that depends on asm calls which can be fucked up by compiler because asm should be used to write whole functions not only parts of them.
I do not recommend using it either, but perhaps instead of flaming someone's work which you don't even understand you should think about it more. It never cease to amaze me how people such as yourself try to act like they know how it was actually created in the first place and for what purpose.

That being the case, this library is probably 6-8 years old by now and it was created for specific compiler with specific flags and so on. Compiling it with a different compiler and different flags as I used back then is just asking for issues as obviously there is a lot of assembler going on which purely depend on the current compiler and how it compiles a specific function. Anyway, even though it was so many years ago I do clearly remember inspecting every function after compilation to see if new assembler was properly injected into it. Also, the executable was modified a lot to work properly with the library and its functions.

Long story short - just don't use it unless you know what you are doing with it. I never released it myself and it should have just been a piece of history rather than something to use nowadays.
 

fabian766

Active Member
Joined
Apr 22, 2008
Messages
59
Best answers
8
Reaction score
48
Location
Poland
I do not recommend using it either, but perhaps instead of flaming someone's work which you don't even understand you should think about it more. It never cease to amaze me how people such as yourself try to act like they know how it was actually created in the first place and for what purpose.
Okay, sorry for hurting your ego and I guess from today critique bad code design is flaming or maybe even "hate speech"? I know that the code is old but it doesn't change matter that there were already calling conventions that would make things easier without rellying on asm functions that can break your code simply because that asm code changes registers which can be accessed already by compiler and can be changed to 0(for example if the compiler emits "xor ecx, ecx" at the epilog for HookedParsePacketSwitch function it'll break it entirely and there's 50% possibility for that because you have if statements that checks for 0 so compiler will save it on epilog for ecx or edx register). About part where you said "which you don't even understand" so only you can understand your code because you write it?

So to summary: I'm only wanted people to know about bad code design(so they know that it can fail because of it(especially on mingw with optimizations enabled)) not to start flame war with you.
 

Iryont

medivia.online
Joined
Jun 11, 2008
Messages
284
Best answers
0
Reaction score
114
Okay, sorry for hurting your ego and I guess from today critique bad code design is flaming or maybe even "hate speech"?
You didn't hurt my ego as I have nothing to prove here. However, as you have called me out by saying that I didn't understand calling conventions back then (which would be really odd for anyone who understands asm, but somehow doesn't understand how C++ code is compiled into asm) I felt obligated to respond.

simply because that asm code changes registers which can be accessed already by compiler and can be changed to 0(for example if the compiler emits "xor ecx, ecx" at the epilog for HookedParsePacketSwitch function it'll break it entirely and there's 50% possibility for that because you have if statements that checks for 0 so compiler will save it on epilog for ecx or edx register)
That is precisely what I just said about compiler in my previous post. At the time my compiler for this library didn't emit e.g. xor ecx, ecx which clears ecx and therefore it becomes invalid, but as we can see from this thread it is happening to some and so on. There are probably countless of other issues which will arise depending on the compiler and its flags.

About part where you said "which you don't even understand" so only you can understand your code because you write it?
No, but I do understand why it was made like that more than anyone else at this point. I was more than happy to make it clear that this library is just something to look at, but it's definitely not wise to use it.

So to summary: I'm only wanted people to know about bad code design(so they know that it can fail because of it(especially on mingw with optimizations enabled)) not to start flame war with you.
That is actually a fact which I believe everyone here knows about. Honestly, I would never try to defend this code as it is simply bad, but I knew exactly what I was doing back then. It served its purpose for a while and was simply dropped.
 

fabian766

Active Member
Joined
Apr 22, 2008
Messages
59
Best answers
8
Reaction score
48
Location
Poland
You didn't hurt my ego as I have nothing to prove here. However, as you have called me out by saying that I didn't understand calling conventions back then (which would be really odd for anyone who understands asm, but somehow doesn't understand how C++ code is compiled into asm) I felt obligated to respond.
About you not understanding calling conventions it's just that functions HookedSetExperience and HookedPushLetter have __stdcall instead of __cdecl but I don't know if this is your doing or just someone edited it because there's /*_cdecl */ infront of them(or maybe you corrected it inside your client.exe). The other function that have different calling convention that should have is AddContextMenu because it have __cdecl and the real convention is __thiscall so it should be declared as __stdcall or __fastcall which allows you to access ecx and edx registers directly from c++ code(that is probably the reason for commenting //HookAsmCall(ADD_CONTEXT_MENU_EX_CALL_SET_OUTFIT_FUNCTION_ADDRESS, (DWORD)&HookedAddSetOutfitContextMenu);). So as you can see my words aren't empty but I don't know either if it's your fucks up or someone after you made it, anyway I understand what you wanted to achieve with asm calls but they are simply broken.
A little example what happens to pushRegisters when compiled:

as you can see it become empty and that is because this function get's called from asm function and the compiler simple don't understand them that much so it assumed that function is never actually called, so function HookedOnPushEvent is broken too for custom events because of that. So with that about 50% new features you added doesn't even work but it could still be used to have cam recorder and client updater. It is my last post in this thread so don't worry you don't need to answer me anymore.
 

Iryont

medivia.online
Joined
Jun 11, 2008
Messages
284
Best answers
0
Reaction score
114
About you not understanding calling conventions it's just that functions HookedSetExperience and HookedPushLetter have __stdcall instead of __cdecl but I don't know if this is your doing or just someone edited it because there's /*_cdecl */ infront of them(or maybe you corrected it inside your client.exe). The other function that have different calling convention that should have is AddContextMenu because it have __cdecl and the real convention is __thiscall so it should be declared as __stdcall or __fastcall which allows you to access ecx and edx registers directly from c++ code(that is probably the reason for commenting //HookAsmCall(ADD_CONTEXT_MENU_EX_CALL_SET_OUTFIT_FUNCTION_ADDRESS, (DWORD)&HookedAddSetOutfitContextMenu);). So as you can see my words aren't empty but I don't know either if it's your fucks up or someone after you made it, anyway I understand what you wanted to achieve with asm calls but they are simply broken.
I do agree with you, but as I have mentioned, some functions were heavily changed in the executable as well and this is not even the exact code I wrote back then.

I took the liberty of looking at first post with a link to github and there are added calling conventions which I didn't even add myself. As far as I remember the default calling convention for MinGW which I used back then was cdecl, so HookedSetExperience was actually supposed to be cdecl as well, but somehow it became stdcall with cdecl being commented out...

as you can see it become empty and that is because this function get's called from asm function and the compiler simple don't understand them that much so it assumed that function is never actually called, so function HookedOnPushEvent is broken too for custom events because of that. So with that about 50% new features you added doesn't even work but it could still be used to have cam recorder and client updater. It is my last post in this thread so don't worry you don't need to answer me anymore.
I'm not really sure what are you trying to prove here. It looks to me like you are implying that somehow 50% of new features I added to Tibianic back then didn't work, but they did just fine, so let it sink for a while and think about it. What is more likely to you, someone messing around with the sources to make it work with random ideas popping in his mind or me writing a code for my own server back then which apparently didn't work and I just did it so players could enjoy the luxury of memory leaks and crashes during playtime?

The fact is that someone took that library, messed around with the sources, compiled with it some random compiler and commented half of the stuff there to make it work. That is not something I did myself, so keep that in mind.
 

danne3131

Active Member
Joined
Jun 26, 2008
Messages
387
Best answers
1
Reaction score
39
@Iryont, you do not have to defend yourself.
You've proven that much is possible in this community, also contributed overtime.
Dont waste your time on these energy extinguishers out here, there are alot..
Cheers
 
Top