CodeCrypter - Encrypt your Script

[RTFC]

@n1kobg: Sorry to hear you're having trouble using CodeScanner. As you can see when you study the script, it uses a bog-standard FileOpenDialog call to get the target file to work on. So I would suggest you check whether the same problem occurs in a small test script (for example, the Help file example for FileOpenDialog). I tested what you describe, but am unable to reproduce this in my own environment (on W10 Pro/64). If it is indeed related to (changed?) permissions on your machine, you could try running it from a different drive, or some subdir of MyDocuments or somewhere else that should always be accessible without admin/system rights. CodeScanner itself does not use #RequireAdmin, but it does attempt to create a new subdirectory to store its various log/MCF files.

Edited December 3, 2020 by RTFC

[n1kobg]

The scan lasts 27 seconds and gives me a lot of potential issues (Number of *potential* issues: 165) while there should be 3 max. I tried what you suggested but same thing happens. If its not permissions what else can it be? Does it needs a certain Service or Task to work (because i have disabled a lot of them, but it works on one of my old Windows installations whith the same tweaks but its a pain to switch them constantly). Im using the latest BETA but I dont think thats the issue since it doesnt needs to work for that.
I also have other problem. Debugging programs shows command promt & other Windows commands despite the encryption. I need some sort of Anti-Debugging.

Edited December 5, 2020 by n1kobg

[RTFC]

Sorry to hear that, but without a (tiny!) reproducer script that fails in my own test environment I cannot even begin to guess what might be your problem. CodeScanner does not need any task or service other than a basic functional Windows OS of XP or higher. Maybe you can test-run on a VM with a bare-bones Windows installation? It sounds as if your current work environment is non-standard in some way. In any case, there's nothing I can do about that, and if FileOpenDialog already produces odd behaviour, I would suggest you figure out what's causing that, before spending time on CodeScanner.

Edited December 5, 2020 by RTFC
typo

[n1kobg]

is there a way to add dynamic Ip?

 

Edited January 2, 2021 by n1kobg

[WinMacBear]

after test one simple msgbox(0,0,0)

I got the error as below:

I do not have a clue where to start with...

Will you please help? Thanks...

expandcollapse popup

Press <Enter> or double-click to activate a selection.

Root File: D:\CodeScannerCrypter.bundle.v3.3d\msg.au3
Processing time: 7.3 seconds

Number of incorporated Includes: 3
Number of Lines processed: 4944
Number of unique native AutoIt functions Used: 0
Number of unique native AutoIt functions Called: 0
Number of UDF definitions: 81
Number of Active UDFs: 65
Number of Calls: 1251
Number of Variables: 204
Number of Globals: 213
Number of UDFonly-defined Globals: 0
Number of Loops: 11
Number of Objects: 9
Number of Main Code Sections: 4
Number of Exit points: 7


Number of *potential* issues: 57

Number of #includes not found: 8
Number of duplicate func defs: 0
Number of unresolved func parameters: 0
Number of unknown functions called: 49
Number of Loop nesting issues: 0

Activate the Report Summary for additional information.

Settings
ON : Include native [...]Constants.au3 files
ON : Track native AutoIt function calls
ON : Track UDF function calls
ON : Track loop structures
ON : Extract variable names
ON : Extract literal strings
ON : Extract macros

1st try missing 8

Number of #includes not found: 8

autoitconstants.au3

stringconstants.au3

fileconstats.au3

debug.au3

array.au3

winapimisc.au3

memory.au3

after I adding these into my testing file, There are 15 not found.....

 

My OS is Windows 7 Pro

Edited January 2, 2021 by WinMacBear

[RTFC]

@n1kobg: in MCFinclude.au3, simply edit one of the $CCkey array content definitions to return @IPaddress1, or write your own little UDF to return whatever you wish to check (IP-related or otherwise), and then call that in a $CCkey entry definition. Note: don't forget to also select that entry's array index as keyID when running CodeCrypter.

@WinMacBear: Looks like your AutoIt environment is not set up properly, as your standard includes cannot be found. This is not a CodeCrypter issue at all, and CodeScanner is merely telling you that without those files, it cannot identify the functions referenced therein. Maybe you did a non-standard installation (that is, in a non-standard location)? One way to circumvent this would be to figure out where your include files are actually stored (say, C:\MyAutoItPath\Include for example), and then replacing all include lines in your script that use angled brackets (such as '#include <Array.au3>') with explicit full path references in quotation marks (without angled brackets, like so: ' #include "C:\MyAutoItPath\Include\Array.au3" ').

