Jump to content

Fix Moblock / Bravery Cape Hack


Vanilla

Recommended Posts

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!

  • Love 16

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

vor 2 Stunden schrieb .NyanCat:

Can you create a guide for all types of cheats?

What about Pro/Wait Damage? Speedhacks? Wallhack?

Speedhacks are already somewhat fixed.

In battle.cpp look for the function IS_SPEED_HACK and replace it with this one:

bool IS_SPEED_HACK(LPCHARACTER ch, LPCHARACTER victim, DWORD current_time)
{
	if (ch->m_kAttackLog.dwVID == victim->GetVID())
	{
		if (current_time - ch->m_kAttackLog.dwTime < GET_ATTACK_SPEED(ch))
		{
			INCREASE_SPEED_HACK_COUNT(ch);

			sys_log(0, "%s attack hack! time (delta, limit)=(%u, %u) hack_count %d",
					ch->GetName(),
					current_time - ch->m_kAttackLog.dwTime,
					GET_ATTACK_SPEED(ch),
					ch->m_speed_hack_count);
			if (test_server)
			{
				ch->ChatPacket(CHAT_TYPE_INFO, "%s attack hack! time (delta, limit)=(%u, %u) hack_count %d",
						ch->GetName(),
						current_time - ch->m_kAttackLog.dwTime,
						GET_ATTACK_SPEED(ch),
						ch->m_speed_hack_count);
			}

			SET_ATTACK_TIME(ch, victim, current_time);
			SET_ATTACKED_TIME(ch, victim, current_time);
            if (ch->m_speed_hack_count >= 10)
				ch->GetDesc()->DelayedDisconnect(3);
			return true;
		}
	}

	SET_ATTACK_TIME(ch, victim, current_time);

	if (victim->m_AttackedLog.dwPID == ch->GetPlayerID())
	{
		if (current_time - victim->m_AttackedLog.dwAttackedTime < GET_ATTACK_SPEED(ch))
		{
			INCREASE_SPEED_HACK_COUNT(ch);

			sys_log(0, "%s Attack Speed HACK! time (delta, limit)=(%u, %u), hack_count = %d",
					ch->GetName(),
					current_time - victim->m_AttackedLog.dwAttackedTime,
					GET_ATTACK_SPEED(ch),
					ch->m_speed_hack_count);
			if (test_server)
			{
				ch->ChatPacket(CHAT_TYPE_INFO, "Attack Speed Hack(%s), (delta, limit)=(%u, %u)",
						ch->GetName(),
						current_time - victim->m_AttackedLog.dwAttackedTime,
						GET_ATTACK_SPEED(ch));
			}

			SET_ATTACKED_TIME(ch, victim, current_time);
            if (ch->m_speed_hack_count >= 10)
				ch->GetDesc()->DelayedDisconnect(3);
			return true;
		}
	}

	SET_ATTACKED_TIME(ch, victim, current_time);
	return false;
}

Note that the only thing I've changed is that the loggin always happens and that you get disconnected if the speedhack detection is triggered too often. The "10" is subject to change.

Also make sure that you visit the function GET_ATTACK_SPEED which is also in battle.cpp. Remove these two lines:

	if (item && item->GetSubType() == WEAPON_DAGGER)
		real_speed /= 2;

and set the variable "default_bonus" to something like 70 (which is a quite good value in test environments). You can fine-tune this value. Make sure you also remove the * 3. You may just want to have a simple value like 70 (default: 80 which is too much in some conditions, depending on your server). This should trigger all those hacks and still make your game playable without false-positives. But this indeed needs further testing, for live servers I recommend choosing a higher threshold (at least 80) until it's confirmed to be working on your server.

  • Love 6

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

9 hours ago, Hype! said:

what about hidden? thats one of the most annoying hacks, do you have a solution for this problem?

The public hidden fixx is buggy and give random Bann 

5 hours ago, PeaceMaker said:

 

what is hidden ? 

Look here this is the released version but Bann random members who not use a hidden hack 

 

 

Link to comment
Share on other sites

vor 3 Stunden schrieb Kori:

The public hidden fixx is buggy and give random Bann 

Look here this is the released version but Bann random members who not use a hidden hack 

 

 

I already saw this version. This isnt the best solution ... it would be better fixing this issue instead of bann/kick every player. Unfortunately I dont have the knowledge to fix it.

vor 9 Stunden schrieb PeaceMaker:

 

what is hidden ? 

 

 

Link to comment
Share on other sites

Am 12.9.2018 um 17:38 schrieb Hype!:

