Jump to content
metin2dev
Ekstasia2
Vanilla

c++ Fix Moblock/bravery cape hack

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!

  • Like 11
  • Thanks 1

Share this post


Link to post
Share on other sites

Very useful, we shouldn't need many anticheat measures if we would apply corrections in the source itself, thank you for this contribution.

  • Like 1

Share this post


Link to post
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.

  • Like 5

Share this post


Link to post
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 

 

 

Share this post


Link to post
Share on other sites
vor 19 Minuten 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 

 

 

Can you send me the link to the fix?

Maybe instead of banning just kick the players? 

Share this post


Link to post
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 ? 

 

 

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites
On 9/17/2018 at 2:16 PM, .NyanCat said:

I tried everything out now and both wait and pro damage are fixed. Moblock as well!

Nice!

Is there a solution for move speedhack?

the same problem, move speed hack work..

Share this post


Link to post
Share on other sites

I'm onto movement speed hack stuff. Gotta research a bit first (had a few rough days, so no time for that). I'll keep you guys updated once I've developed a fix. Shouldn't be too troublesome :D

Share this post


Link to post
Share on other sites

This create a bug https://gyazo.com/a80967c04140ded5930e6f164cb3480b

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://gyazo.com/76e522e1f209e8617d4c5bf039842086

Share this post


Link to post
Share on other sites
vor 1 Stunde schrieb Dobrescu Sebastian:

This create a bug https://gyazo.com/a80967c04140ded5930e6f164cb3480b

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://gyazo.com/76e522e1f209e8617d4c5bf039842086

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×