obfuscated code

[codered2009]

I was trying to create patch file using Visual Patch 3.5 for my c# application which was protected with Eziriz .NET Reactor(obfuscation) for security purpose. But the process failed with the following error
--------------------------------------
Starting build...
19-Jun-09 12:29:16 AM
Project file: Unsaved Document

Autosaving document
Updating screen themes
Creating build copy of data
Locating build configuration
> Using build configuration: Default
Expanding design time constants
Performing pre-build checks...
Verifying files in version: 1.1
Verifying files in version: 1.0
Expanding folder references...
Excluding files not in current build configuration...
> Scanning version: 1.1
>> 0 files excluded from build
> Scanning version: 1.0
>> 0 files excluded from build
Excluding global script files for build configuration...
Including global script files...
> Script file included: C:\Program Files\Visual Patch 3.5\Includes\Scripts\_Global_Functions.lua
Inserting patch manifest...
Error 3013: Failed to decrypt patch engine file: 34003

Build failed - 1 Error(s), 0 Warning(s)


--------- Errors ---------
Inserting patch manifest...
Error 3013: Failed to decrypt patch engine file: 34003

---------------------------------------------------------------------

Can anybody illustrate on this? Is it not possible to create patch for obfuscated code?

[Lorne]

That error doesn't have anything to do with the files in your project, it relates to the Visual Patch 3.5 installation itself. Specifically, the client runtime file needs to be decrypted as part of the patch.exe build process. That error message indicates that the decryption failed, because the encrypted client runtime file has been damaged.

Make sure your security tool didn't attempt to encrypt anything in the Visual Patch 3.5 program folder, for example.

You could try uninstalling and reinstalling Visual Patch. If that fixes it I'd recommend checking the integrity of your hard drive, file system drivers, etc. since it may be a sign of an unstable system.

[codered2009]

I reinstalled the application and now the error went off. but the patch file size is now 34MB. The source file sizes were 33.1MB and the difference between them was just a single line of code. How come the patch size is so big?
BTW, when I did the patching without obfuscating the two sources(exes) then the size of the patch was Ok(in KB size). After the merging of Dlls and obfuscation the problem ocured.

[jassing]

I've seen huge patches exceed the size of file(s) being patched when using agressive protection schemes. What happens in the binary file becomes so vastly different, that VP says "I'll just include the file itself". It still will not put the file on a system unless it finds a valid key file.

One line of 'source code' change; then protected / encrypted could yeild a 100% different file (binary wise).

Consider using any encryption scheme (AES, Blowfish, DES, etc) and encrypt:

This is a test string

Now encrypt

This is a Test string

Not even 1 line of code change, a single byte. the two encrypted strings will be different by more than a single byte.

[Lorne]

Obfuscated files looks like random data -- that's the whole point.

Binary differencing works by finding common patterns between two files, so you can essantially skip the parts that match, and only store the differences between them.

Two files that contain randomized data aren't going to have very many similarities between them.

Add the size of the patch client itself (i.e. the GUI, Lua engine, etc.) and it can end up being a bit larger than the original files.

VP is pretty smart in that it will only use a binary difference if it's smaller than just including the whole file (after it's been compressed). So aside from the unavoidable patch client overhead, which is quite small for the range of functionality it offers, VP will never create a patch that is larger than the source files.

The same thing happens if you try to patch two files that have already been compressed, by the way. Compressing the files effectively strips the patterns out of them.

If you want smaller patches, you will get much better results with files that haven't been obfuscated.

You might want to consider only obfuscating some of your files. Or, if your security tool supports it, you could include the tool with your patches and use it to "un-obfuscate" the files before the patch process begins, then patch the un-obfuscated files, and re-obfuscate them.

Are you sure you need to obfuscate your executables? Most attempts at obfuscation are circumventable, so you may only be creating a false sense of security by doing so.