Apparently 2 months ago? https://github.com/npcdoom/eSRO
Printable View
Apparently 2 months ago? https://github.com/npcdoom/eSRO
Yes...so? it's incomplete, and most of us don't have the ability to finish it ^^
Looks pretty crappy to me. Just re-write it, even if it's incomplete. Shit's easy.
Do i hear a toilet flush ?
There are better ways to waste time with.
regards
rogan12
justin-mbp:eSRO justin$ git diff HEAD~1 --shortstatQuote:
Originally Posted by rogan12
628 files changed, 94506 insertions(+), 0 deletions(-)
There's not much here, and it's extremely over-verbose C++ since as I predicted when they were working on it, none of them has a clue how to write software, so really this is ~10-15k LOC done properly. That's tiny. Maybe a weekend at most.Code:Language files blank comment code
-------------------------------------------------------------------------------
C++ 231 11044 6751 36087
C/C++ Header 261 5005 7317 14280
It's still the best emulator written out there , I remember how were you wishing to have such a thing back then.Quote:
Originally Posted by jMerliN
Mine was significantly better architecturally, only I didn't have the time to sit there and reverse packets, so it was very incomplete. When I got back around to working on it a second time, so much had changed that the prospect of doing all the same work over again made it a non-starter. I have even less time today.Quote:
Originally Posted by ZiCO
The thing is, Eckoro is one of those people who would rather have a project fail miserably than collaborate and make something better. The end result is as I predicted it.
I hope you know that eckoro didn't take any real part in writing the actual emu except for gathering the packets.
Either way, weren't you the guy who wrote that vb6 emulator that is basically single player?
You should be more thankful for software like this. npcdoom wrote it a couple of years ago, basically on his own, I have yet to see anything that you released from all the things you told us (node.js epic emulator, oh mai gawdz!) I can inform you that npcdoom released this in public so that people can learn from it, and that people like you (if you didn't have this fucked up personality) would be able to help him finish it. Also, npcdoom recently (couple of months ago) started his second bachelor studies, in computer sciences, so give him a break on 'not knowing how to develop software' while he wrote this without any real "experience"
Either way, eSRO is obsolete, don't waste your time on it.
https://github.com/npcdoom/ZelosOnline is the latest version
The packets were the only thing that mattered. Even the worst "programmers" would be able to make something that somewhat worked given packet data, as is evidenced by every SRO project.Quote:
Originally Posted by yorick671
No.Quote:
Originally Posted by yorick671
It doesn't matter. I shouldn't be thankful for any of it. The only valuable thing in these projects is packet data. It would've been infinitely more useful to just publish raw packet breakdowns. Just about everything in this source is worst practices, and I feel sorry for anyone who thinks they could or should learn anything from it. My work on an emulator for the community was contingent on someone getting packet information -- something no one ever bothered contributing, not even npcdoom even though I asked him. It's incredible to see people defending code that should be wholly featured on thedailywtf.com.Quote:
Originally Posted by yorick671
This is even worse. Once again, the only valuable information present here is the packet data. He's slowly devolving to: https://github.com/Mikkeren/FizzBuzzEnterpriseEditionQuote:
Originally Posted by yorick671
It's also nice to see the lack of attribution: https://github.com/npcdoom/ZelosOnli...master/libauth
Almost everything in here follows the reversing pushedx and I did to support encrypted communication and to understand the encryption flags, but neither of us is mentioned. This is why the contract for any emulator work from me was that all packet information be provided, because to spend my time reversing for the community ends up with everyone using it without attribution anyway.
I hope you know that pushedx was closely involved in the making of this emulator, if you would have checked the original post (which is even on this very forum) you would have seen that pushedx is credited, plus everybody else involved.
I find your attitude very disrespectful against people that actually try to help, while you have done nothing for this community at all, and are even too lazy to gather your own packets (do we really need to spoonfeed you information before you are able to make something decent? Take a look at pushedx, he knows that he has to do everything himself, and he will do it without hesitation). Either way, the complete packet archive is in the hands of most people (that can use it) in the sro community, I wonder why nobody has given you a copy :wink:
anyway, this is a pointless discussion. Either you help npcdoom out with his emulator, or you start writing your own epic 9001 l33t emulator, there is no real need to keep showing your "superiority" and gigantic ego (we all know you need to use 2 empty elevators to reach the top of a building) while nobody actually cares and while you can start doing something constructive with your time. We'll even help you out, as long as you show some respect
Doubtful. Also, he did not credit everyone, and there's a difference between crediting on a forum nobody will ever visit and on the source repository itself.Quote:
Originally Posted by yorick671
There's a reason we don't have a single decent emulator even to this day.Quote:
Originally Posted by yorick671
Respect is earned, not assumed. If the community wants to continue backing amateurs that don't know how to write software, so be it. Again, not a single decent emulator exists. Why might that be?Quote:
Originally Posted by yorick671
Wow, this code is far worse than I gathered from a cursory glance. This belongs on TDWTF for sure. It's as if someone convinced npcdoom that having more daemons implies scalability, stability, quality, or any other useful metric. Yet it has 0 tests, 0 linting, and no metrics to measure performance which is always step #1 when you have a performance problem.
So much code is repeated all over the place. So much completely useless boilerplate. Unnecessary interfaces and abstraction. There seems to be a goal of keeping every file below some arbitrary file size limit, so things are unnecessarily spread around. About 65% of the code in the project is dedicated to dealing with inter-daemon communication, and that's done using some unnecessary handshaking, and then there's this complicated mess of state management and setting things up to appear to be evented rather than just using something like libev. The SSH protocol solved the security problems this attempts to solve a LONG time ago and much more elegantly -- if this multiplicity approach is desired, using libssh would've been SO much better. Although the abuse of OOP here wouldn't have meant that would've made much of an impact even though conceptually the idea would be drastically simpler (and much more secure). In reality, the daemons are split into their own projects/executables, and unnecessary packaging of not-necessarily-shared code into libs is happening. Really, nothing about this is even reasonable, and splitting things into daemons doesn't improve scalability at all, and has a net detrimental effect to system stability as evidenced by literally every cloud project ever made, ever.
Not to mention what's posted of ZelosOnline is, even with an absurdly unnecessary amount of complication, less complete than the original VB6 SREmu. eSRO is both significantly better in design (although far from "good") and substantially more complete. This "more advanced" project is wholly useless and will only confuse anyone. As a summary of what it is: it's basically a gigantic pile of unnecessary C++ trying to shoehorn ideas solved long ago in elegant and stable projects into abstract template-happy boost-loving misguided implementations. Done in C with the use of existing libraries and using a forking strategy over unnecessarily building N daemons, this would be about 1/10th the size and be much more stable.
As it stands, this code base is significantly trending towards an evented system and does a lot of unnecessary work to try and serialize anything responding to user actions but does so in a very rudimentary and naive manner. At the end of the day, what npcdoom is trying to implement here is something like an evented I/O framework like libuv + a layer of abstraction that would make it akin to Node.js or Twisted while being wholly inadequate in comparison given that both of these have rich and powerful runtimes available. Hence, I still believe as I did when I said I'd write an emulator, that an emulator in Node.js would be significantly simpler than any that anyone has ever made while being trivially made to outperform them all.
My old JS emulator built before Node existed had users in-game and running around able to spawn monsters and kill them in about 800 lines of code, and it was extremely simple to read and extend. I will still maintain my agreement with the community. Pick a client, provide me with up-to-date packet information, and I'll make an open source emulator that's completely functional, under the MIT license, not the AGPL, so anyone can use it for anything.
If you choose to believe that my making such an offer to the community at large is indicative of an attitude problem, then I must wish you good luck in finding a professional engineer who is both willing to and capable of building such a thing.
As for Eckoro's statements regarding packet gathering: what Eckoro did is largely based on the initial work done by people working on SREmu and doing a LOT of reversing work in the client, followed by pushedx using that and extending it a lot towards building proxies that would also identify calls to reading and writing utility functions used by SRO (things like pkt->readByte() or pkt->writeByte(), etc). With this, much like utilities we built to parse packets for SREmu, but made public, Eckoro managed to log most packets and spend enough time guessing to decode most of what was going on. The problem is that this isn't sustainable. Why isn't any emulator, PERIOD, up to date with any client release? It should be trivial to keep up to date within a week or month of releases -- why not? Because it's almost impossible to track down packet changes when you've reversed them from data. What Eckoro did was a lot of busy work, and that's fine, but it's only valid work for a given version frozen in time. What I planned to do (but didn't and still don't have the time for) was to build a basic framework for programmatic debugging and checksumming that would result in a tool that could allow a reverser to reverse individual packet building/parsing sites, do dataflow analysis to trace where data ends up within in-memory structures, and to mark code paths as completed to get an idea of packet coverage, and maintain this by checksums of basic blocks. When a client update happened, beyond doing basic things like re-running parsing tools on PK2 text resources to update the emulator, one would simply load the tool on the new client and see if any basic blocks involved in packet building/parsing have changed. If so, you get a nice display of those modified blocks in red and a new readout of packet coverage, and all you have to do is do a minimal amount of reversing to update the emulator to the latest version (something like a few hours, worst case, for any capable reverse engineer). This tool would take at least a few months to get working well and right, but would be usable on any game (not just SRO), which is why it'd still be a valuable tool to build, and I may get around to it one day but I'm far too busy these days. In absence of such a tool, the task of gathering packet information for an up to date version isn't a task someone can fully achieve in their spare time while building an emulator that is 100% functional. This is why I asked the community for packet data.
The time I have is spare time. I've made an agreement to build the emulator which appears to be what nobody else has ever been able to do, as that can be done in spare time since it follows a traditional software development cycle. If supported with packet data, the result would be something that could literally run on current clients and would be better in every way than the real servers. If no one is willing to share, then providing for this community isn't something worth my time, so I will continue to not build anything. If one day I get around to finishing my dataflow analysis and programmatic debugging engine, I might do it myself, but the odds of that being within even the next 5 years are extremely unlikely.
Hmmm.... the problem is, to build a perfect emulator, you need commitment. And since the sro industry is dieing, very slowly but dieing... i guess it is a waste of time to re-make an emulator from scratch!
I was part of Aion-Unique Emulator, the first aion emulator "the one every server is using atm", and it took amazing amount of commitment, and in the end they shutdown the project :S meh! Its why it is hard for me personally to get involved in emulators :P although i would of loved making a java or c# emulator :P
You are totally right, i've plans to get all developers together (xsense, jmerlin, pushedx, evestu and more) and make from scratch but i don't know which one will accept or decline it.Quote:
Originally Posted by Jangan
so jMerlin can consider it as an offer, i belive when i get 2-3 of them together others will accept too.
off topic:
may i get your skype Jangan? Thanks.
I hope you know that xsense and evestu's skillset isn't even close to that of jmerlin and pushedx. Either way, a project like this is way too complicated for a team on the current sro "level", and while pushedx has currently left sro, I guess jMerlin has to work on it on his own (and that is probably what he desires).Quote:
Originally Posted by RevoLand
While I don't agree with every point he makes, I'd love to see a working emulator for silkroad, but I doubt the MIT license would be the way to go (if you see how greedy silkroad has become), I doubt even anybody would care about the license lol.
--
I talked with pushedx about your last emulator jmerlin, and he told me you had actual skill, so I will trust him on his word, but I'll have to see it before I believe it.
If you have a rough concept of how you are planning on starting this, I'm sure we can arrange you a copy of the packet archive
EDIT: RevoLand, please refrain from deleting my posts that actually bring value into the discussion. You are not the one to teach me about respect if you give me warning messages like this:
http://gyazo.com/410d217895d5ea9df16...png?1364227678
Next time, try to respect your fellow gaming communities, and don't interupt real interesting discussions with your logicless plans to conquer the sro scene (xsense & evestu epic c0d3rz 1337)
(if you plan on deleting this post too, I'm seriously gonna lol)
No one tells their knowledge are same also we are not discussing about their knowledges in there.Quote:
Originally Posted by yorick671
No one can refuse an offer to organized & team based project, i heard about pushedx but never meet him. As i heard about him he will not refuse it. (at least if he is not working on something else)Quote:
Originally Posted by yorick671
You're right about that part but i don't think it will be open-source until all team members accept it to be open-source, it must be team-call and will be.Quote:
Originally Posted by yorick671
I still think i did a right call but if you think it wasn't you are free to talk about it with a super moderator and if he / she decides i did a wrong call then i will be more careful.Quote:
Originally Posted by yorick671
As a moderator we don't have rights to delete posts randomly.Quote:
Originally Posted by yorick671
Thanks for your attention to this thread.
lol'dQuote:
Originally Posted by RevoLand
I already have an idea. It's pretty simple. A single library that packages all of the features needed to build an emulator in Node (https://github.com/just2n/mmo.js) and then a simple application (https://github.com/just2n/silkroad.js) that uses that library but acts primarily as an adapter from the game-specific concepts to use of the mmo library (such as encryption, handshaking, then packet encoding/decoding to fire events into the mmo library).Quote:
Originally Posted by yorick671
Framework for reverse individual packet is really great idea for reversers in any kind of application that sends packets in Server/Client or P2P methods.Quote:
Originally Posted by jMerliN
The question is, are you really want to do that for community?
Tree (data structure) - Wikipedia, the free encyclopediaQuote:
Originally Posted by jMerliN
:D i never liked nodes... and i also hate gathering packets.. but oh well :P new adventures are fun!
merlin... i think you are hinting that you want to start an emulator... what language + framework are you planning to use? I'd love to build the database/designs + stored procedures/functions + connections and others!
//// Off:topic -- i built a pretty intense combat script "automatives/bots/whatever" for another community while i was bored long time ago i Java - used nodes and other stuff but here to look:
https://github.com/RealCombat/RealCo...ee/master/V0.9
Code:for (Node n : nodeList) {
if (n.activate()) {
System.out.println("Activating: " + n.toString());
n.execute();
Task.sleep(100);
break;
}
}
read the post you just quotedQuote:
Originally Posted by Jangan
You do realize that your reply is useless right?Quote:
Originally Posted by yorick671
So where's this packet stuff?Quote:
Originally Posted by yorick671
Still hwaiting...
hmm, i might be confused or possible right...
an idea: i believe microsoft wrote a code somewhere about a client/server connection system, and if i remember right, the server side, reads all kind of data , and send it back to the client..
Now i am thinking, why not just setup a read server, where silkroad tried to connect to the server, by connecting it sends specific packets, where the server will read those packets, save them to a file, then close/decline the connection.
I think this way is good to just keep reading packets and figuring out what they are for, trial and error kind of thing..
-------------------------------------------
2 Possible Problems:
-----------------
1) Not sure if the packets are encrypted, not even sure what kind of encryption they are in, not sure if my method will work.
2) If my method works, there is still a problem with sending back the right packets/commands to the client in order to move on forward. Because this method is suppose to just read incoming packets, and no idea how to figure out what are the outgoing packets.
Forgive me, i am not an expert networker, so i do not 100% understand client/server connections and protocols.
/edit/
https://gist.github.com/leandrosilva/656054
- Found the code.
Much of what I'm about to say came from a time when I had a near infinite amount of free time, followed sharply by a period of 0 free time, followed by my near 0 free time today, which is why I never finished my emulator (primarily because gathering packets is a huge time investment that almost requires a dedicated person because we didn't build good enough tools).
The packets are encrypted. Much of the initial days of building emulators was similar to that. We started by analyzing the first few packets only to realize that some of them were horribly encrypted (before they added the DH handshake).
Then, as with all reversing, it was a quick PEiD to find that there was blowfish and some other encryption. So a few breakpoints and a few minutes of stepping later, followed by a copy of a reference implementation, and you had a server that could encrypt/decrypt packets (the client never expected encrypted packets, they were flagged by a 0x8000 mask on the packet size field, effectively limiting any possible packet length to 0x7FFF bytes).
So then that let client proxies decrypt packets on the fly and spit them all to disk, as well as the server to echo all packets it received with timestamps to disk. Then packets were replayed initially, and slowly disassembled for information. For instance, you'd get a server list packet and see some text that was obviously the name of a server, but there was other stuff you didn't know about, so you'd replay anything you didn't understand and update what you did. This eventually got us in-game. There are a lot of packets and some packets have a lot of fields, while others have encrypted or very awkward values that make no sense to a person looking at it from the outside but all the sense in the world from the internal workings of the game with how it renders geometry and determines your location in the world (talking about big blocks of landscape, not just X/Y/Z coords). Then there's a lot to parse.
It didn't help that they confused things more with some nonsensically stupid multi-packet packets that can "package" multiple packets together (... because.. that makes sense, it's really a clear sign that the engineers had no understanding of TCP/IP or streaming), or that they actually changed the initial encryption, breaking everything, and that every server locale had its own different opcode values, meaning efforts in csro/tsro/ksro to reverse their packets were confused with isro in that nobody knew which packets were the same.
Around that time, cls, myself, pushedx, and a few other (more independent developers, primarily the guys behind rev6 and cw who was doing 0x33) were starting to get more into reverse engineering the client itself since packet sniffing was too slow and error prone, and with the client updating, we had to have a more robust way of finding packet information, and because they just changed the login encryption so our proxies and client bots were broken on the real servers, and the new clients didn't like our old packets so they'd get an exception and crash. So either we kept using old client versions or we'd have to break into the client and figure things out -- which is what we wanted. This was at 60 cap, back when new things were being added like dw cave and cap 70, and we really wanted this new stuff, we were not satisfied with working on some ancient version of the game with 60 cap and 0 content while the game was moving ahead.
So I, while still learning how to reverse engineer, took a stab at the new encryption stuff. Others worked on better tools. cls and pushedx were working hardcore on packet logging tools and reversing their packet functions (on older versions of the client, but it worked fine on the new client, too). cw was working on hacking the bots and starting softmod (I suspect he made a lot of money doing it, too). It's easier to crack a bot than it is to build a bot, typically, so that's smart.
I reversed a good chunk of the auth code into some ugly C that did work. I didn't complete the reversing, but I provided this to others. pushedx finished the reversing where I had left off, which is why you see me credited in the authing code in emus that is still being used today. The tools we then had prior worked by just dumping what was seen in send/recv hooks. pushedx and cls improved this significantly by reversing where the data went after a recv call and where the data came from in a send call. This resulted in packet serialization/deserialization functions that were then hooked and permitted output logs to include the precise size of each field in each packet, which made it significantly simpler to guess what each field was doing. This is when Eckoro got involved and used those tools to reverse most of the packets -- it was time consuming and tedious, and much of the sremu team was busy in school or with jobs, so we had already lost the time needed to apply those tools and get information. Others besides Eckoro had already done this work, and others since have done this work, but nobody has ever publicly released it.
The problem was, in hindsight, that our tools were one generation too immature to have been imminently useful. pushedx worked a lot more on PK2 things, did some interesting work elsewhere, but nobody really advanced the state of packet reversing tools, which was essential to gathering the information. The only subsequent work done was to locate individual packet serialization/deserialization blocks (such as the code that would completely deserialize a character data packet, or the code that would serialize a create character packet). This meant you could open up IDA and reverse that code, but you had 0 context, which made it very difficult unless you attached a breakpoint and actually stepped through it.
A few years ago (this being many years after I stopped working on SRO related stuff), I decided, with a lot more knowledge, to learn more about reverse engineering, especially theoretical techniques used in malware analysis, code quality testing, and automated debugging. What I learned literally revolutionized how I thought about reversing, and it wasn't anything new, it was just the first time such information was so easily available (a lot of papers on the subjects are available on ACM from way before we ever did SRO things, and tools that did instrumentation and dynamic dataflow and branch analysis were long since available, too).
What we needed to do was make one more iteration. A programmatic debugging framework would've made it very simple to have automated much of the reverse engineering tasks (which were mostly the same), and could provide snapshots of live data for dead code analysis, providing you with a context, which meant you could play the game, capture information, then without loading the game and dealing with disconnecting, etc, just step through the code as it actually happened in a live replay. Another concept was dataflow analysis, in which you literally programmatically step through the code and watch how data moves between registers and memory. You start by marking the data you want to watch in a packet as dirty. We'd start with one field, mark all of the bits of that field (say 8 bits for a 1 byte field) as dirty. Now anything that ever assumes that value becomes marked. You mark all basic blocks that touch that data, and all memory addresses which hold that data. Then later, you can harvest that information by overlaying the hot blocks on top of a dead code listing (say in IDA) to see what code actually touched that data. You'd see immediately in the deserialization code what touched it, which would make it very obvious if it was a flag, a single value, etc. If it was a flag about how to process data in the packet, it would be immediately clear by some form of bitwise operations and conditionals based on them. If it was a flag used by the client to determine something (like are you a GM?), it would show up being stored in client state at some address, and being accessed by code and tested conditionally when you did something (like try to open the GM console). This would immediately tell you WHAT it did, where that state was stored in the client, and which byte in what packet stored the original data. Then one simply has to go through this information, which is a lot more data than you had with 0 context, and flag each byte as 'reversed', along with providing ample notes on what it did.
Then, once every byte of every packet has been analyzed, your logs would be clean, as the tool would never see anything it didn't already know. But as soon as a client update comes out, and a new field is added to a packet, for example, the code paths would change, basic block checksums wouldn't, but the new field would be realized as unknown and fields displaced within the packet or that have had their basic blocks modified would be marked as dirty. The reverser then has essentially a very relevant diff of what changed that they need to actually reverse. So a few minutes later, they finish the reversing, and everything is marked as reversed again, the server/bot code is updated to reflect the changes, and things are done.
That's what we SHOULD have done, but I suspect none of us knew enough at the time to actually do it. While I could do it now, I don't have the time to build something like that. An emulator, though, would be pretty simple to build.