Server attaked by Disconnect hacking tool

Newbie Spellweaver
Joined
Aug 4, 2012
Messages
10
Reaction score
0
Hello everybody!
The first, sorry my bad English :)

I think my server is attacked by disconnect hacking tools (but i don't know about this tool)

Expression:

While have 2 connection to server (my team), all work ok!
But, when i found a strange connection, Client says: Reconnect Server(Main) several times. And Server.exe on my server is crashed!!! => DC. This phenomenon repeated!!!

After that, i blocked this strange ip, all work ok!
But, Because alot of Vietnamese person use ADSL network, to change another ip is very easy by reset modem => it isn't a perfect way!

My private priston tale server using MagicPT source, work on windows server 2003 r2 enterprise x86. "sa" user in MSSQL is blocked, and don't have any web service on this server.

Port opened:
22/tcp open ssh
80/tcp closed http
3389/tcp open ms-term-serv
10009/tcp open unknown

Event Viewer don't have any record about that.

Plese help !!!
 
Same thing happened to ePT and bPT all last week.
They were using the disconnections to bug the server into duplicating their items.
That is why ePT and bPT are currently down.

Watch out for duplicated item ID's!
 
i see whats happen... for what i see this DC is linked to USERID, what i see is, they try to create a char and put 71 characteres in the name of char.... so when SQL.dll acess Database that have a bug.. and they crash... i will see more things and i will post here...
if sameone know something...
 
as far as I know, every single PT server fom Brazil is being attacked with this. and the IP doing it is the same Kakdela posted, the DSL from Vietnam.

bPT said that they have found a fix to this, and it looks real since they had no more problems with the server crashing.
 
as far as I know, every single PT server fom Brazil is being attacked with this. and the IP doing it is the same Kakdela posted, the DSL from Vietnam.

bPT said that they have found a fix to this, and it looks real since they had no more problems with the server crashing.

I think so, and i think i know who attacked us. But i don't know what are real problem to fix :(
 
Just insert a null (0x00) into the packet before processing it? That would be my suggestion.
 
I hate to repeat myself, but...

Just insert a null (0x00) into the packet before processing it? That would be my suggestion.

To elaborate, find the code which identifies packet 48470081 (I presume that's 0x48470081) and allow it to pass through decrypt before replacing the last character of the password field with a null, then continue normal execution.

We're talking about buffer-overrun exploitation here, just make sure every string buffer is correctly, and timely terminated.
 
I don't hate myself, I just hate having to repeat myself. Totally different thing.

If someone says "I can do it" or "I've done it" then it means "ner ner na ner ner, you can't fix it, I'm better than you", because if they where going to tell us, they would have done so while they where going to the effort of making a post. There's no point encouraging their playground antics by saying "awww, go on, tell us, pleeeeeaase... MOM! Brian won't let me play with his stuff!". ;)
In case you don't get the reference:-
 
for fix this erros, "20 20 20 20 " u can do two things, all afther the server recive the package.
1) see if in package have same "20" value and fill it.
2) count the number of character in the package and .... fill it =D
the most dificult is , how you will do that... well, a simple kernel function works fine here. but, keep in you mind ... you need to do a fast way to fix, becouse the package recive is a way to cause a delay in server.

theres another way to fix...
chage the 'port/package' of you server (6E 4e ... ) but, if anyone gets this info ... you will down again.

@bob this is good for u ?? (@off)( tnks for that client )
 
Hex code 0x20 is usually a space character, no? (character 32 decimal) So they just padding, and you could use something like the classic BASIC TRIM$ command / function.

What I was suggesting was, if the buffer should be a fixed length buffer, just make sure the last character in the buffer is always filled with a null. That's very fast and efficient.

If there is a valid terminator before, this wont hurt. If not, it will cure. No logic or testing is required, see?

You'd have to perform this operation after all decryption and decompression, and before any further processing. Ofc.
 
Back