Edited January 2, 2021 by RTFC
typo

[WinMacBear]

my autoit install location is under "D:\Program Files (x86)\AutoIt3". I believe i only changed C:\ to D:\.

And all my other scripts are working properly.

Maybe I will try to reinstall the autoit then. Thanks.

[PLSM]

Firstly, your encryption scripts have served me well for years. Thank you.

Unfortunately Bitdefender AV is now flagging any compiled scripts which include MCFinclude as AIT:Trojan.Nymeria.4400. Anyone else getting this?

It has deleted every script I had that was encrypted. Months of work

Thanks

Edited March 2, 2021 by PLSM

[RTFC]

Glad to hear CodeCrypter has been useful to you in the past, and sorry to hear AV is causing difficulties for you now. However, I'm not in the business of trying to evade AV software, sorry. What you could try is contact Bitdefender to get your specific applications whitelisted.

[PLSM]

I have worked out it's the compiled output of AES.au3 that's causing it. To test it I compiled AES.au3 and sent it through VirusTotal.com. 20 of 68 engines found it to be malicious. Just want to be sure you are ok with me sending this AES.exe to Bitdefender to be tested? Hopefully they'll find it's nothing and amend their signatures.

[RTFC]

If it's AES, you could just switch to using only the Bcrypt option in CodeCrypter, and remove all references to AES.au3 in CodeCrypter and MCF.au3. AES itself is written by Ward, who hasn't been very active on these forums lately. I have no problem with you discussing AES with third parties, but AES is Ward's code, not mine, so you may wish to check with him first.

[Musashi]

17 minutes ago, RTFC said:

AES itself is written by Ward, who hasn't been very active on these forums lately. ... but AES is Ward's code, not mine, so you may wish to check with him first.

@PLSM : Just for your information (and to avoid the effort) :

"... Ward, who hasn't been very active..." is an understatement . Ward is absent since 2015 and, what is even more regrettable, has removed most of its attachments. It is therefore most likely impossible to get in touch with him.

[PLSM]

Ok. I have gone ahead and submitted the AES.exe to Bitdefender as a false positive.  Hopefully they will decide it is a false positive and sort their signatures. I will post an update when I know more.

Edited March 3, 2021 by PLSM

[PLSM]

Bitdefender has now come back to me and, as expected, it was confirmed as a false positive. Their AV signatures will be amended within a week.

[RTFC]

That's great news, thanks for reporting it.

I may (at some point) look into creating a CodeCrypter set-up that does not rely on AES.au3 inclusion.

[marko001]

Hi @RTFC

after running CodeCrypter, my first MCF0test.au3 is created.

If I run it I get some solvable problems (missing "[" mainly) and 2 missing functions:

 

Func _ArrayMinIndex(Const ByRef $aArray,$iCompNumeric= 0,$iStart=-1,$iEnd=-1,$iSubItem= 0)         ; {file:10}{line:813}
    If $iCompNumeric= Default Then $iCompNumeric= 0         ; {file:10}{line:814}
    If $iStart= Default Then $iStart=-1         ; {file:10}{line:815}
    If $iEnd= Default Then $iEnd=-1         ; {file:10}{line:816}
    If $iSubItem= Default Then $iSubItem= 0         ; {file:10}{line:817}
    Local $iRet=__Array_MinMaxIndex($aArray,$iCompNumeric,$iStart,$iEnd,$iSubItem, __Array_LessThan )         ; {file:10}{line:818}
    Return SetError(@error, 0 ,$iRet)         ; {file:10}{line:819}
EndFunc          ; {file:10}{line:820}

"Y:\__ AutoIt\MCF0test.au3"(416,98) : error: __Array_LessThan(): undefined function.
    Local $iRet=__Array_MinMaxIndex($aArray,$iCompNumeric,$iStart,$iEnd,$iSubItem, __Array_LessThan )

then

OnAutoItExitRegister( _Resource_DestroyAll )         ; {file:13}{line:18}

"Y:\__ AutoIt\MCF0test.au3"(2970,44) : error: _Resource_DestroyAll(): undefined function.
OnAutoItExitRegister( _Resource_DestroyAll )

and

