How can we help you today? How can we help you today?

Patch-friendly settings

Background: We use binary patches for our application, which means that users only need to download a small file instead of the full setup file. The patch file includes a diff of all files in the installation ie: only changes are included.

I'm not sure whether smartassembly uses any form of randomisation which would cause the obfuscated version of each assembly to be different every time a new obfuscation is performed. This would mean that the patch files would be larger than they could be.

If smartassembly does use any randomisation, it would be nice to be able to specify a seed value when invoking via the commandline. That would mean that it puts the power in the author's hands as to when to create a new seed value and thus get a bit of extra protection, but he could keep the seed value the same for a few builds, just to keep the patch file size small.

Thanks,
Gareth.
garethhayter
0

Comments

5 comments

Sort by
  • Alex D
    Hi gareth,
    That's an interesting scenario. SA doesn't use a random generator for obfuscation, so a seed value isn't needed. However, the unicode obfuscation is fairly chaotic, so a small change could cause a large amount of types and methods to change name.

    The weaker ascii renaming scheme is much less chaotic, I would suggest using that for this situation.

    A random number is used for strings encoding. I think this use case is niche enough that I won't be able to add the seed feature for it, at least in this version. Let me know whether you find it causes a large patch size.

    Does anyone else use SA in this kind of scenario?

    Cheers,
    Alex D
    0
  • Sentinel
    I am aware of this scenario but thought it imposible to generate patch file for changed assembly with acceptable size. It will be nice if it become possible.
    Sentinel
    0
  • garethhayter
    I'll need to perform some tests to check patch size of ascii vs. unicode and strings encoding vs. none. I'll try to get that done this weekend.
    garethhayter
    0
  • Alex D
    Actually, on closer inspection, the random generator used in strings encoding already has a fixed seed, so the whole thing should be deterministic. However, it's still likely to be chaotic.
    Alex D
    0
  • garethhayter
    Here's an interesting approach by another obfuscation tool: http://www.retrologic.com/rg-docs-patchex.html

    Probably not something for this version, but would be nice to aim for it next version...
    garethhayter
    0

Add comment

Please sign in to leave a comment.