I already saw this version. This isnt the best solution ... it would be better fixing this issue instead of bann/kick every player. Unfortunately I dont have the knowledge to fix it.

 

 

It looks like it's using a skill to attack or am I wrong? Because if these are basic attacks, they'd be triggered by the speedhack detection and therefore lead into a kick with the fix mentioned above. But it'd be that they're abusing a skill and mayb the check is missing there. I'll have a look and tell you once I've figured it out.

  • 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

2 godziny temu, Vanilla napisał:

It looks like it's using a skill to attack or am I wrong? Because if these are basic attacks, they'd be triggered by the speedhack detection and therefore lead into a kick with the fix mentioned above. But it'd be that they're abusing a skill and mayb the check is missing there. I'll have a look and tell you once I've figured it out.

I think it`s normal attack, on video posted above ninja has 4lvl. Some servers disable the speedhack function because of random kick with bad code.

 

or I'm ginger

1 godzinę temu, Vanilla napisał:

Nope, it's not bad code. The code is working fine. Some servers just allow absurd high attack speed values because they think it's cool or something.. The calculation doesn't add up at all. I've tested the code that's posted above and it seems to work without false flags, but there's no guarantee that it'll work with every server.

I use similar code,  Some servers just allow absurd high attack speed values because they think it's cool or something.. that`s what i mean

Link to comment
Share on other sites

vor 11 Minuten schrieb JarajTo:

I think it`s normal attack, on video posted above ninja has 4lvl. Some servers disable the speedhack function because of random kick with bad code.

 

  Unsichtbaren Inhalt anzeigen

 

or I'm ginger

 

 

Nope, it's not bad code. The code is working fine. Some servers just allow absurd high attack speed values because they think it's cool or something.. The calculation doesn't add up at all. I've tested the code that's posted above and it seems to work without false flags, but there's no guarantee that it'll work with every server.

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

vor 3 Stunden schrieb Vanilla:

Nope, it's not bad code. The code is working fine. Some servers just allow absurd high attack speed values because they think it's cool or something.. The calculation doesn't add up at all. I've tested the code that's posted above and it seems to work without false flags, but there's no guarantee that it'll work with every server.

even when I set the attack speed down, i can use this attack speed. I tried it with m2bob and lalaker and it works. It would be really nice, when you can find a "fix" for this issue. Gameforge and some other privates server already fixed that.

Link to comment
Share on other sites

vor 13 Stunden schrieb Hype!:

even when I set the attack speed down, i can use this attack speed. I tried it with m2bob and lalaker and it works. It would be really nice, when you can find a "fix" for this issue. Gameforge and some other privates server already fixed that.

As I said, it depends on your server. The calculation for attack speed and it's acual motion isn't quite correct, that's true. I dunno if it's possible to fix this at all. But it fully depends on your server if it works or not or if you have to fine-tune the value. I even saw a server allowing normal attacks to be faster than the hack would send it's packets. And if that's the case, then you have exactly this problem.

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

This create a bug https://metin2.download/picture/I136Ej30Biyo1XbhuAZ866ox0zE5o2Xk/.gif

This is my fix.

	else
	{
		MonsterChat(MONSTER_CHAT_ATTACK);
	}
	
	if (pkVictim->IsPC() == true)
	{
		pkVictim->SetSyncOwner(this);

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

	int iRet;
}  

And at the end of the function:

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

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

	return false;
}

After fix works ok https://metin2.download/picture/FC8u74HZTMSB9e4MhvuGwGvgTINjSBZO/.gif

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

vor 1 Stunde schrieb Dobrescu Sebastian:

This create a bug https://metin2.download/picture/I136Ej30Biyo1XbhuAZ866ox0zE5o2Xk/.gif

This is my fix.


	else
	{
		MonsterChat(MONSTER_CHAT_ATTACK);
	}
	
	if (pkVictim->IsPC() == true)
	{
		pkVictim->SetSyncOwner(this);

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

	int iRet;
}  

And at the end of the function:


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

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

	return false;
}

After fix works ok https://metin2.download/picture/FC8u74HZTMSB9e4MhvuGwGvgTINjSBZO/.gif

I don't think that's correct. If you do that, you'll make moblock/bravery hack work. The problem is that BeginFight() will be triggered even if the distance check fails. So normally the distance check returns BATTLE_NONE and therefore neither SetSyncOwner nor BeginFight() will be triggered. And since BATTLE_NONE is returned, there shouldn't be any damage. Are you sure you implemented it exactly as mentioned in the thread? Because I can't seem to trigger the bug you mentioned here.

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

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.