Enhancement for Macro command

schwander · 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

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?

schwander · 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.?

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.

schwander · 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.

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).

schwander · 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%

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.

schwander · 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),,,

JRL · 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 · 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.

JRL · 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.

jpuziano · 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