Jump to content

New Best Security All Java Servers!


Recommended Posts

Security is done by modifying the server core and client Engine.dll. That itself makes it worthless to buy it, sorry.

 

If you want real protection you should implement a packet clouding and you are ready to go, also its lightweight, doesnt need client modifications(which are suck bad in so many ways), and you dont -beep- your core up instead you improve the code along with it.

 

You mind explaining your near lunatic approach to security without having a secured clientside change to the stan?dard algorhythms

 

Wtf is packet clouding?

 

 

 

Or was this just some attack on the creator for whatever reason?

Link to comment
Share on other sites

You mind explaining your near lunatic approach to security without having a secured clientside change to the stan?dard algorhythms

 

Wtf is packet clouding?

 

 

 

Or was this just some attack on the creator for whatever reason?

 

Leave him mate, he is in his own world of L2J MXC Dev Team, )

Link to comment
Share on other sites

Packet clouding aka packet obfuscation makes it harder(near impossible with current tools) to identify the packets. In other words it hides the meaning of the packet and because of the fact that its implemented along with the protocal version, everything that tries to connect to your server(doesnt matter if its client, bot or program that simulates the login process) get disconnected because in order to connect, your client that connects to the server needs to support obfuscation too.

 

In the simplest way it makes the packet traffic confusing to external clients that does not support obfuscation, which is everything except your lineage client.

Link to comment
Share on other sites

Packet clouding aka packet obfuscation makes it harder(near impossible with current tools) to identify the packets. In other words it hides the meaning of the packet and because of the fact that its implemented along with the protocal version, everything that tries to connect to your server(doesnt matter if its client, bot ot program that simulates the login process) get disconnected because in order to connect, your client that connects to the server needs to support obfuscation too.

 

In the simplest way it makes the packet traffic confusing to external clients that does not support obfuscation, which is everything except your lineage client.

 

It's better to use an Updater, so you can change the protocal all the time.

Link to comment
Share on other sites

It's better to use an Updater, so you can change the protocal all the time.

 

No its not because its easy to always get the new protocol of your client(you need to publish it in some way to let people connect so they just connect to a different protocol and cheating works again.

Link to comment
Share on other sites

No its not because its easy to always get the new protocol of your client(you need to publish it in some way to let people connect so they just connect to a different protocol and cheating works again.

 

Obfuscation requires new way of calculting opcodes for packets, aka intervening in client aka a client extension.

 

 

Any change of blowfish or standard RSA keys in client\server - is easily bypasseble.

 

 

So first you say changing the encryption (Wether opcode first\second byte only) by engine hooks is crap.

And then you say the most logical thing to do is changing it - by fixing a few BYTEs in the keypacket?.

 

Any decent implementation of a sniffer\editor (for bot or otherwise) would sniff from a direct socket or ws32 connect and just snap up any key that is not contained within the client rendering any serverside only protection useless.

 

Are you just really...daft and full of ego from praise from idiots on MXC?

 

 

What the hell?

 

 

 

There's absolutely no point in attacking the OP (wether his protection is awesome or just shit) - short of you wanting to flex muscle.

Which also reveals the sadstate of MXC - and how no one has any knowledge to verify the information they're presented with.

Link to comment
Share on other sites

Obfuscation requires new way of calculting opcodes for packets, aka intervening in client aka a client extension.

 

 

Any change of blowfish or standard RSA keys in client\server - is easily bypasseble.

 

 

So first you say changing the encryption (Wether opcode first\second byte only) by engine hooks is crap.

And then you say the most logical thing to do is changing it - but by using already defining keys in client.

 

Are you just really...daft and full of ego from praise from idiots on MXC?

 

 

What the hell?

 

 

 

There's absolutely no point in attacking the OP (wether his protection is awesome or just shit).

 

Okay i see you dont get it. Packet obfuscation is implemented in the client it requires no client modification. That has nothing to do with the gameserver - loginserver communication because its custom. I dont say change the encrypton god...i say that theres an unfinished packet that goes along with the protocol detection and it contains the packet obfuscation, thats the protection retail servers have(packet obfuscation was translated to java from a leeked off source) so your argument is pretty much useless.

Link to comment
Share on other sites

Okay i see you dont get it. Packet obfuscation is implemented in the client it requires no client modification. That has nothing to do with the gameserver - loginserver communication because its custom. I dont say change the encrypton god...i say that theres an unfinished packet that goes along with the protocol detection and it contains the packet obfuscation, thats the protection retail servers have(packet obfuscation was translated to java from a leeked off source) so your argument is pretty much useless.

 

No it's not retard.

 

Because any key that is sent FROM the server for any type of algorhythm\encryption - can be snapped up without YOU on the serverside able to do ANYTIHNG about it.

 

Jesus christ - read some basic security strategies\system developemnt.

Link to comment
Share on other sites

No it's not retard.

 

Because any key that is sent FROM the server for any type of algorhythm\encryption - can be snapped up without YOU on the serverside able to do ANYTIHNG about it.

 

Jesus christ - read some basic security strategies\system developemnt.

 

God you still dont get it...your stupidity amazed me really, but okay i'll give it a try again. Packet obfuscation is a feature that hides your protocol when you communicate with a server. When this happens only those clients can identify the protocol that supports obfuscation others cant. When this feature is in works, the communication looks like a bunch of random stuff all over the place, so tools that easily identify eg the protocol and packets sent cant do this anymore unless they write a whole new one.

Link to comment
Share on other sites

God you still dont get it...your stupidity amazed me really, but okay i'll give it a try again. Packet obfuscation is a feature that hides your protocol when you communicate with a server. When this happens only those clients can identify the protocol that supports obfuscation others cant. When this feature is in works, the communication looks like a bunch of random stuff all over the place, so tools that easily identify eg the protocol and packets sent cant do this anymore unless they write a whole new one.

 

Please read some books and learn basic security.

 

If Server sends XYZ to Client - anyone on the clientside can snap that up and read it.

 

If server obfuscates XYZ to ABC - Client needs a way to decrypt ABC into XYZ.

 

 

If there's a algorhythm\function that does this - a sniffer without hooking needs to know the way ABC turns into XYZ.

There could be several keys of variable length or one - but if that key is sent by server the sniffer can know the time during the initial connections where the server sends the key to turn ABC into XYZ.

 

Sniff it - and replicate the algorhythm within the sniffer and boom protection is broken.

This is true of any Obfuscation\Encryption\Algorhythm.

 

This is weak - because there will be a standard established way to calculate ABC to XYZ in the client that NEVER CHANGES.

And even if the key is random each time the server sends it to client - it would not matter because it would sniff the key each time.

 

 

There is no way 100% protect - but if you change keys and the way to calculate ABC to XYZ and protect it enough in a DLL so it requires abnormally large time to fully learn the new calculation method - you'll keep out 99,9%.

 

 

Simple logic, wether L2 or Hello Kitty Adventure Island.

 

 

Spewing random shit like "PACKET CLOUDING MAYNZ" and "Obfuscation" that the newer gracia clients support (and do not support as well) is pointless - when you seem to fail to grasp the basic mathematical logic behind systems.

 

 

By not touching client your relegated to NCSofts clientside functions of decrypting any data sent Server<>Client.

 

Jesus christ - it's sad that your supposed to be a super high ranking mxc dev and you don't understand basic premises of communication -_-

 

Link to comment
Share on other sites

Also FYI:

 

There's always been encryption since c3 was it? - adding an extra obfuscation layer does nothing but complicate the data process and add more overhead in calculating the correct packet Opcode.

 

Learn the normal encryption + the packet opcode obfuscation and you can still easily bypass anything.

Hence the need for something "custom" even if it's Opcode^2 - and then make sure it's hard as hell to figure out it's just Opcode^2.

Link to comment
Share on other sites

Also FYI:

 

There's always been encryption since c3 was it? - adding an extra obfuscation layer does nothing but complicate the data process and add more overhead and in calculating the correct packet Opcode.

 

Learn the normal encryption + the packet opcode obfuscation and you can still easily bypass anything.

Hence the need for something "custom" even if it's Opcode^2 - and then make sure it's hard as hell to figure out it's just Opcode^2.

 

Its not custom you freekin fcktard god...ITS A PACKET FROM THE CLIENT. Anyway done with the arguing have better things to do than listening your pretty much senseless arguments. Nothing shows that better than the fact that 1st you ask what the hell is packet obfuscation than you suddenly become the professor of it, good guy google helped i guess.

Link to comment
Share on other sites

Its not custom you freekin fcktard god...ITS A PACKET FROM THE CLIENT. Anyway done with the arguing have better things to do than listening your pretty much senseless arguments. Nothing shows that better than the fact that 1st you ask what the hell is packet obfuscation than you suddenly become the professor of it, good guy google helped i guess.

 

I didn't say it was custom.

 

I said the need for something custom - even if simple beats the hell out of standardized process that's the same for everyone else.

 

 

And yes you are retarded - because you do not read my posts nor answer them.

You just act like a bigshot and call arguments senseless without saying specificly why.

 

I geuss because they're logical and your used to garbled MXC idiots.

Where yelling and throwing "OMFG MXC SUPAH DEV" tag helps an argument.

 

You can't magicly invent a different way the entire subset of computers communicate and pretend it's awesome.

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.




×
×
  • Create New...