The story behind the signature...One ST0 to rule them all? One PE viewer to find them!
One ST_kRO to bring them all and in the darkness bind them...
Mount Doom awaits us, fellowship of OpenKore!
The signature is really about the dream of a unified network system based on kLab's packet cstruct research.
What follows next is the path of me learning from the design of me and others concerning the networking code in kore...
So why, you ask?
Well its simple, survival of the fittest. Being able to adapt to environment or in this case, different servertypes is important to the survival of kore. An unified network system would allow us to support all ST and network modes with much less work, so we could focus on the real important things like AI.
OMG IT DOESN'T WORK!
It all started a few years ago when I tried botting on the latest kRO RE and it did not work. (latest pserver's using RE didn't either using the ST8_01234 ST's)
There, I fixed it
So I started questioning the existence of ST8_01234 etc... and ended up implementing the entire kRO ST as some sort of "timeline" characteristical thingy instead.
A million ST's
The problem was, there were now "a million" kRO ST's and no way to find which one the user should use.
Luckily kLab came up with the awesome PE Viewer solution of being able to find the compilation date of the exe.
Fix one server, break the others...
Since servertypes really have a "timeline" characteristic I began questioning the existence of ST0.
It made no sense to me to make changes in ST0 for one server like bRO and break the support for the other official servers. (which happened regulary)
Fix one server, it has no effect on others?
So the bRO, iRO, etc serverTypes were born where one could make changes in first and finally port to ST0 if all officials were using it. (I still do not condone making changes in ST0 (which I feel to be something like the forever static Sakexe_0) tho, I feel it to be bad design, as testing on all officials is "impossible")
Fix one server, help the others
As we gave the official server supporters the power and responsability to maintain their own tables subfolder without affecting others, so should they also be able to maintain the packets their server is using without affecting others.
However, still at the same time be able to contribute new stuff to be implemented in the future to other servertypes or use stuff already implemented in other static (in time) servertypes. (You know, like everyone copy-pasted "my" solution to en/de-crypting the password in AES rijndael in the login packet I made for the official kRO, kudo's to kLab for the research)
Something like ST0, but not quite the same
But, as you all know actually copy pasting is bad practice. The need for code reuse made me believe that it would be better to base all other servertypes on the kRO ST, which implements new features first. (It grows but once implemented correctly, remains static going backwards in time)
Downfall of current kRO ST design
However, the current downfall with the way we handle the kRO "timeline"-ish ST is that patches to the kRO client might be applied differently to other official clients, so we can't simple inherit in ex. bRO from a specific kRO implemented in kore.
What we need is to be able to share the things that are mutual, while having the ability to separate what is different. All this ofcourse, in a highly configurable fashion.
So a redesign of the whole thing is needed, for the cause of removing the need for copy pasted redundant code.
Manifesto of the unified packet (un)packer servertype network design:
(1) All servertypes should share the same packet cstruct information (ex. a shared table file containing every existing packet struct) where they pick the ones they need from. (so no more copy pasting of subs and (un)pack strings to other ST's required)
And they should use different table files telling kore, which packets to pick from the shared file, the functions of the packets (for xkore etc) and the packetswitches for these packets.
(2) The system should be able to parse & construct both sent & received packets of static & dynamic length (possibly with nesting).
(note: you need the other way around too, because in xkore2 mode, client-sent packets are sent to you) ("in mother russia" joke not intended)
Prove your concept!
This idea was floating around a long time ago and I decided to implement some raw proof of concept plugin.
It parsed kLab's cstruct.txt file and created pack/unpack objects that were capable of (2).
I actually discovered the use of unit tests doing the first implementation of this outside of kore before making it a plugin.
The plugin would only dump every received packet in unpacked form using Data::Dumper to a text file which could be read using text editors named "less" or "more" or any text editor that could handle binary stuff.
Its available in tester's corner but prolly broken now, due to recent changes.
(I know that the parser code is hella ugly, but it worked. I now realize that what I really needed was top-down parsing with bottom-up (un)pack object creation. Well thats what you get from trying to solve a problem with regex'es)
Time is my enemy
I never got around to extend it with (1) and finish the plan of implementing it as THE sole packet (un)packer for normal & xkore network connection modes.
Beware, there be DRAGOONS!!! You shall not pass!
So yea, one does not simply walk into Mordor I suppose...
So thats the story behind the signature.
Beyond...
Apparently a basic packet reconstruction mechanism was already present in kore all along! (yea, big codebase, lots of non-timeproof code (read: quick hacks), a bit unstructured, not much documentation)
A hero approaches
But then EternalHarvest came around and did an awesome job!
He re-coded parts of the xkore's to use the packet reconstruction thingy and made it possible to use unpack strings to pack packets. With this he extended the lifetime of the xkore modes and removed a lot of old cruft from kore. From a quick code review I also noticed he removed a lot of redundant code, which is also nice.
So same idea, different implementation. (different path to mount doom)
The mount doom reference ofcourse stands for the destroying of ST0 and all ST as we know it.
Because, we should not let any part of kore have control over how we should code, but instead build something that we have control over.
Looks like the fellowship of openkore is well on its way again
Now I wish that I could dedicate more time into kore, cause then you'd have my sword.
Wow this should have really been a blogpost or something...
ps: LOTR is awesome
haha
