Custom App Variables

Skip to:  Main Variables  /  Variables for URLs  /  Variables for Reporting  /  KillEmAll Variables

There are certain locations in d7x, such as the Custom Apps system, where variables are accepted and play an important role.  A variable for our intents and purposes is a standardized string of text, that when interpreted by d7x, will be replaced with another string of text.  For example, the d7x (and Windows) variable “%systemdrive%” when interpreted is replaced with “C:” – useful when things aren’t always in the same location…

The variable format d7x uses is much like Windows’ own environment variable usage, wrapping the %variable% in percent signs to identify itself as a variable to the interpreter, differentiating it from a static string of text.  Variables expressed within d7x are not case sensitive.

As you will see below, d7x interprets many of Windows’ environment variables as well as adding some of its own.  There are a few behavioral exceptions however, such as usage of %programfiles% and %programfiles(x86)% which carry an important difference in usage within d7x, as explained below.

There are several places in Custom Apps configuration where you can specify the main variables outlined in this section.  These include:

• Run Installer and command line parameters fields (Pre-Execution tab)
• App Path / Executable fields (Execution tab)
• All command line parameter fields (Execution tab)
• Copy Log File field (Post-Execution tab)

Variables Interpreted  (unique to d7x):

• %tdrive% – Expands to a drive letter and colon.  This is the target partition that d7x is operating on (e.g. “C:” or “E:”) this can be used to point custom apps to offline Windows installations on another partition, such as when attaching a hard drive to a tech bench computer, or operating on the PC from a Windows PE based boot CD.
• %root% – Expands to a drive letter and colon.  This is the partition that d7x is running from (e.g. “C:” or “E:”) and is useful to point custom app syntax to the root of your flash drive, for example when you need to reference something outside of the d7x directory structure.
• %d7apppath% – The exact path that d7x.exe is running from.
• %apppath% – The exact path that the configured custom app executable is running from.
• %3rdpath% – The exact path of the d7x 3rd Party Tools directory.
• %scriptdir% – The exact path of the d7x Scripts directory.
• %reportdir% – The exact path to the current dx Reports directory for the current session.
• %malreportdir% – Same as %reportdir% except it expands to the Malware Reports subdirectory.
• %date% – Expands to the date (no time included) in the format it is configured to appear (in d7x Config > Behavior > Regional Settings) with dashes instead of forward slashes so it is compatible to use with Windows file naming conventions (e.g. “10-13-2014”)

Variables Interpreted  (Exact same behavior as their Windows variable counterparts):

• %computername% – Expands to the current computer name (e.g. “Owner-PC”)
• %systemdrive% or %homedrive% – Expands to a drive letter and colon representing the primary partition that Windows is installed on (e.g. “C:”)
• %systemroot% or %windir% – Expands to the current directory that Windows is installed in (e.g. “C:\Windows”)
• %temp% – Path to the current user’s temp directory.
• %userprofile% – Expands to the current user’s profile directory (e.g. “C:\Users\Bob” on Vista+, or “C:\Documents and Settings\Bob” on XP.)
• %appdata% – Expands to the current user’s application data directory (e.g. “C:\Users\Bob\AppData\Roaming” on Vista+, or “C:\Documents and Settings\Bob\Application Data” on XP.)

Variables Interpreted  (Similar to Windows variables, except some behaviors will differ):

• %localappdata% – Behaves exactly as on Windows Vista+, however this variable did not exist in XP, so d7x fills in the blanks.  (e.g. “C:\Users\Bob\AppData\Local” or on XP “C:\Documents and Settings\Bob\Local Settings\Application Data”)
• %programdata% – Behaves exactly as on Windows Vista+, however this variable did not exist in XP, so d7x fills in the blanks, pointing it to the directory where the same data would be stored on XP.  (e.g.  in Vista+ it expands to “C:\ProgramData” but on XP it expands to “C:\Documents and Settings\All Users\Application Data”)
• %allusersprofile% – Expands to the full path of the All Users or Public directory, depending on OS version.  (e.g. “C:\Users\Public”)  This can be useful to reference objects on the “All Users” desktop.  Example:  “%allusersprofile%\Desktop\foo.txt” would expand to”C:\Users\Public\Desktop\foo.txt” on Windows Vista and above, and “C:\Documents and Settings\All Users\Desktop\foo.txt” on XP.
• %programfiles% – Either expands to the current 32bit OR 64bit (if it exists) Program Files directory, (e.g. “C:\Program Files”)  On 64bit systems, it expands to the 64bit Program Files directory (e.g. “C:\Program Files”)  So in other words, this variable is useful in those rare situations when you are referencing something that will always be in the “Program Files” and never in “Program Files (x86)”
• %programfiles(x86)% – Always expands to the current 32bit Program Files directory (e.g. “C:\Program Files” on 32bit OSes and “C:\Program Files (x86)” on 64bit OSes.)  Use this variable in situations where you are referencing a 32bit app, so that no matter what the OS architecture, you will get the 32bit Program Files directory.
• %commonprogramfiles% and %commonprogramfiles(x86)% – These expand to the little-used common program files directory (e.g. “C:\Program Files\Common Files”) and behave in exactly the same way as the %programfiles… variables explained above.

These variables are used by Custom Apps when interpreting text for the Download URL fields.  Requires d7x v19.12.10 or later.

• %name% – Expands to the client name.
• %num% – Expands to the ticket number.

These variables are used by Custom Apps when interpreting text for the Work Reports / Custom Work Reports, and can only be used in the Work Report Language field.

• %app% – Expands to the full name of the custom app.

The links below document new variables and wildcards for use with KillEmAll v5+ now integrated into d7x and available as a stand-alone executable.

• Wildcard Usage in d7x and KillEmAll
• Rule Variables Used in d7x and KillEmAll

Note:  These newer variables and wildcards will be implemented for use across all d7x functionality, and they DO NOT APPLY to previous versions of KillEmAll from d7II or the stand-alone versions found in the d7II or d7x root or \Modules directories. 

As the new variables are implemented across all d7x functionality, we plan to convert as much of your existing definitions from the older formats as possible, and we plan to include support the existing formats where user discretion in conversion is required due to the more fine grained control possible with the newer variables.  

Please see the documentation on this page for all other areas of d7x and d7II at this time.