                 ,_.                                           ,_.
  ,mi   ,mi    ]@!           ,gm       _mmms.   ,mi   ,mi    ]@!        _mmmm.
  ]@W   d@`    W@           i@@@     ,WAf~V@@   ]@W   d@`    W@       ,WA` 'V!
   M@i gA`    ,@P          gA`@@     !f    @P    M@i gA`    ,@P       ]@[
   '@@Wf      ]@!         WA` @@          dA     '@@Wf      ]@!       'M@m.
   ,W@@.      W@       __W@___8@i       ,Wf      ,W@@.      W@          V@@s
  dA`!@@.    ,@P      **@@****Y@[      gA`      dA`!@@.    ,@P           'M@b
,WA`  !@@s   ]@b    _m ]@!    '@@   ,gAK____. ,WA`  !@@s   ]@b   ,_m,m     @@
!M[    '*@@! 'M@@@@**' @@      Y@D  @@A****M@ !M[    '*@@! 'M@@@@**`!@b. ,d@!
                                                                       `****'


[This file is best viewed with a fixed-width font such as Courier in 80-cols]


XLAtoXLS v2.0
=============

(C)1996, Craig Poxon


Introduction
------------

Put simply, XLAtoXLS converts Excel Visual Basic for Applications (VBA)
Add-Ins (*.XLA) back to code in a Workbook (*.XLS).

According to Microsoft's Excel (5.0) Visual Basic User's Guide, this can
not be done:

> Creating an Add-In Application
> ==============================
>
> You can use an add-in application to distribute copies of your work in an
> unreadable form that others can use.

	...

> Converting a Workbook to an Add-In Application
> ==============================================
>
> When you save a workbook in the add-in format, Microsoft Excel converts
> its code into a compressed form that cannot be read by anyone, and
> cannot be converted back into a workbook. This process is called
> _compiling_. Compiling speeds execution of the resulting code and protects
> your work from being read or modified by anyone else.


It has been known for some time within the Excel community (you do read
comp.apps.spreadsheets,slac.users.excel, and microsoft.public.excel.programming
on msnews.microsoft.com, don't you?) that VBA code can be obtained from XLA
files, but obviously, the people in the know kept the method of doing so
very close to their chests.

Unfortunately, someone rocked the boat. That someone was me. I released an
Add-In called XLATOXLS.XLA which crudely decompiled XLA files to XLS
containing the VBA code.

I received a lot of hassle, perhaps rightly so, from VBA developers. However,
this forced the Excel 'wizards' to start stating more loudly that, yes, XLA
files could be decompiled, and even the steps that could be performed to make
an add-in secure would not make them 100% safe against the determined hacker.

It is worth reiterating the precautions that should be taken before
converting your VBA into an Add-In for release. The following points could
leave you in trouble, as well as a would-be hacker, so before undertaking any
of the following, remember:

 KEEP A BACKUP OF YOUR UNMODIFIED CODE!


  1. Remove any comments, blank lines and leading spaces from your code.

     Yes, comments are left in XLA files! If your code is compromised, why
     lead someone through every intricate step? Removing blank lines and
     leading spaces from your code makes it quite tricky to read, and
     all that structuring is a bugger to put back in manually.

     You might even go as far as hashing all of your variable, function
     and sub-routine names to meaningless combinations of numbers and
     letters. Inserting some dummy code and variables can throw the
     inexperienced off the scent as well.


  2. Save your XLS file containing the VBA code and apply a password.

     To do this, select the File|Save As... menu. In the 'Save As' dialog
     click the 'Options...' button. Enter a password into the edit box
     labeled 'Protection Password:' and press return. Another dialog will
     appear titled 'Confirm Password'. Enter your password for a second time
     in the edit box labeled 'Reenter Protection Password'. Assuming you
     have correctly typed the password, the dialog will close and your
     code will be saved with a password protection.

     The longer your password is, the more protection it will offer. i.e.
     it will take someone with the right knowledge/software to crack the
     password. I think that there must be an optimal length for a file
     password, but I have yet to investigate that. I suggest that your
     passwords be at least 15 characters long. I also recommend that you
     keep a backup copy of the code, which has not been saved with a
     password, in case you forget it!

  3. Protect every sheet in your workbook with a password.

     Select the Tools|Protection|Protect Sheet... sub-menu item. In the
     'Protect Sheet' dialog, ensure that any check boxes present are
     selected. There can be up to three check boxes for a normal worksheet
     protection, labeled: 'Contents', 'Objects', and 'Scenarios', but
     there are none when protecting a Dialog.

     Once entered, you will be asked to reconfirm your password. I think
     the optimal length for a sheet protection password is 15 characters
     and this is what I recommend you use.

     Again, make sure you remember the password that you use or keep a
     backup of your code without any protection.

  4. Protect the workbook with a password.

     Select the Tools|Protection|Protect Worbook... sub-menu item. In the
     'Protect Workbook' dialog ensure that the two check boxes labeled
     'Structure' and 'Windows' are checked

     Once again, use a 15 character password and reconfirm it making sure
     you will remember the password or have a backup file.


You can now make your 'secure' Add-In.



Security of Add-Ins all boils down to the following:

  - How determined is someone going to be to get at your code?
  - How much time are you willing to spend protecting your Add-In from
    decompilation and then from comprehension of code?
  - How valuable is your code?

My conclusion is that a VBA Add-In is never 100% safe, so it is not worth it.
I no longer publicly release Add-Ins written in VBA. I now write solely in
C/C++ and make XLL Add-Ins, which are DLLs that run standalone in Excel.
This is the only way to make your code 100% safe!


Any of points 2-4 above were enough to defeat version 1 of XLATOXLS, hence:


Version 2
---------

Improvements over version 1:

  - Fully compiled C/C++ XLL Add-In. Much faster and more compact than an
    XLA.

  - Add-Ins no longer have to be installed to be decompiled. File dialogs
    prompt you to select the Add-In you wish to work on and where to save it.

  - File password protection is removed.

  - Sheet protection is cracked.

  - Workbook protection is cracked.

On a Pentium 90 with 16MB of memory, the time taken to crack a sheet or
workbook protection password of optimal length is 30 seconds.


Version 1 does not work when running in Excel 7, and neither does Version
2 ... YET! In Excel 7, it seems that Microsoft attempted to close the stable
door after the horse had bolted, so to speak, and it does stop Version 1 of
XLAtoXLS from working.

This is not applicable for Version 2, as it works in a completely different
way from Version 1. I am currently in the process of porting my code to
32-bit and a version of XLAtoXLS for Excel 7 will be out soon.

Keep an eye on my webpage or the /WIN95/EXCEL directories of the major FTP
sites for more details.


Instructions
------------

Requirements:

  Excel 5.0 and minimum hardware for such.
  Please refer to your manuals for more details.


Installation:

  1. Copy XLATOXLS.XLL to your EXCEL directory
  2. Select Add-Ins... from the Tools menu
  3. A dialog titled 'Add-Ins' will appear.

     If you already have Version 1 of XLAtoXLS and the Add-In is loaded, it
     may be advantageous to unload it first. If there is already a ticked
     checkbox labeled 'XLA Decompiler', uncheck it by clicking it and press
     the OK button. Go back to step 2.

      Else

     Click the Browse button

  4. A dialog title 'Browse' will appear. Select XLATOXLS.XLL from the EXCEL
     directory, in the list box labeled 'File Name:' and double-click it
     or press OK
  5. 'XLA Decompiler' will now appear in the listbox labeled
     'Add-Ins Available:'
  6. Press the OK button
  7. XLAtoXLS is now installed and the registration reminder screen will
     appear.



To decompile an Add-In:

  1. Activate a worksheet
  2. Select Decompile Add-In... from the tools
  3. A dialog titled 'Select an Add-In to decompile' will appear. Locate the
     file you wish to work on and press the OK button.
  4. A dialog titled 'Save Decompiled Add-In As' will appear. The dialog
     will suggest a path and filename which is the same as the Add-In but
     with a .XLS extension. When you have selected the file name you wish
     to save the decompiled file as, press the OK button.
  5. If a file with the same name already exists you will be asked whether
     it is okay to overwrite the previous instance.
  6. The Add-In will now be decompiled. If the workbook structure or any of
     the sheets are password protected a message will appear in the status
     bar saying that the password is being broken and the elapsed time for
     the current crack.
  7. The fully decompiled code for the Add-In will now be visible.


Uninstallation:

  1. Select Add-Ins... from the Tools menu
  2. A dialog titled 'Add-Ins' will appear. Scroll through the listbox
     labeled 'Add-Ins Available' and locate the check box labeled
     'XLA Decompiler'. Click off this entry and press the OK button.
  3. A message box will appear informing you that XLAtoXLS has been
     unloaded.


Demo Restrictions
-----------------

This demo version will not provide you with an Add-In's code. It will
decompile an Add-In to demonstrate that it is capable of doing so and show
it to you. Access to the decompiled code is prevented by a modal message
box i.e. you will not be able to do anything, except examine the view of
the decompiled workbook and its first sheet, until you clear the message box
by pressing it's OK button.

Since you will only be able to see the whole of the first page, this is the
only one which will have the password removed. This may vastly decrease the
time taken to decompile the Add-In, when compared to the registered version
of XLAtoXLS.

To obtain a fully functioning version of XLAtoXLS you must pay a registration
fee.


Registering
-----------

The fee for registering is UKP40 or USD60. My address has changed a few times
in recent years (you know how it is when you are a student, and then your
first couple of jobs after that) so please contact me via E-Mail to obtain
my current postal address:

  lardy@slough.demon.co.uk

With your fee, please include a letter stating what the payment is for. You
must also include a statement to the effect of:

  i)  You will only use XLAtoXLS to recover the lost source code of a VBA
      Add-In that you have written

        OR

  ii) You will not misappropriate any other VBA code that you may obtain
      through the use of XLAtoXLS


      WITHOUT THIS STATEMENT I CANNOT PROCESS YOUR ORDER!


If you are sending cash, please make sure the paper is thick enough so that
the payment isn't visible through the envelope.

As soon as I receive your fee, I will send to you a ZIP file containing
a registered, fully functional version of XLAtoXLS via a UUEncoded E-Message.
If you want the file uncompressed or on a diskette via postal mail, then
this can be arranged at no extra cost.


If you have already registered for version 1 of XLAtoXLS, you can upgrade to
version 2 for UKP10 or USD20. I should have already been in contact to inform
you of this opportunity, but in case I have missed you out please remind me.


Once I have ported XLAtoXLS to 32-bit code, I will inform all of the
registered users, and the version for Excel 7 will be available to you
at no extra charge. A restricted, demo version will be placed in the
/WIN95/EXCEL sub-directory of the popular FTP sites.


Protection From XLAtoXLS v2
---------------------------

I'm not out to ruin anybody's business with XLAtoXLS. I would hope that
everyone who uses XLAtoXLS does so responsibly. However, I would still like
to advise what further techniques you can apply, as well as the ones
detailed earlier, to hamper decompilation of your Add-In with Version to
of XLAtoXLS:


The bottom line is that you can't protect your Add-Ins 100%, unless they
are written in C that is!

The most time consuming aspect is the password breaking routines. Make
sure all aspects of your Add-In are password protected and that the
password is between 10-15 characters long. You might want to spread your
code over as many modules as possible (the maximum is 256); the more
passwords that need to be broken, the longer it will take to decompile the
Add-In.

The longest time it takes to crack a password on a Pentium 90 with 16MB of
RAM is 30 seconds. So potentially, it could take two hours to decompile an
Add-In with 256 modules. In practice, it would never take that long...who
in their right mind is going to protect 256 modules (and they had better
do it with different passwords as well!) before making an Add-In? The non-
stop march of technology will increasingly negate the effectiveness of
these precautions.

Disclaimer
----------

XLAtoXLS is Copyright (C)1996 by Craig N. Poxon and is protected as such
under international treaty provisions. All Rights Reserved.

There is no warranty, express or implied, with XLAtoXLS. There is no
warranty of non-infringement on third parties' rights.

You may not rent, lease or offer the use of XLAtoXLS. You may not reverse
engineer, decompile or disassemble XLAtoXLS.

You may not use XLAtoXLS to decompile any Excel Visual Basic for
Applications Add-In authored by Craig Poxon.

In no event shall the author be held liable for misuse of this product,
any loss of data, down time, loss of revenue or any other direct or indirect
damage or claims arising from the use of XLAtoXLS.


Acknowledgments
----------------

Microsoft, Excel, and Visual Basic are registered trademarks of the
Microsoft Corporation.
