[Shetch]

Hello SA-MP forums!

Very recently, PR-RP.com experienced a big influx of item duplicating which was caused by the DialogHider.cs CLEO modification. We of course knew that the items were being duplicated, but we were not sure how. We didn't even know where to start looking. After about a week of the server being online, we received a message were a player offered to expose the duplication bug to us. He of course told us about the DialogHider.cs being used and we took action immediately.

How does it work?:
DialogHider.cs can hide dialogs shown to the player and move around while the dialog is sill being displayed on the player's screen (the server thinks it's being displayed), even though no dialog is visible for the player (client side). The dialog can then be shown again at any given moment as well as multiple responses can be sent to a single shown dialog.

1. Dialog ID 1 is show to the player: "Would you like to get $100?" "Yes" "No"
2. Player responds "Yes" to the dialog.
3. $100 is given to the player.
4. Player responds "Yes" to the dialog again, even though no dialog was displayed.
5. $100 is given to the player.
6. Player responds "Yes" to the dialog again, even though no dialog was displayed.
7. $100 is given to t... etc.

How can I prevent my server from such attacks?:
The way you fix such an exploit is very simple. You set up a single player variable called 'pDialogOpen'. When a dialog is show to the player by the server, set the variable 'pDialogOpen' to 1. When player responds to the dialog, set it back to 0. If a player responds to the dialog and 'pDialogOpen' is already 0, you know DialogHider.cs or some other dialog response hack is being used.

The code I used for our GM:
Defining a function which we will use to display dialogs:

Код:

public ShowPlayerDialogEx(playerid, dialogid, style, caption[], info[], button1[], button2[])
{
	ShowPlayerDialog(playerid, dialogid, style, caption, info, button1, button2);
	PlayerInfo[playerid][pDialogOpen] = 1;
	return 1;
}
// You can hook the ShowPlayerDialog to make it tidier.

Displaying a dialog by the server:

Код:

ShowPlayerDialogEx(playerid, 1, DIALOG_STYLE_MSGBOX, "Money", "Would you like to receive $100?", "Yes", "No");

Responding to the shown dialogs:

Код:

public OnDialogResponse(playerid, dialogid, response, listitem, inputtext[])
{
	if(PlayerInfo[playerid][pDialogOpen] != 1)
	{
		new string[128];
		format(string, sizeof(string), "AdmWarn: %s(ID: %i) is possibly dialog hacking.", PlayerInfo[playerid][pName], playerid);
		SendAdminMessage(COLOR_YELLOW, string);
		return 1;
	}

	PlayerInfo[playerid][pDialogOpen] = 0;

	// Here we can SAFELY respond to the dialog, because now we know the dialog was actually shown to the player BY THE SERVER.
	switch(dialogid)
	{
        	case 1:
		{
			if(response)
			{
				GivePlayerMoney(playerid, 100);
			}
		}
	}
	return 1;
}

[wallee]

This is nothing new, but nice of you to warn us.

[Vince]

Assign the dialog id to the variable rather than just 0 or 1. Then you can compare it directly in OnDialogResponse which provides an extra layer of protection, i.e.:

PHP код:

if(PlayerInfo[playerid][pDialogOpen] != dialogid) 


[Shetch]

Quote:

Originally Posted by Vince Assign the dialog id to the variable rather than just 0 or 1. Then you can compare it directly in OnDialogResponse which provides an extra layer of protection, i.e.: PHP код: if(PlayerInfo[playerid][pDialogOpen] != dialogid)

Do you mean showing a player dialog ID 1 and receiving response from dialog ID 2? I thought SA-MP server is already protected against invalid dialogid responses by itself, no?

Quote:

Originally Posted by wallee This is nothing new, but nice of you to warn us.

Well, it was definitely new for me and it was killing the server. Just wanted to give my 2 cents on how to overcome this.

[Lordzy]

Quote:

Originally Posted by Shetch Do you mean showing a player dialog ID 1 and receiving response from dialog ID 2? I thought SA-MP server is already protected against invalid dialogid responses by itself, no?

There were few tools designed to send fake packets to the server, such as what you've doubted. I'm not sure whether they've been fixed on the latest version.

Also, why hasn't anyone considered about the listitem ID sent to server by the client? Suppose there's a dialog list which will contain list items such as "Dodo\nSparrow" and the same dialog ID, if shown to an administrator will have "Dodo\nSparrow\nSeaSparrow\nHunter". As you can see the dialog response is supposed to have (0 < listitem < 1) for normal players and (0 < listitem < 3) for administrators. But if a player sends a fake response with listitem as 3, they could get access to Hunter. This is an example of how server security can be easily exploited by sending fake packets. So, it's better to safeguard almost everything to be totally safe.

[PrO.GameR]

This isn't anything new, It's been used for a long time and indeed thats the way to prevent it, although players can still have an open dialog, hide it, and spoof another one (as far as I remember if they knew the ID they could open it and fake the data)
They can also change the inputtext, hence messing with codes that use that data directly.
Your code just fixes the dumb way to abuse this cheat.

I'll just cut the code I have for this and make it a plug and play plugin for people that are struggling with it.

[Vince]

Quote:

Originally Posted by Shetch Do you mean showing a player dialog ID 1 and receiving response from dialog ID 2? I thought SA-MP server is already protected against invalid dialogid responses by itself, no?

Not sure, but it doesn't hurt to try.

[Sgt.TheDarkness]

Quote:

Originally Posted by Lordzy There were few tools designed to send fake packets to the server, such as what you've doubted. I'm not sure whether they've been fixed on the latest version. Also, why hasn't anyone considered about the listitem ID sent to server by the client? Suppose there's a dialog list which will contain list items such as "Dodo\nSparrow" and the same dialog ID, if shown to an administrator will have "Dodo\nSparrow\nSeaSparrow\nHunter". As you can see the dialog response is supposed to have (0 < listitem < 1) for normal players and (0 < listitem < 3) for administrators. But if a player sends a fake response with listitem as 3, they could get access to Hunter. This is an example of how server security can be easily exploited by sending fake packets. So, it's better to safeguard almost everything to be totally safe.

If you had one simple check to determine whether or not the player was authorized to have that vehicle, this would never work. The same can be applied to anything a player tries to exploit, if you add sanity checks into your code, the chances of exploitation become very slim.

[Shetch]

Quote:

Originally Posted by wallee This is nothing new, but nice of you to warn us.

Quote:

Originally Posted by PrO.GameR This isn't anything new, It's been used for a long time and indeed thats the way to prevent it, although players can still have an open dialog, hide it, and spoof another one (as far as I remember if they knew the ID they could open it and fake the data) They can also change the inputtext, hence messing with codes that use that data directly. Your code just fixes the dumb way to abuse this cheat. I'll just cut the code I have for this and make it a plug and play plugin for people that are struggling with it.

I searched the SA-MP forums and found nothing but players complaining about this issue. That's why I created this thread.

[Lordzy]

Quote:

Originally Posted by Sgt.TheDarkness If you had one simple check to determine whether or not the player was authorized to have that vehicle, this would never work. The same can be applied to anything a player tries to exploit, if you add sanity checks into your code, the chances of exploitation become very slim.

Yes, that's how I've been doing before knowing about this exploit. However, it's always better to have safeguard over natives and callbacks to ensure safety. Just like it says, "prevention is better than cure".