Func _XML_GetValue(ByRef $oXmlDoc,$sXPath)         ; {file:18}{line:1281}
    Local $oXML_COM_ErrorHandler=ObjEvent("AutoIt.Error", __XML_ComErrorHandler_InternalFunction )         ; {file:18}{line:1283}
    #forceref $oXML_COM_ErrorHandler         ; {file:18}{line:1284}
    Local $oNodes_coll=_XML_SelectNodes($oXmlDoc,$sXPath)         ; {file:18}{line:1286}
    If @error Then Return SetError(@error,@extended,$XML_RET_FAILURE)         ; {file:18}{line:1287}
    Local $aResponse[1]         ; {file:18}{line:1289}
    For $oNode_enum In $oNodes_coll         ; {file:18}{line:1290}
    If $oNode_enum.hasChildNodes () Then          ; {file:18}{line:1291}
    For $oNode_enum_Child In $oNode_enum.childNodes ()         ; {file:18}{line:1292}
    If $oNode_enum_Child.nodeType=$XML_NODE_CDATA_SECTION Then         ; {file:18}{line:1293}
    _XML_Array_AddName($aResponse,$oNode_enum_Child.data)         ; {file:18}{line:1294}
    ElseIf $oNode_enum_Child.nodeType=$XML_NODE_TEXT Then         ; {file:18}{line:1295}
    _XML_Array_AddName($aResponse,$oNode_enum_Child.text)         ; {file:18}{line:1296}
    EndIf         ; {file:18}{line:1297}
    Next         ; {file:18}{line:1298}
    Else         ; {file:18}{line:1299}
    _XML_Array_AddName($aResponse,$oNode_enum.nodeValue)         ; {file:18}{line:1300}
    EndIf         ; {file:18}{line:1301}
    Next         ; {file:18}{line:1302}
    $aResponse[ 0 ]=UBound($aResponse)- 1          ; {file:18}{line:1304}
    Return SetError($XML_ERR_SUCCESS,$XML_EXT_DEFAULT,$aResponse)         ; {file:18}{line:1305}
EndFunc          ; {file:18}{line:1306}

"Y:\__ AutoIt\MCF0test.au3"(3983,95) : error: __XML_ComErrorHandler_InternalFunction(): undefined function.
    Local $oXML_COM_ErrorHandler=ObjEvent("AutoIt.Error", __XML_ComErrorHandler_InternalFunction )

How can I solve it? 

Thanks,

Marco

Edited June 18, 2021 by marko001

[RTFC]

On 6/30/2020 at 9:53 AM, RTFC said:

Three strikes, and you're out. I won't be helping you again.

 

[Lion66]

Hi @RTFC

I want to thank you for this library. She was useful for me.

A few questions.

1. Why is the multi-line style specified in the lines 2640 and 2653 (codecrypter.au3 (Release........: 3.3, Decryptor ...):

BitOR($ES_MULTILINE, $WS_HSCROLL)

It does not allow to select by mouse the second input to confirm password. Only by press to Enter key or Tab.

2. When using an Encrypt with x86-x64 option, I get an error when starting the resulting script.

$B2F4011173F28174=$tUlong.value
warning: $tUlong: possibly used before declaration.

Edit: This is about it?

Ward’s AES encryption UDF has an unresolved issue in 64-bit environments
that awaits a fix.

I do not understand how to fix it?

3. I do not see the option will add string (Salt), for example to @Username (key Id = 3).

It would be stronger than just the username.

Theoretically, if the cracker knows that the script is encrypted with this UDF, then it goes through the options from Key ID 2 to 7 and can decrypt the code.
Or is it wrong?

Thanks.

Edit:

The third question I decided after reading the file CodeCrypterFAQ.pdf.

After adding a new key to the file MCFinclude.au3

$CCkey[8] = @UserName & $String

, it was necessary to start the Codescanner again. Not only Codecrypter.

 

Edited November 13, 2021 by Lion66

[RTFC]

Thanks for your questions, @Lion66. Answering these in order:

ad 1) no particular reason; that was just the standard template I used for GUI inputs. In this context it serves no purpose; just ignore it.

