Jump to content

Fix Moblock / Bravery Cape Hack


Vanilla

Recommended Posts

vor 19 Stunden schrieb Dobrescu Sebastian:

Yes, but our sources are different so you may not have, but some like me yes. Anyway, the thing is that i just separed your new lines and old lines. Old lines for PC. New lines for mobs. Why hack should work ? I'm gonna test on day.

you're right, probably this works with players, but the bug wasn't because of this. The speedhack detection should kick the player, that's the job for the hack you showed here. The lines you changed affect mob-lock/bravery cape hack. If you do this, you won't be able to draw aggr from monsters. Did you try that?

We are the tortured.
We're not your friends.
As long as we're not visible.
We are unfixable.

Link to comment
Share on other sites

  • Premium

As all of us know, damage hacks send always same packet (eg. combo1, combo2, etc). It will be nice to send attack command client-server with attack type attached as variable and serverside to null them if they are identical in a short time.

 

Best regards, Florin.

Link to comment
Share on other sites

  • Premium
Acum 16 ore, Vanilla a spus:

you're right, probably this works with players, but the bug wasn't because of this. The speedhack detection should kick the player, that's the job for the hack you showed here. The lines you changed affect mob-lock/bravery cape hack. If you do this, you won't be able to draw aggr from monsters. Did you try that?

For me works perfect. Are you referring to IS_SPEED_HACK? There i made some changes to accurately detect players with hack. So maybe my fix will only apply to me in this situation.

 

Link to comment
Share on other sites

  • Bronze

When I read the topic's title I thought it's about this

https://metin2.download/picture/0bJW15j4Cs20sE3Gv862xUUNANBR7HpZ/.png

 

But Hey! Thanks for the tip, I didn't know about this issue :D

Edited by Metin2 Dev
Core X - External 2 Internal
  • Metin2 Dev 1
Link to comment
Share on other sites

vor 3 Stunden schrieb Exygo:

When I read the topic's title I thought it's about this

https://metin2.download/picture/0bJW15j4Cs20sE3Gv862xUUNANBR7HpZ/.png

 

But Hey! Thanks for the tip, I didn't know about this issue :D

I don't even remember doing this :D It'd be, but I honestly have no idea.

 

@_Sielu Why so complicated? We already have a working solution and this is the speedhack check. It's working fine and I think a counter is better to store than walking through a vector every time a damage packet goes it's way.

Edited by Metin2 Dev
Core X - External 2 Internal

We are the tortured.
We're not your friends.
As long as we're not visible.
We are unfixable.

Link to comment
Share on other sites

1 godzinę temu, Vanilla napisał:

I don't even remember doing this :D It'd be, but I honestly have no idea.

 

@_Sielu Why so complicated? We already have a working solution and this is the speedhack check. It's working fine and I think a counter is better to store than walking through a vector every time a damage packet goes it's way.

I see you dont know how speedhack attack work :)

gl with this function.

Link to comment
Share on other sites

  • 3 weeks later...
Dnia 6.10.2018 o 21:30, tester12 napisał:

vanilla, have you any idea for block speed hack move?

Probably u must delete this function with PythonCharacterModule.cpp (It is not used by the client but allows for speeding)

{ "SetMoveSpeed",                    chrSetMoveSpeed,                    METH_VARARGS },
Link to comment
Share on other sites

Am 12.10.2018 um 23:24 schrieb ReFresh:

@Vanilla I tested your fix but, when some player use bravery cape and start killing monster it will kick the player from the server.

Thanks for testing it. Can you send me a syslog snippet? You can also play with the values and adjust them to your needs. The fix for bravery cape hack doesn't involve a kick. The kick is only triggered by the speedhack detection, so there's either something wrong with it or the values need to be adjusted.

  • Love 1

We are the tortured.
We're not your friends.
As long as we're not visible.
We are unfixable.

Link to comment
Share on other sites

  • Gold

@Vanilla Oh, I deleted it because it caused problems so I didn't want to use this fix anymore. But in syslog was the speedhack detection error. So I inserted default speedhack function back and all was good. It started kicking players many times in a row when they were killing monsters. Tell me where I can find a speed hack value for detection of speedhack? I couldn't find the value anywhere. 

