RTFC

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.

In that case you might want to look into using CodeCrypter with keyID=1 (password query).

Good day to you too. My day was crap, thank you for asking. A1: first read this. So given you're running in a 64-bit environment, call _WinAPI_Wow64EnableWow64FsRedirection with parameter True if you wish to use the legacy 32-bit Windwos system dll's, and False (or don't call it) if you know you can use the newer 64-bit versions that are native to x64 Windows. Basically if you use legacy code yourself that relies on the old 32-bit Windows dll's, you'd want to set this, otherwise leave it be. A2: the #include keyword followed by a filename (in quotation marks, or between angled brackets if it's a native AutoIt #include) does exactly that (assuming that the file is found, that is): it takes the contents of that file and inserts these as one giant copy-paste into the master script that will be compiled/executed. most include's are function libraries whose functions can thereafter be called by other parts of your code, but you could use it to insert the complete works of Shakespeare if you like (but as a (rather large) comment section, otherwise the compiler will complain, because it hates Shakespeare (as it doesn't really understand it)). Note that the included text (whatever it is) is inserted at the exact point where the #include statement was in your original script, which can be important (if you're #including raw lines of code, for example). So don't place an #include in the middle of another function, unless you know what you're doing. You can run Au3Stripper (either at the cmdline or from (full) Scite4AutoIt) to produce the single script with all required parts of the #includes added (and the #include statements removed). Compare and contrast with the original source for hours of fun.

I think you may have misinterpreted/overestimated the (very limited) "command" functionality its editor implements; these are mostly startup cmdline options that you can set/change at runtime, and stuff like taking screenshots at some specific resolution. To do the things you want to do in a development environment (i.e., uncooked, unpacked application), by far the easiest way is to create a new, or edit an existing blueprint. Blueprints were explicitly designed for people that are uncomfortable writing code (e.g., most game designers). It's incredibly simple to learn, just connect event/function nodes with their Exec pins to form a flow diagram in the BP, and stick variables into your inputs (or read them from node outputs) where required/desired. Example: You wrote you need JSON interaction. So open your project, Top Menu->Edit->Plugins, search "JSON", then enable (tick) "JSON Blueprint Utilities" (available for free), and confirm. Restart the Engine, open any blueprint (or create a new one), right-click anywhere on the background, type json in the new window's search bar, and select any of these functions: There are literally hundreds of video tutorials online to get you up to speed in a matter of a few hours. And as long as your tasks are not frame-critical, you don't need to engage with the underlying C++ code at all.

I have trouble understanding why you would wish to automate Unreal Editor; that's like wanting to automate Scite to write an AutoIt script. If you have access to the uncooked, unpackaged project, it makes more sense to directly edit the blueprints (or add your own BPs to run alongside, or edit/add to project source code) to achieve your goals: JSON: there are several JSON plugins available out of the (UE) box to interact with JSON data (Edit->Plugins->Search "JSON", and several more on the marketplace start/stop: just run the editor headless from the cmdline with the appropriate settings (e.g., if you launch the editor with -game this would act the same as choosing the standalone launch option in the editor) the output log is already written to file (in <YourProjectFolder>\Saves\Logs), or in the Output Log window, click Settings->Open in External editor. Moreover, automating UE editor seems a terrible idea to me anyway, because its GUI layout/ menu organsiation tends to change (sometimes drastically) with almost every engine update (of which there are several a year).

It helps if you open the dll first. #include "zlib_udf.au3" Local $sData = 'hahahahahahahahahahahehe' Local $bData = StringToBinary($sData) Local $tBuffer = DllStructCreate('byte Data[' & BinaryLen($bData) & ']') $tBuffer.Data = $bData _Zlib_Startup() $result = _Zlib_CalculateAdler32(DllStructGetPtr($tBuffer), DllStructGetSize($tBuffer)) ConsoleWrite($result & @CRLF) _Zlib_Shutdown()

Diffie-Hellman is definitely the way to go; don't bother with _Crypt_*. I use this C++ library myself, but @jchd has provided this AutoIt implementation.

And if we're going to do a proper comparison then one should include the efforts of @timmy2 + @UEZ with enhancements by @Beege, @MrCreatoR, and @Malkey (cobbled together by yours truly).

There are two separate issues here, 1. struct element retrieval and 2. Hex representation. ad 1. struct dot notation won't tell you this, but if you check the help page for DllStructGetData, you'll see: ad 2. Reading up on the Hex function in the Help, you'll find:

Yes it does in my opinion, provided that your code does check any pointer for null before actually using it.

More often than not, garbage collection (GC) is not instantaneous, and calling Delete/Dispose/Close functions merely marks the parsed pointer as no longer needed (as if placing it in a bin beside the curb, but in theory still accessible until the garbage truck comes to empty it), to be physically removed (as in memory being freed) whenever the GC comes round to it. So although it's extremely unsafe to still reference the pointer after calling the disposal function, it's perfectly possible that it's still valid. Therefore it makes good sense to actively null it out yourself if there is any chance that any code might still reference it in the interim.