CodeCrypter - Encrypt your Script

[souldjer777]

LOL, dude that's hilarious  and thank you again!

Tactical nuclear warfare against household pests For Dummies, chapter 23...

[souldjer777]

Good Morning RTFC,

I again appreciate all the help  

On that extremely long x64 string... getting the following after successfully running codescanner / codecrypter and then attempting to compile.

MCF0test.au3"(1428,1027) : error: syntax error (illegal character)

Line ends in

IP_Rangescsv&=_MCFCC("0xE97     ...   " & _
"30835 ... 3C910DD" & _
"510AD ... 919F749" & _
"11709 ...  FA451FD" & _
"01327F .... 11631DEC"," & _ 
"1)

I replaced all the files from your new zip file in my Includes directory.

My fix was...

IP_Rangescsv&=_MCFCC("0xE97     ...   " & _
"30835 ... 3C910DD" & _
"510AD ... 919F749" & _
"11709 ...  FA451FD" & _ 
"01327F .... 11631DEC" & _
", 1")

Thanks RTFC!!!

[RTFC]

I think I should hire you as my personal beta tester, souldjer777; you have a knack for finding unlikely edge cases.

Please try the latest version of the bundle (1.5).

[souldjer777]

Worked like a charm! Thank you x 1,000,000 

[Hackhers]

I cant make it work, I have tried bunch of things. I really cant understand what metadata and how to open it. But It seems its open already for me. (See: http://prntscr.com/8carro) 

After that I open codecrypter.au3 with these options http://prntscr.com/8cas85

Finally I got the error: http://prntscr.com/8casje
 

I use windows 10

Edited September 3, 2015 by Hackhers

[RTFC]

@Hackhers: you shouldn't have to engage with the metadata at all, or open any metadata files (unless you wish to engage in low-level tinkering with the contents yourself). And I don't think Win10 is the problem (but thanks for the info; my test environment is now Win10 too). Your third screenshot suggests that a (reconstructed) line is either too long or a termination thereof is somehow missed.

If you post the smallest possible reproducer script, I may be able to figure out what's the problem. I'll be happy to help, but you've got to meet me halfway. So please do some tests first to narrow down the issue:

Try codescanning+backtranslating this single-line script: Msgbox(0,"test","Hello World")

Does that fail? Then there's something fundamentally wrong with your set-up/environment. Does it work? Then it's something particular about your own script. So then you start disabling large chunks of your script, replacing real function calls with dummy calls, etc., to identify what particular sequence/statement/region generates the problem. Then you repeat at a finer scale. The issue may be in your script, or in CodeScanner misinterpreting your script, or CodeCrypter/MCF failing to rebuild it correctly. After Codecrypter trips up, check the contents of MCF0test.au3, and check the logfile MCFencoding.log in your script's CS_DATA subdirectory. That should give you an idea where the problem arises.

I appreciate the screenshots, but they are insufficient to identify the issue. Once you've narrowed it down to a reproducer script of a few dozen lines at most, I'll have a look at it if you post it.

[Hackhers]

@Hackhers: you shouldn't have to engage with the metadata at all, or open any metadata files (unless you wish to engage in low-level tinkering with the contents yourself). And I don't think Win10 is the problem (but thanks for the info; my test environment is now Win10 too). Your third screenshot suggests that a (reconstructed) line is either too long or a termination thereof is somehow missed.

If you post the smallest possible reproducer script, I may be able to figure out what's the problem. I'll be happy to help, but you've got to meet me halfway. So please do some tests first to narrow down the issue:

Try codescanning+backtranslating this single-line script: Msgbox(0,"test","Hello World")

Does that fail? Then there's something fundamentally wrong with your set-up/environment. Does it work? Then it's something particular about your own script. So then you start disabling large chunks of your script, replacing real function calls with dummy calls, etc., to identify what particular sequence/statement/region generates the problem. Then you repeat at a finer scale. The issue may be in your script, or in CodeScanner misinterpreting your script, or CodeCrypter/MCF failing to rebuild it correctly. After Codecrypter trips up, check the contents of MCF0test.au3, and check the logfile MCFencoding.log in your script's CS_DATA subdirectory. That should give you an idea where the problem arises.

I appreciate the screenshots, but they are insufficient to identify the issue. Once you've narrowed it down to a reproducer script of a few dozen lines at most, I'll have a look at it if you post it.

Hey, I adressed the issue. It's problem with Curl.au3 library. You can get it from over here https://www.autoitscript.com/forum/topic/173067-curl-udf-autoit-binary-code-version-of-libcurl-with-ssl-support/

[RTFC]

Well done, Hackhers.
 I can reproduce the bug with Ward's curl example scripts, and I've identified the problem.

Please stand by while we improve your CodeCrypter experience....

[RTFC]

@Hackhers: Okay, it is not trivial, but it can be fixed. Please follow these steps:

1) download the latest version (1.6) of the CodeScannerCrypter bundle

2) Open Ward's Curl.au3 and find the line that starts with:

Global Enum _
 $CURLOPT_WRITEDATA = $CURLOPTTYPE_OBJECTPOINT + 1, _

This Enum statement goes on for about two hundred lines, so it's not surprising that CodeCrypter complains when it tries to construct a single line from all those parts. You have to break up this definition into several (ca. 5-10) separate ones. To do this, go down about twenty lines, remove the tail end of that line, i.e., remove <comma><space><underscore>,insert a new empty line below it, and fill it with:

Global Enum _

Then repeat that step every twenty-thirty lines or so, until you reach the end of that statement. Save Curl.au3 and close it.

3) Run CodeScanner anew on your script.

4) Start Codecrypter and navigate to Tab Single-Build. Uncheck the tickbox: "Skip redundant UDF defs". Under Tab Main , load your source script, and enable only "Create MCF0," then run it.

5) Open the CS_data subdirectory of your script. Delete StringsUsed.txt, then copy StringsUsed_CS.txt as StringsUsed.txt. This is done to restore the original binarycall names in Curl's SymbolList. CodeCrypter/MCF normally replaces all function names with metacode {func##}, and the official func names are capitalised, whereas the binary version is lower-case, so finding the official func names would fail. This is why we have to restore the original strings as-is.

6) In CodeCrypter, now disable Main option "Create MCf0", and enable option "BackTranslate." Run it. That should do it.

After adding MCFinclude.au3 to Ward's Curl_Example_Easy,au3, I also tested that encryption works for Curl.

Hope it helps.

RT

Edited September 5, 2015 by RTFC

[Hackhers]

Well done, Hackhers.
 I can reproduce the bug with Ward's curl example scripts, and I've identified the problem.

Please stand by while we improve your CodeCrypter experience....

I really appreciate your work  Even AutoIt cant handle this error, because of that long line AutoIt gives wrong line number. It sees that line as 1 line but In editör It's not

[RTFC]

You're welcome, Hackhers.

Forgot to mention two things. Firstly, The fix of curl.au3 is obviously a target script patch, not a generic solution for all scripts that involve hundreds of lines of catenated global Enums (which in this case, do not even enumerate, because the values are explicitly assigned.)  I reckoned that very few people use Enum to begin with, and even fewer would resort to this kind of excessive line chaining. So for other people encountering this situation in future, please patch your target script in the manner advertised above. Creating a structural fix to detect and deal with this extremely rare scenario is a bit too much work for my weak and lazy brain.

Secondly, the curl patch is one-off (edit once, solved forever), but replacing stringUsed.txt with stringUsed_CS.txt you would have to repeat whenever you run a script through CodeCrypter that includes Ward's curl.au3. I'll add another switch to CodeCrypter/MCF in future to have the option of disabling this function name replacement that is messing with the symbol-list look-up. Not sure it's worth the effort, but it's easy to add... Alternatively, a durable fix would be to make all function names in the curl bundle completely lower-case everywhere.

 

Oh yeah, and obfuscating the function names won't work here, of course, as some of these are actually machine code calls in the embedded binary code.

Edited September 5, 2015 by RTFC
typos, addendum

[souldjer777]

Howdy RTFC,

Long time - no talk to  

Having an issue with encrypting (using your latest 1,6 and AutoIT 3.3.14.2)

These are the includes I'm using

#include <Array.au3>
#include <ButtonConstants.au3>
#include <ComboConstants.au3>
#include <Date.au3>
#include <EditConstants.au3>
#include <File.au3>
#include <FileConstants.au3>
#include <GUIConstantsEx.au3>
#include <GuiEdit.au3>
#include <MsgBoxConstants.au3>
#include <OutlookEX.au3>
#include <ScrollBarsConstants.au3>
#include <StaticConstants.au3>
#include <String.au3>
#Include <WinAPI.au3>
#include <WindowsConstants.au3>
#include <MCFinclude.au3>

I'm wondering if one of these includes is tripping up the encryption process as the Code Scanner passes with no issues to report.

Congratulations! No issues detected. / No problemo

codecrypter cruises through okay as well...

MCF0test.au3

It's just when I compile that _AES_Startup() 

"C:\temp\MCF0test.au3"(2135,2064) : warning: $Code already declared/assigned

"C:\temp\MCF0test.au3"(2172,19) : warning: $KeyLen already declared/assigned

"C:\temp\MCF0test.au3"(2281,1646) : warning: $Opcode already declared/assigned