ad 2) It looks like you are combining obfuscation with object/struct member access, which is an unsafe practice (as detailed in the Remarks section). Object support is fairly limited in Coderypter, and may require you to do some manual patching of the string tables before generating the final output. I am guessing that your member variable $tUlong is elsewhere being obfuscated, but I really cannot tell from your limited info (one line of code does not amount to a reproducer-script for testing). My advice would be to dispense with obfuscation altogether (you don't really need it if you're encrypting). The 32/64-bit issue is unrelated (just use x64 option if you can to avoid that; only use Ward's algorithm if your code has to run on 32-bit OS/machine).

ad 3) the $CClist entries in MCFinclude are just examples to illustrate how to set up your own encryption keys; it's entirely up to you whether and how you expand upon that basic functionality (adding a salt, as you suggest, would be one such enhancement); feel free to implement whatever works for you. But it's not up to me to cater to each individual user's requirements in this respect; the whole point of CodeCrypter is that you make your encryption keys unique.

On 11/12/2021 at 10:02 PM, Lion66 said:

Theoretically, if the cracker knows that the script is encrypted with this UDF, then it goes through the options from Key ID 2 to 7 and can decrypt the code.
Or is it wrong?

Wrong. Even if a hacker gains access to the contents of your $CClist, the worst possible scenario is that they figure out what is being queried from the environment at runtime, but never, ever what the environment is expected to return for that query (this is not stored anywhere). Codecrypter creates an executable that functions only in a "sanctioned environment" (where the environment returns the correct decryption key(s)); anywhere else it should return something different, which then fails to decrypt your encrypted script. This is explained in great detail in the FAQ (which you say you've read; quoting a relevant paragraph here:).

Spoiler

You can think of the array $CCkey in MCFinclude.au3 as a list of instructions to construct a secret phrase (the decryption key). For example:

• go to the library, find the first red book on the top shelf in the cabinet left of the largest window, take the 7th word of the 3rd paragraph on page 123;

• use the name of the only black pet in the house;

• take the first letter of each word of the saying on the plaque over the kitchen door

• take the word for the material of the bedspread in the main guest room

• etcetera (you can define these instructions yourself, adding as many as you like)

When your proverbial hacker steals your executable, even though this list is itself also encrypted (with a fixed key; there's no other way), they may be able to decipher the list itself, or monitor the location in RAM where the result of these instructions is stored. But such an instruction itself no longer makes sense if it's referenced in any other house! There, the guestroom bedspread may be a different type of cloth, there may not be any house pet, let alone a black one, or even if so, it's name is likely different. Thus your hacker can monitor all they want, but garbage in = garbage out, meaning the decryption key does not match, therefore no sensible AutoIt code comes out of the decrpytor, just gibberish that causes the programme to halt immediately. So yes, "the data" (that is, the encrypted line and the "secret phrase" as extracted locally from the work environment) are indeed "injected in memory", but this information is completely useless when the secret phrase is different because the environment is different. There is no hint whatsoever inside your script what name your black pet actually has; there never was, and never will be. What is absent to begin with cannot ever be extracted. Your only responsibility is to select or define an instruction (or combination of several) that is unique (or very rare), and unobtainable without access to the original environment.

 

On 11/12/2021 at 10:02 PM, Lion66 said:

After adding a new key to the file MCFinclude.au3, it was necessary to start the Codescanner again. Not only Codecrypter

Yes, obviously, since $CCkey is part of MCFinclude.au3 which is included in your source script. How would CodeCrypter know about the changes you've made if CodeScanner hasn't had the chance to update the MCF files first?! You have to keep in mind that CodeCrypter doesn't read/see your original script, but only the MCF files that CodeScanner produces. So you have to think of encryption as similar to a compiler pass; you wouldn't expect your executables to reflect a later change you made to an #include until you recompiled any script that includes it, would you?

Edited November 15, 2021 by RTFC

[Lion66]

8 hours ago, RTFC said:

My advice would be to dispense with obfuscation altogether (you don't really need it if you're encrypting).

I did not know that. Then consider separately.

Obfuscation.
In any code after obfuscation adds an string, which causes a mistake.

$0B74769B07BE21B9=$tUlong.value

But deleting a line does not cause problems with the script. So there's no problem.

Encrypt.
All analogies with a book and a cat mean to come up with a unique string for a key? Or you mean something else?
Then the key will be inside the code. But I understand that I still can't decrypt it from this code:

Local $String=Execute(_MCFCNG('0x55034992E6E43B9DCC6666078D11D938EF7CC2730A1740383D32753A41F62F18CF7BD39F39168E829E852E8549E5192D'))
$CCkey[8]=$String