CODEWITHSUNDEEP
delphidisabled-control
Bianca
Bianca

Reputation: 973

Delphi Anti Cheat (enable any disabled button)

In my application there are some buttons that I've disabled for a reason. But these buttons are easily enabled by TNTEnforcer.

Is there any easy way to prevent this?

Tried to pack with some packer / obfuscator, but still can be enabled.

What is TNTEnforcer

Upvotes: 6

Views: 2343

Answers (3)

David Heffernan
David Heffernan

Reputation: 612874

VCL controls are backed by Win32 controls and these are inherently insecure. You cannot restrict access to their properties and state. External programs can readily modify state, press buttons etc.

You might be tempted to run a timer that resets the UI state at a high frequency. This might make it a little harder for a cracker. But still not particularly hard, and at what cost to your program and code?

So, in my view, you should not attempt to stop external programs interfering with the UI state. Instead you can add checks and defences to the OnClick handlers and other code behind the UI. This is perfectly crackable too, but it does at least require a little more effect from the cracker.

You might write:

button.Enabled := False;
button.OnClick := nil;

when you disable the button. When you re-enable it you could write:

button.Enabled := True;
button.OnClick := MyOnClickHandler;

That's a rather crude way to do it. It might be preferable to push the checking down the call chain, into the OnClick handler itself, or even better, further down into your business logic. That way, no matter how the code reaches the business logic, if it needs to be blocked it will be.

Upvotes: 8

stanleyxu2005
stanleyxu2005

Reputation: 8231

If your application uses the traditional component TButton (from StdCtrls.pas), the button is a Windows standard control. Anyone, who knows the control handle, can access it. The attacker TNTEnforcer can iterate windows and find the button handle. After that, the malware can enable your button and simulate mouse clicks.

Solution 1: As disabled buttons are not clickable, my first idea is to intercept CM_ENABLECHANGED (David mentioned WS_DISABLE) messages, so that the malware is not able to change the button enable-state. The solution is similar to David's but over complicated. As David mentioned, we can remove the OnClick handler temporarily, when we intend to disable a button.

Solution 2: Another idea is to protect button handle from being searched. You might convert your traditional Vcl-based application to a cross-platform FireMonkey based application. Because the FMX draws components itself, the TNTEnforcer cannot attack in the old way at all. I have never done that before. The convert effort can be high.

Upvotes: 1

Remy Lebeau
Remy Lebeau

Reputation: 595792

Unless the attacker has intimate knowledge of the inner workings of the particular version of the VCL that your app is using so that it can directly manipulate the VCL's internal memory, the best it can do is use standard Win32 APIs to manipulate the publicly accessible HWNDs of your app, such as by using EnableWindow() followed by BM_CLICK.

So one simple defense would be to remove the attack vector that you want to protect - in this case, by replacing TButton with TSpeedButton. TButton is a TWinControl descendant, so it has an HWND. TSpeedButton is a TGraphicControl descendant, so it does not have an HWND, and thus is not accessible to external processes because it is a custom drawn control managed exclusively by the VCL, not the OS.

Upvotes: 4

Related Questions