encrypted chained macro fails to run

pseakins · Post by **pseakins** » Fri Jun 15, 2007 1:11 pm

I have a multi purpose macro invoked by F9 hotkey. Depending on the application underneath it performs different functions. One of them is intended to send a password through to Quicken. It does this by calling a further encrypted macro which contains the password. I've written and tested it all. It works fine. Finally, I applied encryption to the password macro. Now it doesn't work. So, I put in messages to see what's going on because you can't debug a hotkeyed macro. I've pasted the appropriate parts from the F9 macro below. I thought it might be pathing so I tried both pathing methods (one is remmed). Finally, when "QuickenZipUp.scp" is UNencrypted the debug message displays correctly ie., "Macro result = [ok]". When "QuickenZipUp.scp" is ENcrypted the debug message displays "Macro result = [%MACRO_RESULT%]" which tends to indicate that the macro was never reached. (It goes without saying that the 1st thing the password macro does is set the MACRO_RESULT value).

Here's the code portion;

Label>DoQuicken
//Macro>%SCRIPT_DIR%\QuickenZipUp.scp /arg1=Quicken
Macro>C:\Documents and Settings\user\My Documents\Macro Scheduler\QuickenZipUp.scp /arg1=Quicken
MessageModal>Macro result = [%MACRO_RESULT%]
Goto>Exit

pgriffin · Post by **pgriffin** » Fri Jun 15, 2007 1:58 pm

Encrypted macros require the password to open the program, well before the MACRO_RESULT is populated.

Would it be possible for you to encrypt the calling macro (the 'F9' macro) and place the password macro within a Subroutine (srt>) which is only called when needed?

For sensitive data it may be a better solution to put several SRT>'s in a single file and call them when necessary instead of calling multiple macros.

pseakins · Post by **pseakins** » Fri Jun 15, 2007 2:15 pm

Well, unless I have misread you, what you've said directly contradicts the help file info. - "Macro Scheduler allows you to set a password for a script which must then be used to edit it."

Edit it - not run it.

"However, if you need to use Macro Scheduler to automate a process which involves sending passwords to other applications or to send other sensitive information, then you would want to ensure that only the right people can edit the script and see the secrets."

I understand the encryption is intended to be used to protect the source code. Requiring a password for execution is a separate option which I have NOT selected.

The help is quite specific about this.

The password macro IS the one containing sensitive data, that's why I wish to encrypt it. The calling macro is general purpose and does not require encryption.

pgriffin · Post by **pgriffin** » Fri Jun 15, 2007 3:25 pm

My mistake. I will test a few options and see what can be done.

Me_again · Post by **Me_again** » Fri Jun 15, 2007 3:38 pm

Macro> can't call an encrypted macro. Check out Marcus comments and workaround in this thread about this issue.

pgriffin · Post by **pgriffin** » Fri Jun 15, 2007 3:49 pm

Thank you, Me_again! that is what I thought (and have experienced)...

I have also embedded passwords in an Access database which is password protected, then retreive the password with some vbscript which is run from a compiled macro.

A little more work, but that way the password is protected.

Me_again · Post by **Me_again** » Fri Jun 15, 2007 3:59 pm

I would probably just store the data in a separate encrypted file and decrypt that file with the main macro. But if the macro is already written then Marcus work around will be the quickest solution.

pseakins · Post by **pseakins** » Sat Jun 16, 2007 3:06 am

The "Marcus workaround" #1 does not work. The UNencrypted macro when invoked via "Run" works correctly. When it is ENcrypted, I see a flying Macro Scheduler icon dashing across the screen, but the macro does not execute. A "here I am" message within the macro fails to display.

Run Program>C:\Program Files\Macro Scheduler\msched.exe C:\Documents and Settings\user\My Documents\Macro Scheduler\QuickenZipUp.scp /arg1=Quicken

Bob Hansen · Post by **Bob Hansen** » Sat Jun 16, 2007 5:40 am

Instead of hard coding and/or encrypting the password in the script, how about reading it in from a hidden, security permissions controlled text file?

In any method that you decide to use, if using SEND>, remember that log files will display the values, so you may want to disable logging, or pass the log file through an editor to Search/Replace the SEND> line with the password. The last line in your macro could call another macro to do the editing of the log file once it was closed.

pseakins · Post by **pseakins** » Sat Jun 16, 2007 2:12 pm

"Marcus workaround" #2 - assigning a hot key to the encrypted macro and "pressing" the hotkey in the calling macro DOES work.

Bob, reading a password from a hidden file using a plain text (unencrypted) macro would defeat the purpose of having a secret file. If the method is plain to see then so is the password.

Re, logging. If the macro is encrypted without logging, then logging cannot be subsequently turned on without first supplying the encryption password, so this is not an issue for me.

For me the purpose of this is to be able to have the encrypted password supplied to the application using a few keystrokes - to save having to tediously type the password as I have been doing for the last 9 years. I have built in a failsafe so no one can easily poke away at it. Now it's all working I am quite happy with it.

I use an incrementing environment variable. This variable seems to be visible only to Macro Scheduler. If I drop to Dos and check, it's not there!