Here is a syslog of player which was kicked to login menu:

Oct 14 11:06:56 :: Tester attack hack! time (delta, limit)=(0, 95) hack_count 10
Oct 14 11:06:56 :: Tester Attack Speed HACK! time (delta, limit)=(0, 95), hack_count = 11
Oct 14 11:06:58 :: Tester Attack Speed HACK! time (delta, limit)=(0, 95), hack_count = 12
Oct 14 11:06:58 :: Tester Attack Speed HACK! time (delta, limit)=(0, 95), hack_count = 13
Oct 14 11:06:58 :: Tester Attack Speed HACK! time (delta, limit)=(0, 95), hack_count = 14
Oct 14 11:06:58 :: Tester Attack Speed HACK! time (delta, limit)=(0, 95), hack_count = 15

I'll be always helpful! 👊 

Link to comment
Share on other sites

  • 3 weeks later...
  • 5 months later...
On 9/9/2018 at 8:17 PM, Vanilla said:

Hello everybody,

since I've heard that a lot of servers (and even the most recent vanilla source release) have no fix for this hack I decided to release this. It's not too big, but I really would like to make it visible for everybody. I highly dislike hacks in every form and I'll gladly develop such fixes.

So, the fix is quite easy. It's a bug from metin2. They decided to add a check if the target is too far away to be attacked and yeah, that works. Targets only receive damage once they're within range. But the problem is that modern moblock tools do that a different way. They send attack packets to every mob in the near surrounding which triggers aggr towards the player. You may ask: Why does it trigger aggr and let the mobs move to the player? Well, as mentioned, the source has a fix for that - but it's implemented too late.

1. Open char_battle.cpp and search for this function: CHARACTER::Attack

First you may notice that there's literally no check for distance. The distance check is implemented in battle.cpp in the function battle_melee_attack. That's fine and we don't need to modify anything about this.

 

2. If you scroll down you'll see the following lines:


	pkVictim->SetSyncOwner(this);

	if (pkVictim->CanBeginFight())
		pkVictim->BeginFight(this);

Noticed something? Yeah, the check is - as mentioned before - in the function battle_melee_attack. The problem is, that these lines are executed before the check happens. So hackers will be visible in logfiles (syslog should spam distance errors) but they're still free to hack like they want to.

 

3. Move the lines below the battle type segment

So, how do we fix this? We'd simply move it down below the battle type functions. So you'd move it just before the line "if (iRet == BATTLE_DAMAGE || iRet == BATTLE_DEAD)". But still that won't be enough since these lines would still be executed. We don't want them to be executed. So we wrap a condition around it.

 

4. modify these lines so they look like this:


	if(iRet != BATTLE_NONE)
	{		
		pkVictim->SetSyncOwner(this);

		if (pkVictim->CanBeginFight())
			pkVictim->BeginFight(this);
	}

If we take a look on the battle type functions we'll notice that they return the BATTLE_NONE if something goes wrong - for example the distance is invalid.

 

5. you're done!

The fix pretty much solves this issue. If you still know hacks that work feel free to write in this topic, I'll gladly share solutions once I've developed them.

Enjoy!

Hello.
Dear Vanila.
Thank for this. 

Bugged!!!!!

WHITOUT this fix, syserr :
SYSERR: Apr 11 16:23:49.472300 :: Attack: Unhandled battle type 3

Fix:

char_battle.cpp
in this switch:
switch (GetMobBattleType())

After this:
case BATTLE_TYPE_MELEE:
            case BATTLE_TYPE_POWER:
            case BATTLE_TYPE_TANKER:
            case BATTLE_TYPE_SUPER_POWER:
            case BATTLE_TYPE_SUPER_TANKER:

add:
            case BATTLE_TYPE_SPECIAL:

 

787292068_Nvtelen.png.6faa7b0bbb3398fd29

Link to comment
Share on other sites

Announcements



×
×
  • Create New...

Important Information

Terms of Use / Privacy Policy / Guidelines / We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.