Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 12/10/2023 in all areas

  1. CodeCrypter enables you to encrypt scripts without placing the key inside the script. This is because this key is extracted from the user environment at runtime by, for example: password user query any macro (e.g., @username) any AutoIt function call any UDF call some permanent environment variable on a specific machine (and not created by your script) a server response a device response anything else you can think of, as long as it's not stored in the script any combination of the above You need several scripts to get this to work, and they are scattered over several threads, so here's a single bundle that contains them all (including a patched version of Ward's AES.au3; with many thanks to Ward for allowing me to include this script here): Latest version: 3.4 (3 Dec 2021): please follow this link. Note: if you experience issues under Win8/8.1 (as some users have reported), please upgrade to Win10 (or use Win7) if you can; as far as I can tell, the scripts in the bundle all work under Win7 & Win10 (and XP). Moreover, I have no access to a Win8 box, so these issues will not be fixed, at least not by yours truly. How the bits and pieces fit together: CodeCrypter is a front-end for the MCF UDF library (you need version 1.3 or later). Its thread is here: '?do=embed' frameborder='0' data-embedContent>> The MCF package (also contained in the CodeScannerCrypter bundle) contains MCF.au3 (the library itself) plus a little include file called MCFinclude.au3. The latter you have to include in any script you wish to encrypt. Any code preceding it will not be encrypted, any code following it will be encrypted. You define the dynamic key inside MCFinclude.au3, in the UDF: _MCFCC_Init(). From the same post you can download an MCF Tutorial which I heartily recommend, because encrypting a script requires a number of steps in the right order, namely: In MCFinclude.au3, define and/or choose your dynamic key(s) (skip this step = use default setting) include MCFinclude.au3 in your target script Run CodeScanner (version 2.3+) on your target script, with setting WriteMetaCode=True (see '?do=embed' frameborder='0' data-embedContent>>), then close CodeScanner. Start CodeCrypter press the Source button to load your target file enable Write MCF0 (tick the first option in Main Settings) Enable "Encrypt" (last option in the Main Settings) Go to the Tab Encrypt and set up the encryption the way you want (skip this = use default settings) Return to Main Tab and press "Run" if all goes well, a new script called MCF0test.au3 is created in the same directory as your target. It has no includes and no redundant parts. Please check that it works as normal. (see Remarks if not) It all sounds far more complicated than it is, really. Not convinced? Check out: a simple HowTo Guide: HowToCodeCrypt.pdf an updated and extended Q & A pdf (FAQ, also included in the bundle) to help you get started:CodeCrypterFAQ.pdf For additional explanations/examples in response to specific questions by forum members (how it works, what it can/cannot do), see elsewhere in this thread, notably: Simple analogy of how it works: post #53, second part General Explanation and HowTo: post #9, 51, 75, 185/187, 196, 207, 270, 280 (this gets a bit repetitive) BackTranslation: post #179 Obfuscation: post #36 (general), 49 (selective obfuscation) Specific features and fixes: post #3 (security), 84 (redefining the expected runtime response), 169 (Curl Enum fix), 185/187 (using license keys), 194 (replacing Ward's AES UDF with different encryption/decryption calls), 251 (AV detection issue), 262 (extract key contents to USB on different target machine prior to encryption) Limitations: post #26 (@error/@extended), 149 (FileInstall), 191 (AES.au3 on x64) Not recommended: post #46/249 (static encryption), 102 (programme logic error), 237 (parsing password via cmdline) Technical notes: BackTranslation is a test to check that the MetaCode translation worked. Skip it at your peril. It also turns your multi-include composite script into a single portable file without redundant parts (you can opt to leave the redundant parts in, if you want). CodeCrypter can also obfuscate (vars and UDF names) and replace strings, variable names and UDF names with anything else you provide, for example, for language translation). After CodeScanner separates your target's structure from its contents, CodeCrypter (actually MCF, under the hood) can change any part, and then generate a new script from whichever pieces you define. See the MCF Tutorial for more explanation and examples. Encryption currently relies on Ward's excellent AES UDF and TheXman's sophisticated CryptoNG bundle. You can replace these with any other algorithm you like (but this is not trivial to do: edit MCFinclude.au3 UDF _MCFCC(), and MCF.au3 UDF _EncryptEntry(), see post #194 in this thread). AES by Ward, and CryptoNG by TheXman are also included in the bundle (with many thanks to Ward and TheXman for graciously allowing me to republish their outstanding work). Going to lie down now... RT
    1 point
  2. I am totally off topic this time but @TheXman this is the best About me I ever read on this forum.
    1 point
  3. @jugador I'm more than happy to let others assist you and explain the way they did it. I'll stop gathering the info that I was compiling for you. I don't have much desire to participate in these forums anymore anyway. If you would like my assistance in the future, feel free to ask again.
    1 point
  4. I can try to help you with that. I'm sure that I still have those manifest tools & scripts that I created archived somewhere. I will find them and either create a stripped down example for you, explain the steps needed to do it, or both. The archived tools & scripts would've probably been saved with whatever version of the Chilkat's DLL was available at the time and their corresponding manifests. If so, then I'll supply them if necessary. As for the 2 different ways that I described, they are basically the same because they use the exact same manifest. The only difference is whether one would want to use the sxs method of distribution (the exe which has to be accompanied with its associated .manifest file) or to modify the exe's internal/embedded manifest, which means only the exe would need to be distributed. Each method has its advantages and disadvantages. Which method one should use, as far as I'm concerned, would depend on the use case.
    1 point
  5. I'd rather not make any assumptions as to what kind of help you're looking for. Can you be more explicit as to what you would like my help with? Are you asking for help to gain a better understanding of how to create external side-by-side (sxs) manifests that allow the use of ActiveX DLL objects and methods without having to register the DLL using regsvr32? Are you asking for help gaining a better understanding of how to modify an exe's internal manifest to use ActiveX DLL objects and methods without DLL registration? I have working examples for both of those methods (internal manifest & external sxs manifest) so I can try to help you understand what's needed to get that to work. Are you asking specifically for help with why the script you posted above isn't working as expected? Or, are you asking for help with something else? Although I'm quite familiar with Chilkat's work, I've never had the need to use it in any of my projects, so I don't have a license for it. My Chilkat examples use his free objects, like the JSON object. As I hope you are aware, Chilkat's Crypt2 object requires a license. Do you have a Chilkat license? If not, then I would suggest you use one of his free objects while gaining a better understanding of how to use DLL's (like Chilkat's ActiveX DLL) without having to register them. Finally, I only used Chilkat's DLL as an example back then because he provided an easily accessible manifest for his objects and his work was very well documented, which made the creation of my internal and sxs manifest tools easier to develop and test. The tools I created for creating sxs manifests and modifying internal manifests are not specific to Chilkat. The process should work with any exe that uses such DLL's as long as a valid manifest, or the information needed to create the manifest, is available.
    1 point
  6. mr-es335

    cmd to Autoit #3

    ioa747, I will endeavor to answer your queries in turn: Q1: What appears to be the primary issue here is that the folder icons for Drive G are not being updated with the .au3 script? R1: In the original script [Link], there is a section entitled, "rem Copy (desktop.ini) files (folder icon fix):" 1) As can be observed in that original script, he was "relocating" the selected folders from [C:\] to [D:\] • set oldPath=C:\Users\%user%\ - set newPath=D:\%user%\ • What is somewhat surprising here is that he "missed" the User's "Desktop" folder! • Though it does not indicate what the specifics of the desktop.ini file is involved, I could "assume" that the writer was employing the original desktop.ini files. • As the specified folders are indeed, what I refer to as "user system folders" - as a result of the "Location" tab, such folders have their own desktop.ini files. https://social.technet.microsoft.com/Forums/en-US/7f1b5172-1748-44ab-af89-cdcb0ec60a7c/local-folder-redirection-batch-file-command-prompt-cmd-script Q2: ...that you have the folders in a different location ("D:\Install\System_Config\Folders\Source_Data_E") and in a different location the desktop.ini files ("D:\Install\System_Config\ini_files\E\") R2: Firstly, I was attempting to be as "faithful to the original script" - inasmuch as I was able to...for my own personal need and requirements anyhow. • See: "rem Setting variables to use when applying folder redirection in registry." and "rem Copy (desktop.ini) files (folder icon fix):" • Secondly, as I was not employing the original icons as those in the original desktop.ini files, I thought it prudent to keep such data in their own locations [...which I see now from your comments...is not necessary]. Thanks! Other points to note... In my script, the _UpdateFoldersIcons() functions - I do believe in a way, negates the need for the separate .ini files, as I am attempting to "globally" update the "user system" folder icons for any-and-all such folders. • See "How to Change the Windows 7 Default Folder Icon": [Link] https://www.sevenforums.com/tutorials/23825-folder-icon-change-windows-7-default-folder-icon.html Following is the text from that function: • Local $sRegistryPath1 = "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}\DefaultIcon" •Local $IconValue3 = "D:\Install\System_Config\Icons\folder.ico" •RegWrite($sRegistryPath1, "(3)", "REG_SZ", $IconValue3) • Note: After deploying this function, any-and-all Explorer folder icons should adopt the updated folder.ico data file. • This should negate the need for the "rem Copy (desktop.ini) files (folder icon fix):" section as I was not requiring the need for "different icons" for each of the specified folders. An important note... What IS interesting,. is that my original cmd script DOES invoke that update, whilst the .au3 script does not! Interesting! 1) My original cmd script: :: Update folder icons... reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Icons" /v "3" /t REG_SZ /d D:\Install\System_Config\Icons\folder.ico /f echo Updating System folder icons completed. 2) The .au3 script ;Update folder icons... Local $sRegistryPath3 = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Icons" ;------------------ Local $IconValue3 = "D:\Install\System_Config\Icons\folder.ico" ;------------------ RegWrite($sRegistryPath1, "(3)", "REG_SZ", $IconValue3) IMPORTANT UPDATE! I discovered why the .au3 script was NOT globally updating the Explorer folder icons! • Compare the following: a) RegWrite($sRegistryPath1, "(3)", "REG_SZ", $IconValue3) b) RegWrite($sRegistryPath1, "3", "REG_SZ", $IconValue3) Observations 1) As to why I added the "()'s" I have no idea? However, when removed...all was well! 2) The above does clearly demonstrate however, that the functions "_CopyIniFilesE()" and "_CopyIniFilesF()" are no longer required! In closing... I do hope that the above explains "all the goings on", and that such does make sense? I also wish to sincerely thank you ios747, for your wisdom and your insights into this matter. I do appreciate such very much!
    1 point
  7. Danp2

    WinMenuSelectItem

    Did you see this note in the help file entry for WinMenuSelectItem?
    1 point
  8. Mobius

    AutoCamo - 98.18b

    Last updated 9/10/21 * Image may not represent current product Features Simple Integrated countermeasures against file and memory analysis based decompilers. Add basic types of resources into the interpreter or other types as raw data. Define multiple programs to execute pre and post build. Create and include pe version information. User defined patches that can be implemented globally on the interpreter and compiler or selectively. Handles its own basic macro's as well as environment variables in most fields for easier path finding. Drag and drop configs (script bound or separate) to the input edit box or to the icon to load them. Configuration settings can be copied to the clipboard or saved as config files or Au3 scripts. Settings can now be saved directly to an AutoIt3 script. Subsystem independant, can act as a gui or console tool. And much more. See next post for update information. A3C_97.16b.7z A3C_98_18_b.zip
    1 point
  9. RTFC

    Code Scanner

    Hi Everyone, This is my first-ever post to this forum, and it's also the first forum I ever joined, after visiting anonymously for some time. I've been very impressed by both the level of expertise and the friendly, helpful, generous, and funny replies to OPs by the large majority of members. My main intention in joining was to share some potentially useful scripts of mine with the community. I've been programming for many years, and since a few months, also in AutoIt. On the other hand, I've no clue about posting stuff, so here goes (fingers crossed): I wrote this one to help solve dependency issues in some larger AutoIt projects of mine, but it should be equally useful for small/simple projects. It's not meant to replace AU3check, but to provide additional info on your project, and identify *possible* runtime issues that the compiler does not pick up. You then have to figure out yourself whether/where/how to change your code. Also be warned that the file I/O is tectonically slow (definitely room for improvement there). Download CodeScanner and associated UDFs in the CodeScannerCrypterBundle. This utility scans an AutoIt code project with multiple #includes and/or UDFs for inconsistencies, clashes, and various other hidden (potential) problems. It also generates MetaCode files for use with CodeCrypter and the MCf library. It does NOT alter your code; it just reads, evaluates, and reports. 36 Optional Outputs (from version 2.0😞 status report (text file), identifying: missing #includes, duplicate UDFs (lists all occurrences with their resp. parameters); issues with global definitions, unresolved function parameters... searchable treeviews of code architecture (nested #includes, nested function calls (UDF + native AUtoIt); detailed stats for each selected branch (who calls X, who is called by X) array listings (some 2-D) of: identified potential issues; unique #includes, redundant #includes; unique UDFs with calling stats; globals; all locations/definitions of UDF func def/endfunc, all calls, all #includes, all globals, all variables, all literal strings, all native AutoIt functions (with parameters) definition list of all globals identified only within UDFs, written out as script for easy inclusion at top of your script (so all globals are predefined in main code) MetaCode files (see the MetaCode thread (esp. the Tutorial) for details: '?do=embed' frameborder='0' data-embedContent>>) all results can be written to text files and read in to other scripts in their original array formats with an additionally supplied small UDF. You can edit the code to add more yourself; I'm gradually extending its functionality as/when required for my own projects. Hope it helps!
    1 point
  10. RTFC

    MCF - MetaCode File UDF

    MetaCode offers a way to: separate a script's structure from its content remove all redundant definitions (globals and UDFs) change any content (and some structure) combine (new) structure and (new) content into a new script The most useful applications implemented so far are: Fast language translation (not just text strings, also variable names and UDF names) Obfuscation (vars and/or UDFs) Script Encryption (conditionals, calls, and macros) Encryption is powerful because the key is not stored anywhere; you can define it to be a user password, macro, environment spec/variable, server response, something you define yourself, or a combination thereof; anything goes, as long as it's not a fixed string or fixed value. More info in the CodeCrypter thread: ?do=embed' frameborder='0' data-embedContent>'?do=embed' frameborder='0' data-embedContent>> ?do=embed' frameborder='0' data-embedContent> But MetaCode has more potential than that; it allows you to tinker with any type of content separately, then rebuild a new version. So for example, you can have a single script structure and numerous different language modules you just plug in to create a new version in a different language. A brief Tutorial is here: MetaCode Tutorial.pdf The MCF library itself can be found in the CodeScannerCrypter bundle. And a little example how to use it for translating your GUI into a different language: UI_Translator.7z (new version that should work with the new version of Google Translate, see post #13 below) MCF.au3 is just the library plus the MCFinclude.au3 file you need to include in any script you wish to encrypt. There is no GUI here. However, I did write a separate front-end for it called CodeCrypter, which you can find here: ?do=embed' frameborder='0' data-embedContent>'?do=embed' frameborder='0' data-embedContent>> ?do=embed' frameborder='0' data-embedContent> MCF uses output generated by my CodeScanner version 2.8+, which you can find here: '?do=embed' frameborder='0' data-embedContent>> CodeScanner also depends on MCF.au3 now, as it can now call a few of its functions. I should also mention Ward's excellent AES.au3 UDFs used for the encryption and decryption calls, which is now included in the CodeScannerCrypter bundle (thanks to Ward for allowing to include it). You can find the original (unpatched) version here: '?do=embed' frameborder='0' data-embedContent>> Note: you can replace the encryption/decryption calls with whatever algorithm you like (hint: the native <Crypt.au3> library is too slow for most purposes, better stick to machine code routines) So just to be clear: CodeScanner (v2.8+) needs MCF (earlier versions won't work!) CodeCrypter needs MCF (plus anything that MCF needs) MCF itself needs MCFinclude (part of MCF zip) MCF also needs readCSdatadump (part of the CodeScanner package, you need the latest version packaged with CodeScanner v2.8; earlier versions won't work!) both MCF and MCFinclude currently rely on AES.au3 by Ward So you basically need to download the whole bundle for any of it to work. If you have any questions, please start by reading the MCF Tutorial and the CodeCrypter FAQ (you can download the latter separately from the CodeCrypter thread). Next, read the extensive Remarks sections in MCF.au3, MCFinclude.au3, and CodeCrypter.au3 If still no joy, then please post. However, I'm not online that often, and logged in to the forum even less, so response may take a while). RT
    1 point
×
×
  • Create New...