This configuration page is used to define all of your favorite custom applications which you can add to d7 in these areas:

• Custom Apps on the Audit/Diagnose page
• Custom Apps on the Malware page
• Custom Apps on the Maintenance page
• Custom Apps on the Customize/Install page
• Custom Apps on the Offline page
• Custom Tools which display in the Tools drop down menu
• Custom Scripts which display in the Scripts drop down menu

To define a custom app, first select the area to which you are adding the app (e.g. Malware) from the bullet options at the top.

• App Download URL (applies to all “page” apps and the Tools drop down menu, but isn’t available for the Custom Scripts option.)
  • You may configure a download URL for your custom app so that d7 can automatically download the app if it is missing.
    • If not using this option, d7 won’t download the app when missing.
  • If using this option, you should set it up FIRST before anything else, and test download/extract the app. d7 always downloads/extracts applications to the 3rd Party Tools directory, however if your application is zipped, it may be zipped with the main EXE inside nested folders within the ZIP, so who knows where they will extract to (e.g. with no nested folders it would extract to 3rd Party Toolscustomapp.exe, however with nested folders in the ZIP it may extract to 3rd Party Toolscustom app 1.0customapp.exe, for example…)
• Download File Name (naturally this only applies if you are using the App Download URL function.)
  • This option sets a static file name for your download, and is required to use the App Download URL function.
    • The reason is that your download URL may point to a dynamically changing file name that will be downloaded. d7 MUST know the name of the file it is downloading, in order to extract the file properly if it is a ZIP file, and even if it is a plain EXE file it will need to know the name in order to execute it!!
  • 64bit name is obviously for use with the 64bit download URL box

• 64bit only download URL is obviously only for use with a separate download for a 64bit version of your custom app.

• 2nd – in this field you can specify a secondary download URL for use if the primary download URL fails to download for any reason.

• Non-Direct URLs – Check this box if the URL redirects to an undisclosed URL for downloading the file.  This works when the actual download at the URL location is a text file containing a URL= line inside with the actual file download.  Web browsers are ‘smart’ enough to pickup on the redirect automatically, while d7 must be told it is this type of redirect!

• Spoof Referring URL – This field is to specify a referring URL to ‘spoof’ – some sites for example don’t allow direct downloads, so they check to see if you are coming to the download link from a ‘referring’ URL, another page on their site.

• Redownload if app is > x days old – as it says, if the app was downloaded more than the number of days specified here, it will be redownloaded – useful to keep apps current.

• App Website or Online Help File – this field can be filled out to specify a download webpage or online help file.  If the custom app cannot be downloaded for any reason it can automatically open this webpage; alternately you can open the webpage specified here by right-clicking on the custom app and selecting Goto Website when on a custom app page in d7.

App Name (applies to both apps and scripts)

• Give the app/script a name that will be displayed within the d7 GUI.

Run Installer First

• Check this box and browse for the installer executable when the download is not a portable app, but must first be installed prior to running.
• Installer Parameters – These are command line parameters you can pass to the installer (when supported) to install it silently/automatically without user prompting, for example.

App Path/EXE Name (applies to both apps and scripts)

• All custom apps are placed in the d7’s 3rd Party Tools subdirectory with some exceptions:
  • You may configure apps on the same DRIVE LETTER as d7 but outside of the 3rd Party Tools directory by entering %root% for the drive letter and colon
    • (e.g. %root%my foldermy app.exe)
  • You may configure apps to run from UNC network shares, providing you have the full path to the share starting with
    • (e.g. serversharemyapp.exe)
  • You may also configure apps to run outside of this directory by using environment variables in the path.
    • (e.g. %windir%system32MRT.exe)
  • Accepted environment variables are: %systemdrive% %homedrive% %windir% %systemroot% %programfiles% %programfiles(x86)% %userprofile% and %allusersprofile%
  • When using environment variables to run apps on the system outside of 3rd Party Tools, naturally the app download functionality and also the Randomize file name options have no effect, however the Wait for Termination and command line parameters do function with this method.
• All custom scripts should be placed in d7’s Scripts subdirectory.
• Simply click the Browse button to select your application or script.
• If you left the App Name (above) blank, then the file name of your EXE/Script will be automatically inserted as the App Name.
• Use system and d7 specific variables in commands. (see Variables below)
• 64bit App Path/Name – Configure a separate 64bit app to run on 64bit systems.

Command Line Parameters (applies to both apps and scripts)

• Use system and d7 specific variables in command parameters. (see Variables below)
• For custom apps appearing on a tab, these parameters are only passed to your custom app when the app is run as part of d7 Auto mode. So the intention is for you to input parameters (if available) that tell your app to run in an automated fashion.
• For the custom tools and scripts menus, these parameters will always be passed to your application. Useful, for example, with Sysinternals applications where you can pass the “-accepteula” parameter to the application enabling you to bypass the EULA prompt before running the app. Useful also if your app or script will always require a certain parameter to run as you intended.

Import Config File(s) Before Running (for apps only)

• Fill in this box to copy your app’s pre-configured settings file (such as an INI file) to the application directory before running the app. This ensures that your app will run automatically with the configuration that YOU want, without having to reconfigure it every time it is run.
• Configuration sets should be saved to the Config3rd Party Configs directory or a subdirectory inside of it. These configuration sets are also sync’d with D7’s Sync Configuration option discussed elsewhere.
• If you select a .REG file in this box, instead of being copied to the application directory, the .REG file will be automatically imported to the local registry before running the custom app!
• If you select a .BAT/.CMD/.VBS file in this box, it will be copied to the application directory and then executed from there, prior to running the custom app!
• The Update After checkbox will copy the config files to Config3rd Party Configs AFTER the custom app is run (excluding .REG/.BAT/.CMD/.VBS files of course.) This ensures that any changes you make to the app’s configuration are saved in order to be copied back to the application directory for the next time you run the custom app.

