RTFC

I'm not familiar with webdriver, and I'm unable to test at the moment. But I'll bet that you can encrypt my original helloworld example just fine. One quick test would be to disable the option Remove orphaned globals and UDFs under the SingleBuild tab. You should start by doing a BackTranslate (no encryption), and check MCF0test output from that. Only if that works normally should you attempt encryption. More generally. both in BackTranslate and Encrypt, you can try to identify the problem by working in stages. You start with a working example like helloworld, and gradually add/replace more functionality from the script you wish to process(see Tab Encrypt, button UDFs). If the issue occurs only when encrypting, you can target each individual function for encryption, so with sequential testing you should be able to narrow down where the problem lies. 1.Backtranslate my helloworld, check that output works 2. Encrypt my helloworld, check again 3.Backtranslate webdriver demo, check again if it doesn't work, and you can't tell where it fails, move independent parts into helloworld step by step, and repeat. 4. If BackTr works, but encrypt does not, even with orphan removal disabled, try again with all individual functions unencrypted. When that works, start encrypting the first half of funcs only, if problems, go back a step and do the first quarter only, if still problems, encrypt one function at a time. Two steps forward, one step back, and so on. You'll need patience and perseverance. See also the suggestions in the Q & A pdf (also in the bundle). cannot guarantee that CodeCrypter will always work out of the box for every conceivable script you might throw at it. But it seems to work for most people most of the time.

The displayed error msg suggests that your test script does not contain required #include MCFinclude.au3 (anymore). Without it, CodeCrypter cannot produce an encrypted version. If you have not edited helloworld.au3 yourself, then your files may be corrupted; delete everything and re-download the package from the official Autoit repository (various idiots have posted copies elsewhere; I cannot vouch for that content). I did test the helloworld example again just now, which can be encrypted without any issues, and runs normally.

Yes, IOCTL_DISK_GET_LENGTH_INFO is a non-destructive read-only operation without any buffers; it's just a harmless query.

https://www.autoitscript.com/forum/files/file/491-codescannercrypterbundle/

@UEZ & @pixelsearch: You two are both amazing.

What you describe is called a doubly-linked list (a boost example is here, tutorial here). No need for assembly; highly optimised code for that already exists in several languages.

Please explore "parallel/concurrent processing" UDFs in the Wiki.

Bad suggestion. VB6 uses stdcall by default, and the OP shows that cdecl alternative was not used.

yap, this one for example.

My advice: don't use a zip; instead, use a proper installer that 1. creates your subdir structure and all its content wherever the user wants, 2. the content includes an .ini (text) file that your main programme reads in at startup; this contains a variable that will hold the path to the dll(s); and 3. your installer writes the actual path of the dll's to the local .ini file upon (local) installation (wherever the user wanted it to be). Personally I use Inno Setup Compiler, which is free, and setting it up is trivially easy.

Glad you got the basics to work. Regarding your question, first of all, I'm assuming you already read this part of the FAQ: The answer to your question thus relies on what your target machine(s) is/are. If you're using a hardware signature such as the C drive (or CPU) serial number, your decrypted code will only run if the target environment returns those serials when queried at your script's startup. In other words, the encrypted script is machine-specific and will only run there. But Codecrypter is far more flexible than that. For instance, suppose you only want a group of trusted friends to be able to run your code, then you could use the password option (keyID = 1) and give each of them the secret word or phrase. Or maybe you wish to limit the period of time your code is functional; then you could for example append the current Month and Year macros as your key and distribute as many copies as you like; as soon as the next month starts, all copies will stop working as the decryption no longer produces valid code (of course, if online you could query public internet clocks rather than relying on a machine's internal calendar). On a more advanced level, if you look at the key definitions in function _MCFCC_Init() in MCFinclude.au3, you'll notice that key retrieval is just a function call, and you can just as easily call your own sophisticated functions as relying on the simple examples provided. So suppose you want to set up a licensing system without storing the key in the registry of each machine where you install your programme. Then you could write a little function that instead tries to go online to connect to your own little server (see elsewhere on the forum how to set one up), and queries your database of all your customers that legally bought your software, and if matching the ID sent by your code, the server returns the decryption key(s); if no connection is made, it just produces a message that online connectivity is required for it to work and exits gracefully. Of course this setup does require your server to be online all the time, otherwise your users will get annoyed. Earlier in this thread a user requested a way to get a single, encrypted, portable executable, and they didn't care if the decryption key was discoverable, just to make it difficult enough that the average user would find it too hard to do. In that case, you could consider using the macro @AutoItExe, which returns the full path and filename of the executable of your compiled script (note that the uncompiled encrypted version then won't work(!), as the macro then returns the AutoIt interpreter's full path and name instead, so it would fail when run uncompiled from Scite). I personally wouldn't recommend this, but it's a quick and dirty fix to get some protection. Also note that the decryptor includes the path (unless you remove that part), so if the user decides to move your exeecutable to a different path, it won't work either anymore. These are just examples; your own skill and imagination (and AutoIt's own capabilities) are the only limits on what you can achieve and how to set it up. Simply put: Trusted users? Use a password; trusted/controlled environment? use system specs, hardware IDs, etc. Any other situation? Get creative.

Obviously a fully encrypted script runs more slowly than a plaincode one, as every line needs to be decrypted first! If you want to reduce slowdown, you can opt to encrypt only selected functions you wish to keep secret (see button "UDFs") or encrypt only a proportion, or every Nth line. Regarding your object issue, one line is of course totally inadequate for any kind of test (and I have no idea what "catton" is). I would need from you the smallest possible test script that runs normally when unencrypted and fails when encrypted.

ConsoleWrite("This " & @CRLF) Switch @error Case 0 ConsoleWrite("works" & @CRLF) Case Else ConsoleWrite("fails" & @CRLF) EndSwitch

Hi @habsi; welcome to the forum. In the CodeCrypter FAQ pdf (part of the bundle) you'll find an extensive description how to identify and fix issues. For example, have you tested that a BackTranslated version of your script (instead of an encrypted one) does work? If obfuscation is enabled, does the issue persist when this is disabled? If your script is larger than, say, fifty lines, then you should first create the smallest-possible reproducer test script (throw out all code that has nothing to do with the error and/or the targeted object), and test that script instead. If you then still can't figure out what's going wrong, then you could post that tiny reproducer script (which has to run in Scite without external dependencies) in this thread (please use the "<>" code tags) for me to have a look at. Be aware though of what the Codecrypter FAQ states regarding CodeCrypting objects:

Better than storing a plaintext password in the registry? Asolutely. Better than using CodeCrypter? No.