I know how one error can make it look like many... just a little lost here.

Thanks!

[RTFC]

Howdy souldjer777,

Well, that was an interesting diversion. You were right in identifying the includes as the problem, more specifically, it's caused by water's OutlookEx.au3, which I'd like to emphasise is not a standard AutoIt include but a member contribution. And although I have the greatest respect for water, I was disconcerted to find at the top of OutlookEx, these charming, innocent-looking lines:

#AutoIt3Wrapper_Au3Check_Parameters= -d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6
#AutoIt3Wrapper_Au3Check_Stop_OnWarning=Y

You'll have noticed that warnings were produced by AU3check, not errors, so your script would still compile and work normally if it had been allowed to proceed. Moreover, a quick inspection of Ward's AES.au3 will show you that it's just because Ward uses multiple conditional instances of declaring the listed variables locally (If(...) Local $var=X, Else, Local $var=Y, etc.

Now, because of "#AutoIt3Wrapper_Au3Check_Stop_OnWarning=Y", any warning would stop compilation, and all warning types 1-6 are enabled by water here, including w3, which is triggered upon multiple definition lines such as Ward used. Since most #directives are retained by the Codescanner/Crypter process, these lines turn up in the final output. Note that the same problem occurs in Codecrypter backtranslation (something you should have  checked yourself, grumble, grumble), i.e., it's got nothing to do with encryption whatsover (except for encryption requiring AES.au3, and this include contains the lines that trigger warning 3). With me so far?

Why does this not occur when you au3check/compile the original script? Because such directives are probably ignored if they occur in an #include file, and only considered when they are stated in the main script. In fact, when I add those two lines I quoted above to my bog-standard helloworld.au3 test script (NB without OutlookEx.au3 being included), that original script stumbles in exactly the same way (i.e., without Codecrypting it) as yours does after CodeCrypting it (MCF0test.au3). You have to remember that the fundamental difference between any original script and its Codecrypted equivalent is that it has become a single file without any includes. So any stray Au3Check directives in included UDF libaries and such will now be active, causing your issue in this case. The solution is of course obvious; just remove those offending #directives from your OutlookEx.au3. I suppose I could in a future update explicitly remove such directives from all includes, I guess. So thanks for making me aware of this. However, I don't consider it a major flaw that warrants an immediate new release. I hope this clarifies your issue; a trivial one-time edit of OutlookEx should solve it.

Edited January 22, 2016 by RTFC
typos, clarification

[legend]

RTFC it's a nice idea, but in my opinion an obfoscator would be better, since the protection of encrypting can be decrypted in less than 20 seconds.

You can dump the process from windows taskmanager, and grab unencrypted script with a hex editor.

 

You should instead work on a obfuscator

[RTFC]

@legend: Wow, that's a pretty bold claim. Care to back it up with real evidence? Because when I examine a task manager  dump of a compiled Codecrypted script, I can find no trace whatsoever of, for example, a "Hello, world!" or "This is an Example" strings in the example below:

#include <GUIConstantsEx.au3>
#include <MCFinclude.au3>

MsgBox (0, "Test","Hello, World!")

Example()

Func Example()  ; adapted from Help file, first example for GuiCreate
    Local $hGUI = GUICreate("This is an Example")
    Local $idOK = GUICtrlCreateButton("Press to Quit", 140, 200, 120, 30)

    GUISetState(@SW_SHOW, $hGUI)

    While 1
        Switch GUIGetMsg()
            Case $GUI_EVENT_CLOSE, $idOK
                ExitLoop

        EndSwitch
    WEnd

    GUIDelete($hGUI)
EndFunc   ;==>Example

Re. obfuscation, Codecrypter already provides substantial support for that, also independently of encryption (if you don't want to use that, which is of course entirely up to you). Obfuscation currently covers both variable names and function names; what other parts of the language would you want it to support?

To be honest, I cannot see how the "unencrypted script can be grabbed," as you claim, because the unencrypted script does not exist in the Codecrypted version, only as individual decryption calls for each line, that are only ever executed one by one, and only in memory, based upon a dynamic key that is only ever defined at runtime, and again, only in memory (and outside of the sanctioned environment, that key would be wrong). So I'm having trouble understanding how you can possibly extract and store a full unencrypted script that was never present in full unencrypted form in the excutable to begin with.

Incidentally, you're skirting dangerously close to the prohibited topic of decompilation of AutoIt scripts here. But I'll leave that up to the forum moderators, as I appreciate that you may have legitimate concerns about whether an encrypted script is adequately protected (as you have expressed earlier). I've explained in the past under what specific cirumstances there may be a risk of a successful attack (notably, unfettered access by an attacker to the target machine on which the script is allowed to run), but 1) after studying several task manager dumps without finding a trace of plaintext code that was originally encrypted, 2) knowing that Codecrypter's decryption never, ever creates the entire unencrypted script as a single entity, and 3) decryption itself will produce utter garbage in any environment that does not match the sanctioned one in terms of the environment-dependent decryption key, I currently cannot see how you can possibly be right. But please enlighten me if I'm wrong; if it really were that easy to retrieve a complete unencrypted script, then I needn't have bothered. But it'll take more than that short last post of yours to convince me.