Export/Save Registry Settings Key After Running (for apps only)

• This option will export a registry key of your choice to a .REG file after the app has run. Useful for apps that save their configuration to the registry. The .REG file will then be re-imported on any subsequent runs of your custom app.
• The Update After checkbox must be selected for this option to take effect.
• The Import Config File(s) Before Running box must contain a .REG file for this option to take effect. This is the reg file name it will be saved as, and used for in the future when re-importing.

Copy Reports (When filled in, this option attempts to copy any reports generated by your custom application after it is run.)

• Move Instead (of copy)
• Use system and d7 specific variables. (see Variables below)
• Specify a directory name only to copy a directory, or specify a pathfile name to copy just that. Wildcards are accepted as part of the file name!
  • e.g. %localappdata%SomeCompanySomeAppLogFiles*.*
  • e.g. %apppath%*.log
• (This option forces the Wait for Termination functionality described below)

Variables for Custom Apps Config

• %reportdir% – The current d7 Reports directory.
• %malreportdir% – The current d7 Malware Logs directory.
• %d7apppath% – The current directory of d7.EXE
• %root% – The current drive d7 is running from e.g. E:
• %apppath% – The current directory of the custom application you have configured. (Used for the Copy Reports feature only.)

Additionally, these standard Windows environment variables are supported:

• %appdata% %localappdata% %programdata%
• %userprofile% %allusersprofile%
• %windir% %systemroot%
• %systemdrive% %homedrive%
• %programfiles% %programfiles(x86)% (always use %programfiles(x86)% for non-64bit apps as it will automatically resolve to just %programfiles% on 32 bit systems.)
• %commonprogramfiles% %commonprogramfiles(x86)% (always use the (x86) variable for non-64bit apps, resolves same as above.)

Randomize File Name (applies to all custom apps and the Tools drop down menu)  –  Randomizes the file name before executing the application. Useful for using against malware that will block your app from execution based on it’s process name.

Run As System – Runs the app under the local system account, useful to bypass file system and registry permissions, but will render the app unable to access network resources.  NOTE some applications won’t even start properly in this mode, e.g. Fab’s AutoBackup 4 Tech.  🙁

Run Inside CMD.EXE – Use this option only when an application fails to run properly from inside D7, but works fine when run manually. This option creates a batch file to run the application, and runs that batch file. The purpose is that the batch file will change to the current application directory before running the application; this can resolve some issues when apps fail to run properly using standard methods.

Wait for Termination & also wait for:  (applies to everything, under certain circumstances, except custom scripts)

• Waits for the app to terminate before proceeding.
  • d7 will also wait for any processes in the text field below this check mark.  Separate multiple process names with a semi-colon.  e.g.  program.exe;program64.exe
• Applies to all custom apps on “tabs” when executed as part of d7 Auto mode.
  • Does not apply to custom apps when not executed as part of d7 Auto mode, unless Randomize File Name is selected.
• Applies to custom apps in the Tools drop down menu only when Randomize File Name is selected.
• When Randomize File Name is selected, d7 must wait for your app to finish and close itself before it can change the file name of the app back to it’s original name – so the next time d7 needs to execute the app it knows which app to execute!
• NOTE: This may not work for certain applications – what happens is the application process that d7 launches may start a new process and then terminate itself – since d7 sees the original process terminated it moves on. Such is the case with PC Decrapifier (there is a thread entitled Maintenance Pause in my Google Groups forums where I have created a batch file workaround for that particular app.) In this event, a custom batch solution may be the answer. Feel free to drop me a line in the forums and I’ll try and work with you on a solution tailored ro the particular app you are using.

Wait in Service Mode – This option causes d7 to shutdown immediately after running the custom app, where it will wait in “Service Mode” until the app has finished running, then it will reboot the PC automatically (and continue where Auto Mode left off if in Auto Mode of course.)  Service Mode means d7 installs itself as a Windows service and continually restarts itself should it be terminated.  This is useful for apps such as Combofix and Rogue Killer which will attempt to terminate d7, breaking automation.  NOTE the Copy Logs option will not function properly with Service Mode.

Audible Alert … – use this option to have d7 sound an audible alert prior to running the app, which is useful to get a tech’s attention for apps that cannot be fully automated and may require user intervention.

Display Prompt … – Use this option when the Wait for Application to Terminate option above does not work for your app.  Optional:  In the text field below this option you may specify the number of seconds before the prompt is disregarded.  Useful for apps that may terminate early (to update itself) or crash, this will display the prompt halting d7’s operation; if the app stays running longer than the number of seconds specified, the prompt will not be displayed.  This option applies to Auto Mode only.

Disable Cloud Sharing – Normally dCloud users who choose to ‘share’ their custom apps with other dCloud users will have all of their apps uploaded.  Disabling this for a particular custom app could be useful for example if your custom app contains a private download location, customized executable (that you’ve purchased/licensed) or something else that you don’t want shared with the world – ex.  Ninite

Run on these Platforms – Here you can configure which platforms the custom app will be allowed to execute on.

Adding Pre-configured Custom Apps: