Enhancement for Macro command

Ideas for new features & functions

Moderators: Dorian (MJT support), JRL

Post Reply
schwander
Junior Coder
Posts: 29
Joined: Tue Jun 14, 2011 6:32 am

Enhancement for Macro command

Post by schwander » Sun Jun 26, 2011 5:08 pm

Hi,
As we have LabelToVariable> command it would be great if Macro> command will be able to run code not only from a file but from a variable also.
Best regards

User avatar
Marcus Tettmar
Site Admin
Posts: 7393
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Mon Jun 27, 2011 7:36 am

Can you explain why this would be beneficial and why it would be different from using a subroutine and GoSub?
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

schwander
Junior Coder
Posts: 29
Joined: Tue Jun 14, 2011 6:32 am

Post by schwander » Mon Jun 27, 2011 3:43 pm

With my pleasure, Marcus :)
Please, provide me the safe method to dial with encrypted macro.
I found the only one and it is unacceptable to me.
Firstly, I have to decrypt the macro.
Further, I need to write it to a hdd before running it and ... desecure the data.
Can Macro Scheduler safely remove temporary file? And why to do this? If we have a possibility to run macro from a variable?
Best regards.

PS.
There is no problem if the macro contains the program code only. But, what about strictly confidential data, database etc.?

User avatar
Marcus Tettmar
Site Admin
Posts: 7393
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Mon Jun 27, 2011 5:36 pm

I'm not sure I follow. As I understand it you were making a request for the following functionality:

Code: Select all

/*
Some_Code:
Let>var=123
MessageModal>var
//etc
*/

Macro>Some_Code
And I am asking how is this better than the following existing functionality:

Code: Select all

SRT>Some_Code
Let>var=123
MessageModal>var
//etc
END>Some_Code

GoSub>Some_Code
I'm not sure what being any of this has to do with temporary files or encryption.
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

schwander
Junior Coder
Posts: 29
Joined: Tue Jun 14, 2011 6:32 am

Post by schwander » Mon Jun 27, 2011 6:43 pm

I mean the Macro> command can not securely work with encrypted macros (which can contains some confidential data).
Firstly, I need to save decrypted macro to the temporary file. And then read it to run the Macro> command. So, I need to use special soft to safely remove (http://en.wikipedia.org/wiki/Data_remanence) that temporary file.
And there is no need to utilize such applications if Macro command can accept variable (wich contains decrypted script) instead of filename. That is the benefit.
Last edited by schwander on Mon Jun 27, 2011 6:54 pm, edited 1 time in total.

User avatar
Marcus Tettmar
Site Admin
Posts: 7393
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Mon Jun 27, 2011 6:54 pm

Hi,

I'm still not with you:

1. Macro> can accept a variable for the filename:

Let>example_file=c:\somewhere\file.scp
Macro>example_file

2. Your original post seemed to suggest you wanted the Macro command to be able run a block of code defined under a label, just as LabelToVar can read a label block of data into a Label. If this is the case then how is this different to GoSub and a subroutine (it's not surely).
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

schwander
Junior Coder
Posts: 29
Joined: Tue Jun 14, 2011 6:32 am

Post by schwander » Mon Jun 27, 2011 7:14 pm

Ok, forget about LabelToVar
So, the code below shows how the current version of MS dials with encrypted script

Code: Select all

ReadFile>FileName_of_Encrypted_Macro,Encrypted_Macro_Var
Crypt>EncriptionKey,%Encrypted_Macro_Var%,Target_Variable
WriteLn>TargetFileName,ResultVar,%Target_Variable%
Macro>TargetFileName
Run>Safe_Remove_Application.exe /TargetFileName
I suggests the next

Code: Select all

ReadFile>FileName_of_Encrypted_Macro,Encrypted_Macro_Var
Crypt>EncriptionKey,%Encrypted_Macro_Var%,Target_Variable
Macro>%Target_Variable%

User avatar
Marcus Tettmar
Site Admin
Posts: 7393
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Tue Jun 28, 2011 8:32 am

Ok, now I see what you mean and what you want to do. The LabelToVar thing really threw me!

Right now I would say if you want to obfuscate/protect your code you should be using the compiler and just compile to a .exe. You can still use script library files using Include and compile them statically, so that they are inside the .exe and protected.

The SDK also gives you the ability to run code in memory (use the RunCode method).

Of course you could also place ALL your code inside one encrypted macro and instead of using Macro> calls put the code from the file you are calling inside a subroutine and call it with GoSub instead. Then you just have one encrypted and protected file.
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

schwander
Junior Coder
Posts: 29
Joined: Tue Jun 14, 2011 6:32 am

Post by schwander » Wed Jun 29, 2011 1:08 pm

Hi,
I have not yet matured enough to work with the SDK.
The above example is the case of excessive assurance. Far more dangerous is the situation where the macro is interrupted by the user (or in case of program bug) and the temporary file of decrypted script remains on the hard disk.

Actually, it would be not bad to use variables in some other cases

FindImagePos>NeedleFile_Variable,SCREEN,,,
LibFunc>TestDLL_Variable,,,,

For example:

Code: Select all

LabelToVar>NeedleFile.BMP_DATA,NeedleFile_Variable,,,
/*
NeedleFile.BMP_DATA:
Some code
*/
FindImagePos>NeedleFile_Variable,HaystackFile(or SCREEN),,,

User avatar
JRL
Automation Wizard
Posts: 3524
Joined: Mon Jan 10, 2005 6:22 pm
Location: Iowa

Post by JRL » Wed Jun 29, 2011 2:16 pm

Far more dangerous is the situation where the macro is interrupted by the user (or in case of program bug) and the temporary file of decrypted script remains on the hard disk.
I didn't go through the steps of creating an encrypted script then decrypting it. The following sample goes back to your LabelToVar example.

If you use the include> function rather than the Macro> function you can delete the script immediately after creation. Make the first line of the script being written to disk a deleteFile> function that deletes its own script. In this way the script exists on the disk for a fraction of a second.

It is true this is not absolutely secure, A very astute user might possibly use a program to wait for the file to exist and grab it during its one hundredthousanth of a second life time. To help prevent this you could also randomize the file name and location.

Still not secure because the file did exist on disk and that same astute user might find it using a deleted file recovery tool. So the second line of the script should be a WriteLn> that writes gibberish to the script file name thus preventing anyone whose resources fall short of a major government from recovering the original file contents. If you do that you would of course add another DeleteFile> after writing the gibberish.




Code: Select all

/*
CodeSample:
DeleteFile>vFileName
Dialog>Dialog1
object Dialog1: TForm
  Left = 337
  Top = 166
  Caption = 'Sample'
  ClientHeight = 131
  ClientWidth = 162
  object Label1: TLabel
    Left = 48
    Top = 8
    Width = 55
    Height = 13
    Caption = 'Data to use'
  end
  object Edit1: TEdit
    Left = 23
    Top = 34
    Width = 121
    Height = 21
  end
  object MSButton1: tMSButton
    Left = 41
    Top = 74
    Width = 75
    Height = 25
    Caption = 'Process'
  end
end
EndDialog>Dialog1

AddDialogHandler>Dialog1,,OnClose,Quit
AddDialogHandler>Dialog1,msButton1,OnClick,Process

Show>Dialog1,res1

SRT>Quit
  Exit>0
END>Quit

SRT>Process
  GetDialogProperty>Dialog1,Edit1,Text,vData
  MDL>vData
END>Process
*/

Let>vFileName=%temp_Dir%LTV-Inc-sample.scp

LabelToVar>CodeSample,vCodeToWrite
WriteLn>vFileName,wres,vCodeToWrite
Include>vFileName





schwander
Junior Coder
Posts: 29
Joined: Tue Jun 14, 2011 6:32 am

Post by schwander » Wed Jun 29, 2011 2:49 pm

Hi, Dick
Thanks for advice.
But my posts above are enhancement suggestions. Not an issue report.
Best regards.

User avatar
JRL
Automation Wizard
Posts: 3524
Joined: Mon Jan 10, 2005 6:22 pm
Location: Iowa

Post by JRL » Wed Jun 29, 2011 3:06 pm

I understand.

I like to post alternatives in the event the poster needs an immediate alternate method. Enhancements are different than bug fixes. Bug fixes are dealt with expeditiously. On the other hand an enhancement might come out with the next update. Or it might not.

User avatar
jpuziano
Automation Wizard
Posts: 1085
Joined: Sat Oct 30, 2004 12:00 am

Post by jpuziano » Mon Nov 26, 2012 9:08 pm

Hi schwander,

Thanks for posting this enhancement request.

I have a similar request only with the Include> statement... see link below:

Include> pulls script lines directly from variable [Open]
http://www.mjtnet.com/forum/include-pul ... t7513.html

Thanks and take care
jpuziano

Note: If anyone else on the planet would find the following useful...
[Open] PlayWav command that plays from embedded script data
...then please add your thoughts/support at the above post - :-)

Post Reply
Sign up to our newsletter for free automation tips, tricks & discounts