Edited January 24, 2016 by RTFC
clarification

[souldjer777]

Thank you very much RTFC  I'm going to give it a shot!

I figured it was the Outlook include - but didn't know why  

#AutoIt3Wrapper_Au3Check_Parameters= -d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6
#AutoIt3Wrapper_Au3Check_Stop_OnWarning=Y

Can I just comment those two lines out?

Wish me luck!

Edited January 25, 2016 by souldjer777

[RTFC]

Yeah, you can comment those lines out. Actually, you need only disable the second one. Alternatively, you can patch CodeScanner (not Crypter), if you go to function _ScanFile, find the comment "; skip some special lines completely" and then add this line at the bottom (before the next comment line):

If $fileIndex>1 And StringLeft($line,16)="#AutoIt3Wrapper_" Then ContinueLoop

That should resolve not just this particular issue but all similar ones in future too. Tihs patch will be included in the next Codescanner version, but it may be some time yet before the next bundle release.

Hope it helps.

[souldjer777]

Thank you so much RTFC!  I really appreciate all the help!!!

Sorry for not trying to backtranslate - but sometimes I can spend hours looking at something and get nowhere...

(or for that matter days (ouch)) 

You rock  I'll give that a try as well 

 

[RTFC]

I realise Backtranslation may seem like a pain and a waste of time. But it's the simplest way to tell at what stage something went wrong, either:

• when CodeScanner took your script apart, and meta-encoded it (if the backtranslated script fails), OR...
• when CodeCrypter replaced original content with altered bits and bobs (translation, obfuscation, encryption...).

And given that you originally suspected encryption to be the cause of your problem (as CodeScanner reported no problems), a backtranslation test would have instantly told you that that was not the case (beause the backtranslated version would have errored out as well). Of course, my secret, totally selfish underlying reason to advocate doing this is that it saves me time as well. And I've had cases where I really had to open two Scites side by site (Scite-by-Scite?) and compare the backtranslated and original version line by line, to find where Codescanner had missed a beat (or a complete drum solo).

But don't worry too much about it; it's also an excuse for me to be able to moan.

[souldjer777]

Thanks for posting the new update RTFC  30 Jan 2016

I have multiple lines of code that wrap with " & _" Am I reaching a variable limit here? Notepad++ shows 1000+ characters. 

Local $sVariable01 = "Some text is here:" & @CRLF & _
"Some more text is here.... this goes on for a while bla bla bla bla bla." & @CRLF & _
"Some more text is here.... this goes on for a while bla bla bla bla bla." & @CRLF & _
"Some more text is here...  this goes on for a while bla bla bla bla bla. this goes on for a while bla bla bla bla bla." & @CRLF & _
"Some more text is here....this goes on for a while bla bla bla bla bla." & @CRLF & _
"Some more text is here....this goes on for a while bla bla bla bla bla." & @CRLF & _
@CRLF & "MORE INFORMATION IS HERE" & @CRLF & _
"Some more text is here....this goes on for a while bla bla bla bla bla.this goes on for a while bla bla bla bla bla." & @CRLF & @CRLF & _
"Some more text is here....this goes on for a while bla bla bla bla bla.this goes on for a while bla bla bla bla bla." & @CRLF & @CRLF & _
"Some more text is here....this goes on for a while bla bla bla bla bla." & @CRLF & "this goes on for a while bla bla bla bla bla." & @CRLF

I am getting an error where I don't believe the code is wrapped back correctly ...

_MCFCC("0x3C76C28D88684FAA6C86AC2121C86AEA3C5EEDA22385D182F324B9C67106B36A800BAC4B51A03D3360B0E29E900B1073582CF63B34EC95DBFE7205D67C99332F",1)&Execut"
error: syntax error (illegal character)
"e(_MCFCC("0x6AECD2D24ABCDADBF83175C11D540D08CF173E26A952A4E5993EC5F78572474A",1
error: Statement cannot be just an expression. (illegal character)

I'll remedy myself if I can but just giving you a heads up.

UPDATE: just back spaced a couple times to put the "Execute" together and I'm compile okay

Edited February 3, 2016 by souldjer777