Defense against crash o matic or other else channel crashers!

Anyone have found this problem? Someone know something about it?

I wonder if its possible to block the particular packet from this crashing tool with a firewall.

Why does the server even accept such unauthorized commands if the tool does from what I read, send a disconnect for all players?

Idk how do it... ENC+MCL check fully enabled, magic key totally changed, not just first 2 digit, XOR's changed, in logs nothing found.

It is a problem on other game also...
ALL of the pocket has a function to crash the server..
They use the tool name WPE.. my TyeraGuard block it.
So meaning if your client has TyeraGuard... your server is fully protected..
I add WPE on vr 1 because that is the problem also on other game I develop.

Just encrypt TyeraGuard on cabalmain.exe so pro programer cant disable it.
TyeraGuard Protect the game packet for the program that send wrong message on the server

And you cant block pocket on firewall.. firewall block port but not packet.
Packet is a part of client. Once you run the game. All packet is open .
Every moved you do in the game has a pocket with size and byte.
But when you use a program like WPE and send wrong message to a packet of client.
The server detect it as a bug and detect that server has a problem and thats the reason why it crash.

Sadly your tool not avoid it because if he use their own cabalmain, than he can use that easily. Server side cabalmain check needed. That is only way to avoid these attacks.

Ok.. I will tell a magic.
The cabalmain unpack has a magic..
You can add ip of your server on cabalmain unpack.
But im not done yet on my experiment about cabalmain.exe unpack.
If I success I will share...

So if you will encypt it with tyeraguard.. viola! 110% protected.

And if will just think hard.. you will see that there is many way to hide tyeragurd plus cabalmain plus your ip.

I will tell a example..
1st example is add ip on cabalmain.exe
2nd is chnage port of cabalmain.exe
3rd change client version

And many many more ways ...
There are many ways so other cant play your game without using your server cabalmain

Quote:

---

Originally Posted by AkiSora

Sadly your tool not avoid it because if he use their own cabalmain, than he can use that easily. Server side cabalmain check needed. That is only way to avoid these attacks.

---

I think they cant use their cabalmain bcuz the XOR is different and also the magic key...

Quote:

---

Originally Posted by JemCanoy

I think they cant use their cabalmain bcuz the XOR is different and also the magic key...

---

really ... do you think ppl that are clueless can crash a channel ... xor, magic key, header xor or packet indent everything CAN be replicated in a malicious cabalmain by a person that KNOWS what he's doing ... that's why server-sided protection is the only good protection ...

Quote:

---

Originally Posted by TyeraErde

There are many ways so other cant play your game without using your server cabalmain

---

you have NO clue what u're talking about ... take it from some1 who CAN hack :)

on-topic: try changing the bad packet OP code to something else on SERVER-SIDE :P (0xA4 if i remember correctly)

edit: actual opcode is 0x0A not 0xA4 :) confusion was caused by the correct opcode 0xF4 :D

Quote:

---

Originally Posted by x30unlimited

on-topic: try changing the bad packet OP code to something else on SERVER-SIDE :P (0xA4 if i remember correctly)

---

specifically where?

Quote:

---

Originally Posted by Revy

specifically where?

---

usr/bin/WorldSvr ?

Quote:

---

Originally Posted by x30unlimited

usr/bin/WorldSvr ?

---

u know not me xD

Somebody known something about GMHeartITS/RockAndRollITS?
Its check client hash or encryption key?

Quote:

---

Originally Posted by AkiSora

Somebody known something about GMHeartITS/RockAndRollITS?
Its check client hash or encryption key?

---

No, it's completely unrelated to the client.

If anyone can tell a solution against channel crashign than i will give it for something:
-Event NPC, Forcecalibur, xdata.enc filling (with ENC and MCL hashes)

Why don't you program a server side program that will check incoming packets and block the bad ones? The source is out here on ragezone somewhere to decrypt client packets.

The yamachis tool named something,.. Ostara?

http://forum.ragezone.com/f451/packe...yption-792325/
http://forum.ragezone.com/f451/sugge...roblem-772490/
http://www.multiupload.nl/KE9Z6PY5MZ
To bad that I don't have the source since its no use for me, I cant find it anywhere.

Quote:

---

Originally Posted by toast2250

The yamachis tool named something,.. Ostara?

http://forum.ragezone.com/f451/packe...yption-792325/
http://forum.ragezone.com/f451/sugge...roblem-772490/
Multiupload.nl - upload your files to multiple file hosting sites!
To bad that I don't have the source since its no use for me, I cant find it anywhere.

---

It was indeed ostara and I can't seem to find the thread myself O.o
https://dl.dropboxusercontent.com/u/13349043/ostara.rar
This is the last source I have on my dropbox.

Quote:

---

Originally Posted by SpeedDevil

It was indeed ostara and I can't seem to find the thread myself O.o
https://dl.dropboxusercontent.com/u/13349043/ostara.rar
This is the last source I have on my dropbox.

---

He deleted it when he was working on Minerva

I think so found the problem..
May anyone have multiple idea's than share here!

Quote:

---

Originally Posted by AkiSora

If anyone can tell a solution against channel crashign than i will give it for something:
-Event NPC, Forcecalibur, xdata.enc filling (with ENC and MCL hashes)

---

With this kind of approach, most likely not going to happen. However if you want to trade you can simply use this section. Also what if someone says " Release the SFC, EventNpc, xdata tool, then w/l share the solution for "channel crashing", what would be your respond?

already found the source of bug! All owner be careful with return stones... Those are causing that crashes...

It's not only return stones that can crash a channel or so I've been told.

Quote:

---

Originally Posted by AkiSora

already found the source of bug! All owner be careful with return stones... Those are causing that crashes...

---

be a good boy and share your fix, the fact that retn stone is causing the bug can be deducted from what i've told you, changing packet opcode from 0x0A to 0xF4 = making retn stone work :) so changing 0x0A server-side to something else wld work as protection against the bug, just my thoughts :)

Quote:

---

Originally Posted by SpeedDevil

It's not only return stones that can crash a channel or so I've been told.

---

special inv is causing crash too :D

This is a reason why i dont want share anything good. This guys this... Lot of people knows about this bug but no any share to fix them..

I have replaced Return Stones in item.scp and in item.enc...
After i tried to use Return Core but not working... Tried to use Free Warp from PremiumService.scp but same not work! Anyone any idea?

Quote:

---

Originally Posted by AkiSora

I have replaced Return Stones in item.scp and in item.enc...
After i tried to use Return Core but not working... Tried to use Free Warp from PremiumService.scp but same not work! Anyone any idea?

---

seel the infinite return stone on shops?

I have tried to use Return Core, and Free Warp in premiumserice.scp
Same msg:
You can't use return stones until cooldown get down!

I have replaced return stones with HP Potion lvl3..

Hmm weird ^^

Can you explain with more detail how are attackers crashing your server? just by using return stones?

They just moddify the size of that packet, making it bigger, so when someone use return stone, server can't handle that, cuz its to big, so in that way it makes the srv to shutdown cuz its over what he can do , so with client too.

until you find a solution I recommend you disable the wap and unfortunately force your users to walk

@cadena, thats not gonna make happy a lot of players, cuz might leave from your server and going to other server that has this bug fixed. Imagine players staying to walk from bloody ice till to fort ruina, when they simple can use warp, so i kinda not recommand you that.

Then this is more like a exploit rather then a bug, there are no problems with warping if you use the main from PunkS7yle.

The other main released by Spike had some bugs with return stone as PunkS7yle mentioned it will crash your channel.

There are no problem with punky's cabalmain because the packet is intact, the cabalmain that Spike released, was still from Punky that made that edit with the return stone packet.

I have taked in Free Warp in PremiumService.scp and kept return stone with some modification in item.scp..
Now return stones count not getting down! I dont know it will fix or not but i will try it..

What main are u using akisora?

punky 374 + some adress modified...

did you try with the return core ? http://www.cabalhelix.com/itemshop/i...ReturnCore.gif (ID = 944)

Yep but still can crash... I dont know what he can use but... its horror...

I get the felling that removing return stones from the server and client side wont help.

You probably only need to log some packet traffic, spoof or break it and fire it away at the server, no need to use the client,.. wpe?
The server binary cant handle such request/s so it crashes, you need a packet filter that drops bad packets. Shouldn't the server be made to drop such packets instead of crash?

Therese a packet logger now do a packet filter, fix/change the server binary.
I'm newb so its just a idea, I think your doomed. : P

http://forum.ragezone.com/f315/kal-o...filter-898174/

Have you tried this?
http://forum.ragezone.com/f451/defen...ml#post7576184

Blocking certain incoming packets - General Computing - Codecall
iptables(8) - Linux man page

Ugh,.. :blink:

do u have the opcodes of the packages that makes the server crash? i think i can code something ive an idea. But i need to make some test, crashing a test server.

I can make a server so you can remote test crash it all you want.

i dont need a server, i need the opcodes

0xF4
E2 B7 1D 00 00 00 00 00 F4 00 3E 47 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00

Is this what you want? Its the return stone but I cant test it because I have Xtrap.

So this using an return stone itemid.. so if you remove all return stone example can't use this anymore ye? explain me if im not right!

I have now deleted Return Stones from Shops, quests. Setted Property to nontradeable, nondroppable, nonmailable. Deleted from starter gear... Now the crasher can't get return stone...

u need an script to remove all rs from inventory, then remove all return stone from shops, drops and gifts on boxes (chaos lamp per ex). And they can still attack you sending the package with an external program.

I can help, but first i need the tool or a main without xtrap.

not really, ever time needed return stone to get into invertory.. Ever time found in channel crasher invertory 2nd invertory tab, 2nd line 2nd slot... This was a first which gvied an idea for return stone bug...

then you can remove the second inventory from premium scp

If he can't get return stone than can't crash channel. Free Warp fucntion is enough for players until i can't get a packet filter!

crash channel???
I tested only cause the client DC
The server does not crash

my ser is crash...

did it work?

yes world close

Quote:

---

Originally Posted by cadena

did it work?

---

IF this question goned to me, than i can say yep it seems work :) That guy was on our server but can't crashed...

Then ill do the same as you, better safe than sorry.

Which server u own?

my server is still not ready. Will be a latin server

Up for this! Any solution for the new channel crash tool?

Bunch of noping in WorldSvr.elf.. To be exact its 36 bytes in total to nop..

P.S
After you edit the 36 bytes in WorldSvr.elf, you also need to fix this one E2B70E0000000000350C05000001 in chatnode. It can crash channels too.. Good luck!

Quote:

---

Originally Posted by x30unlimited

on-topic: try changing the bad packet OP code to something else on SERVER-SIDE :P (0xA4 if i remember correctly)

actual opcode is 0x0A not 0xA4 :) confusion was caused by the correct opcode 0xF4 :D

---

What to change sir? found already