Code Protector - Frequently Asked Questions

  1. If someone tried to decompile the VBA code after protecting an MDE file using the Code Protector, what would the result be?
  2. What limitations does the product have?
  3. What exactly is this 'compiler junk' you talk about?
  4. Does removing the "compiler junk" affect the database in any way? e.g. performance or logic?
  5. Can't I just rename all of the variables in my VBA code to make it less readable?
  6. Why aren't Public-scope variables removed from the "compiler junk" in the MDE Source Code Protector?
  7. Do you offer a Money Back Guarantee?
  8. Can the Code Protector be automated from the command line?
  1. If someone tried to decompile the VBA code after protecting an MDE file using the Code Protector, what would the result be?
    Please review our example page that details the changes that are made to each MDE file and the reasons why they are highly effective.
  2. What limitations does the product have?
    The product does not prevent decompilation (or reverse engineering) of the VBA code.  Instead, the product aims to make decompilation harder and more inline with decompiling standard VB6 applications.
  3. What exactly is this 'compiler junk' you talk about?
    Normal MDE files created by Access contain extra information that we like to call "compiler junk" - this is redundant information about variable names, data types, constants, UDTs etc that are no longer needed in a fully compiled MDE file.

    However, this "compiler junk" makes it much easier to decompile/reverse-engineer the VBA code in an MDE file to a standard that is very close to the original VBA source code (including for example all variable names).
  4. Does removing the "compiler junk" affect the database in any way? e.g. performance or logic?
    No.  The "compiler junk" is no longer needed and can safely be removed.  The "compiler junk" is only required when the database is not in a fully compiled state - (i.e. in MDB or ADP format).

    There will be no effect on the performance of your code or indeed the logic by removing the "compiler junk".
  5. Can't I just rename all of the variables in my VBA code to make it less readable?
    Yes, but this isn't as effective as what the Code Protector achieves.  Compilers (including the VBA compiler) make use of both explicit variables (declared by the developer) and implicit variables (declared by the compiler) in order to make everything work as it should.  By examining the "compiler junk", a decompiler can determine exactly which variables are implicit and which ones are explicit - using this information, the decompiler can then optimize the resultant source code by removing all implicit variables - this is key to making the resultant source code very accurate to the original. 

    By removing the "compiler junk", the Code Protector prevents a decompiler from determining whether a variable is real (explicit) or temporary (implicit), which means it has to treat all variables as explicit - this makes the resultant source code much less readable - see the example page to get an idea.

    For an example of this, please look at the Example page.
  6. Why aren't Public-scope variables removed from the "compiler junk" in the MDE Source Code Protector?
    Variables, UDTs and Enumerations that are declared by you as Public scope form part of the TypeInfo of the VBA module.  To explain, Public scope items should not be classified as "junk" because if you remove them from the TypeInfo of a VBA module, they will effectively become Private scope.  If you don't want an item to be publicly viewable, you should declare the items as Private rather than Public in your source code before compiling to MDE format. 

    Therefore, the default options in the Code Protector are to leave Public scope items intact.  However, you may change the default options if you wish, but beware that if you have late-binding code that requires a public-scope variable, UDT or Enumeration to be present, then the code will fail.  We recommend that you do not change the default options unless you have a specific need to do so.

  7. Do you offer a Money Back Guarantee?

    Yes - ultimately we want you to be delighted with your purchase.  If you aren't, then just notify us within 14 days of purchase and we will refund your full payment.   All that we require from you is that you tell us:
    • your registered email address
    • that you have uninstalled the software and won't use it again
    • why the product didn't meet your needs (so we can improve the product)

  8. Can the Code Protector be automated from the command line?
    Yes, as of version 1.25 you can now launch the MDE Source Code protector from the command line passing two arguments for the input MDE and output MDE file paths.  In doing so the application will launch and process the file without interaction from the user (as long as no problems occur).  The application will also close automatically once complete.

    The simple command line arguments are displayed below:

     <PathToMDEProtector>\MDEProtector.exe "PathToInputMDE" "PathToOutputMDE"

    Tip: The default path for the MDE Protector executable is '%programfiles%\EverythingAccess.com\MDE Source Code Protector for Microsoft Access'.


    New in v2:

    Extended command line support:

    <PathToCodeProtector>\MDEProtector.exe "PathToInputMDE" "PathToOutputMDE" /rvX /rcX /rtX /reX /p "Password"

    Where X is a number 0 - 2:
    0 = Private Only
    1 = Private and Public
    2 = None

    /rv is the equivalent of the 'remove module variables' option inside of the application.

    /rc is the equivalent of the 'remove module constants' option inside of the application.

    /rt is the equivalent of the 'remove module types' option inside of the application.

    /re is the equivalent of the 'remove module enums' option inside of the application.

    /p "Password" allows you to pass the Access 2007 / 2010 encryption password via the command line

<< Back to main information page