Questions

[chuckltn73]

Ok well, hrmmm call me crazy but i generally go with the simplest solution to a given problem, Richardo hit it on the head I believe it was and some others I think.

A simple check of a preassigned variable that only the server Op can change in the source. I think there was mention of using the variables table expansion field to this end.

I know I personally will impliment some kind of encryption, Ive already been Working on ClearLogin and the login packetmanager dll you included, well not much of work more of looking through and preparing to add the encryption and authentication.

I think there are many possibilities the serverOp could impliment, which would be the beauty of opensourcing it people would be able to share ideas, and at the same time be able to see what can work the best within those given ideas.

[chuckltn73]

Humm seems I can not edit my post;

On the subject of encryption I wanted to touch base a bit more in depth. Something like encryption should truly be left to the serverOp to deal with, for the very simple and important reason that, a global encryption system that is predistributed will very quickly undermine, said encryption. It would basicly defeat the purpose of adding the encryption if that encryption was distributed (Did that make any sense?)

[KLS]

Problem with that is the variable would be easy to work around for anyone competent enough to modify the client. Simply connect with the client you want to replicate to your own server see what version it sends to the server and put that secret version in a new version of your client: tada it now has replicated the secret key.

If you add a little basic encryption it makes it harder but not impossible to replicate.

client-> RequestConnection -> server 
server -> Reply (Including secret key for this connection) -> client
*figure out patches and stuff* if it's a SC patch then:
server -> Challenge -> client
client -> ChallengeReply: SecureHash(SecureHash(variable) + SecretKey)) -> server
server compares clients version to it's own internal hashed version and if they don't match disconnects.

That's pretty basic right there but would probably be enough. Would be harder to get the variable but not impossible because well the binary is in the hands of the enemy and he can simply decompile it to see what the key is, or they could potentially brute force it as well.

I think simple things like server side checks to see if players can do this or do that when they attempt to do something will cover most cases. Collision is the only real problem as it would be difficult to detect serverside. You could put a check in the movement code to see if someone is under the world and track how often it happens, if it happens a lot odds are there's a problem with your zone or someone is cheating. That wouldn't cover all cases though as there would be situations where people would be able to travel through small walls undetected.

One thing that might be an option is using a plugin type system for the various parts of the client, for example network is handled by a network.dll and ui is handled by ui.dll and various core mechanics handled by core.dll etc etc etc, would allow the release and modification of most the client while still keeping sensitive things tucked away in the main binary. Not sure how well that would work with your code though.

[chuckltn73]

Brilliant, KLS My compliments.

I agree completely, although I should have been a bit more clear, serverside check of the variables table, in other words the values would have to mach whats stored in the database. If it doesnt well then the client is automaticly kicked from the server.

One option for preventing decompilation is obfuscating it after compilation, but that would have to be something the serverOp does when he or she compiles the client.

I think if someone obfuscates their binary, modularizes the client as kls suggests, and also adds encryption it would probably be as secure as possible.

In truth since simpleclient comes with clearlogin, all the checks could be on via the loginserver with some simple modification. As for the cheating checks perhaps incorperating alot of the MQ additions to the recent servers would do the trick on alot of that, atleast untill SC is compatible with the most recent netcode if ever.

[chuckltn73]

A follow up:

the reason I said do these checks loginserver side is because, the ClearLogin is a small app and easy to edit, therefore it would be a small matter to enhance it with these sorts of changes, and would keep the emu server code basicly stock, so it would cut down on the editing the serverOp needs to do in order to get it up and running

[chuckltn73]

any chance of getting the right click look around working? would makle life alot simpler

[Darkriderone]

Well I have been interested in SC for some time, because it gives me a chance to design a world thats not based on Sony, doesn't require Eqclient in anyway and I don't have to make a copy eqserver 1001 of servers already out there.

I was joyed to be able to make new zones for people to explore, new mobs for people to see, there were enough really good eq-based servers out there. With SC I could have my own updater for files, and released new zones.

But in the end I respect Wind for the work and effort he has done with SC, I'm hoping to pitch in with help adding or pointing fixes or tweaks, and if he would like it to remain closed-source I'm willing to back him on that.

*wisper in wind's ear* opensource, opensource, opensource...

Sorry I'm no soultry siren...

[chuckltn73]

I completely agree, it is his project so in the end its his call, I personally hope the source is shared, but if not well thats his decision. As I understand it he does WANT to release it but is concerned about the cheating aspect, but I think alot of good ideas for combatting that particular issue have been shared so now we just got to wait for his word on it.

On a side note, guilds are a bit buggy with it but work with 0.6.0-dr2,Merchants dont seem to want to sell me anything on my server though, I get a message saying that item is only for display blah blah...

Other then that though aside from some small bugs/annoyances it works great. I for one am excited to see what kinds of new versions people would come up with if the source was opened.

Oh and hopefully *Crosses fingers* I should have a clearlogin with mysql authentication ready soon I am just having a few issues getting it to talk to mysql properly

[chuckltn73]

OH btw for anyone interested I have posted a link to a 0.6.0-dr2 setup of the server with database and the latest SC in the download links thread it works fine thusfar

[chuckltn73]

a small update:

I have gotten SC to work with 0.6.0-DR3, Im slowly working my way up the version tree to get it as close to 0.7.0-xxxx as possible

[Sorujan]

Well there I was, googling for an eq emulator and found this site, I read through the forums for a couple hours and came across this, After a couple more hours reading the wiki, I decided to download this client and setup a server and was playing with this client, I have to say AMAZING work to the developer(s) of this. You did a phenomenal job, It looks like a very early alpha to me but never the less outstanding job!

I have been reading through this thread, and felt that Maybe I could put in a couple cp. I think that this program being opensourced would be absolutly wonderful! Though I do understand the concern about cheating if it was, so here are my suggestions...

1) As has already been stated some form of a serverside check of the client version... ClearLogin seems like the best option for that, however doing it in the worldserver wouldnt be difficult either.

2) Make sure the licensing if an stipulates that the Developer / ServerOp Does not have to redistribute the source if they distribute their version of the client binaries.

3) Adding some form of an encryption layer to the packet that will send the version information to the server.

5) Impliment serverside checks on movement( As I understand it the .map files hold the line of sight information which would also have to hold information about walls and structures) E.G. Walking through walls, super speed. things of that nature... Also a serverside check on invisibility and whether or not the client has either a buff in place or the abbility to see invisible.

Now I have some suggestions:

A) Possibly a loading screen ( even just the splasy displayed when the client app first loads?) for zone transfers

B) Right click mouse look?

C)The abbility to say change the name of the client window.

D) Modularized GUI Styles( In other words the abbility to add new ui skins and choose from them(

E)Setting the client up to remember the Window possitions and allow the player to use tell windows and or add new chat windows for the various ingame chat channels

F) Last but certainly not least some eqemu users/devs getting together and getting some flavor of compatiblity with the 0.7.x server builds?

Anywho, those are my suggestions that I think havent been covered by others if so I appoligise for reposting them again.

[Sorujan]

Would it be possible for someone to explain how to say, change the classes, races, skills and so forth?

[chuckltn73]

Did you change the serverversions.ini file, it seems to hold the opcodes and text as well now?

[chuckltn73]

Ok so I made a zone in OZ 8.3 exported to xwa bsp tree and the client crashes whne i load in and walk around a bit I sent you a PM with the log from sc. Im wondering if 8.3 isnt compatible with sc? Or perhaps i should use octree?

[Sorujan]

Dont suppose we can get an update on whether or not sc source is going to be released?

Or some ETA on a new bugfix release or new release in general?