d7x Custom App News – d7xTech.com (formerly Foolish IT) https://www.d7xtech.com Computer Repair Software - PC Tech Utilities - Malware Prevention Fri, 22 Jun 2018 16:09:34 -0400 en-US hourly 1 https://wordpress.org/?v=4.9.6 42914034 d7x v18.5.7.1 Release Notes (with Custom App updates) https://www.d7xtech.com/2018/05/d7x-v18-5-7-1-release-notes-with-custom-app-updates/ https://www.d7xtech.com/2018/05/d7x-v18-5-7-1-release-notes-with-custom-app-updates/#respond Mon, 07 May 2018 22:50:29 +0000 http://www.foolishit.com/?p=14437 Today’s release adds only one notable improvement to the custom apps download capabilities, which facilitates the download of AdwCleaner using the improved non-direct URL option.  This was necessary when updating the custom apps package for this default app, as well as the Auslogics DD Portable which also needed a newer download URL.  The default custom app profiles are updated automatically and without notification.

Please Note:  v18.5.7.1 is NOT a ‘FastTrack’ build as it will be detected by previous versions, rather this version is actually a ‘Release’ build (which also fixes the bug in prior versions causing this issue.)  For this reason, the only update notification will come as an optional prompt when manually checking for updates (which will incorrectly inform you it is a ‘FastTrack’ build.)  Please update to this build in order to resolve the issue with FastTrack/Release build detections!

]]>
https://www.d7xtech.com/2018/05/d7x-v18-5-7-1-release-notes-with-custom-app-updates/feed/ 0 14437
d7x (Alpha) September Update (Updated) https://www.d7xtech.com/2017/09/d7x-alpha-september-update-updated/ Fri, 22 Sep 2017 22:07:10 +0000 http://www.foolishit.com/?p=12988 d7x v0.0.0.90 just released adds Windows 10 to custom app platform/OS restriction settings.  If not configured, behavior should not change.  Backwards compatibility note:  This is the only area in d7x configurations where d7II may (and likely will) erase the setting entirely when used to edit the same custom app configuration.

Although we’re not looking to add new features in d7x Alpha at the moment until we have tested everything, had good feedback from testers, and are confident in bringing this to the d7II “Pre-Release” stage, there are *minor* improvements we’d like to make along the way.

This is a great example of what these look like.  So if you have any suggestions that will add some real use to d7x right now, let us know.  While we can’t guarantee anything no matter how small at the moment, we would like to see what the current ideas are shaping up to look like as we begin to wrap up some things and proceed to new areas in d7II code replacement.

See this post if you missed it, and/or need any links:

d7x (Alpha) September Update for d7II subscribers – Latest update includes a NEW d7x Remote Deployment Tool (d7II SFX Mini), a NEW Config Mgmt Portal, and more for testing!

This latest d7x Alpha “TestBuild” replaces the “d7IIx Alpha” versions opened to all d7II subscribers in March.   We believe this release can be tested with confidence in a production environment, provided you keep d7II with you as a backup.  d7x Alpha is designed to sit beside d7II in the same folder, and maintains backwards compatibility with […]

 

]]>
12988
CCleaner (Piriform) Malicious Code Breach! d7x/d7II/dSupportSuite Users Take Notice! https://www.d7xtech.com/2017/09/ccleaner-piriform-malicious-code-breach-d7xd7iidsupportsuite-users-take-notice/ https://www.d7xtech.com/2017/09/ccleaner-piriform-malicious-code-breach-d7xd7iidsupportsuite-users-take-notice/#comments Wed, 20 Sep 2017 14:51:01 +0000 http://www.foolishit.com/?p=12907 Sept 26th, 2017 Update:  Yesterday this appeared on Bleeping Computer:

Avast Publishes Full List of Companies Affected by CCleaner Second-Stage Malware
https://www.bleepingcomputer.com/news/security/avast-publishes-full-list-of-companies-affected-by-ccleaner-second-stage-malware/

Bleeping also put out a nice article from the 22nd, containing a nice summary if you’re just catching up on the news (because of course more has emerged since our last update, and we shouldn’t just assume you read it elsewhere):  

Info on CCleaner Infections Lost Due To Malware Server Running Out of Disk Space
https://www.bleepingcomputer.com/news/security/info-on-ccleaner-infections-lost-due-to-malware-server-running-out-of-disk-space/


Sept 21st, 2017 Update:  These articles also came out yesterday, unfolding some plot twists to this story.  If you get your news here, you could do better!  

It seems a new backdoor was discovered and … you just need to read these:

CCleaner Command and Control Causes Concern
http://blog.talosintelligence.com/2017/09/ccleaner-c2-concern.html

CCleaner Malware Infects Big Tech Companies With Second Backdoor
http://thehackernews.com/2017/09/ccleaner-malware-hacking.html

Original post is below, but be aware some details may no longer be accurate as the story unfolds.


This came out two days ago on the CCleaner blog:  Security Notification for CCleaner v5.33.6162 and CCleaner Cloud v1.07.3191 for 32-bit Windows users.

It seems that CCleaner has had malicious code bundled into their 32bit binaries (along with their “Cloud” version) and the tampering occurred prior to distribution.  The infected binaries were provided for download from their official site/update servers and distributed legitimately for about a month, silently infecting users to send data back to the ethers.  It also occurred completely under the nose of their new parent company Avast, the anti-virus software maker who acquired Piriform (the makers of CCleaner) as recently as July.  In fact, yesterday Avast released their own blog post about it, Update to the CCleaner 5.33.6162 Security Incident.

For the consumers who’ve used any of their products, you need to know this, but I’ve got ZERO advice for what you do with that information (other than maybe call a tech if you aren’t tech oriented, because you have software on your PC that is sending bits of your data elsewhere.)  On second thought, I’m told that Malwarebytes says their software removes/fixes it, and I see they have a blog post here:  [Updated] Infected CCleaner downloads from official servers (they have the free/trial/paid user-level “scanner” software which I’m sure all editions take care of the issue quite effectively.)

With prevention, the damage is done and over for the most part unless you’re still running the infected CCleaner, but that person isn’t reading this article…  By next update at least all of our CryptoPrevent users who haven’t noticed or heard should have detection sigs for the affected binaries, and Folder Watch can quarantine or the Program Filtering can pick it up on execution as well.  In fact from a few days ago when ClamAV was the only anti-virus engine to detect it (VirusTotal.com) today it lists 41/64 engines detecting it, and that’s just how it goes in this industry.  If you have the infection but you have any sort of security software, you won’t have the infection for long.

Finally the elephant in the room is trust.

I’m sure that the CCleaner developer could’ve been as shocked as anyone else to learn about the incident, but I just don’t know.  As for Avast, if checking CCleaner (and their other software) binaries with their own security staff, or even just a little software scan with their product, was not part of their decision to acquire Piriform/CCleaner, then I’d be very surprised (and maybe I should be…)

Regardless, if you use CCleaner or Piriform products, I don’t think that this is any reason to stop using them, or the parent company’s Avast’s products.  We should all now agree that malicious activity can breach even the most trustworthy, and we should also agree that when the incident is over it isn’t always a “trust” issue at all, maybe it’s more rare than we’d normally admit, but we just got burned.  So far that’s all anyone knows here, but the thing is it wasn’t just CCleaner users, but the people at Piriform got burned too, meaning whoever punches the clock there that isn’t involved in this (which is up to and including maybe everyone.)

I have no real advice here, and in fact I would like to explicitly offer no suggestion at all; but at this point in time, there are two points to understand:

1.  Piriform hasn’t entirely dealt with the issue until they know who did it, but that is a legitimate and long established “good” app and company, and you should have no doubt that Piriform (and their parent company Avast, the makers of that big anti-virus software product, I might reiterate) will be paying attention more closely from here on out.  That should be more comforting than it might sound to someone already burned.

2.  Realize that this can happen to any other legitimate and long established (“trusted”) software by the time you make the switch, if it didn’t happen already and it’s just undetected to date (as was the case here.)  

So the best I can offer for the time being is just a little food for your own thought, with the disclaimer that you take this information like anything else you read on the internets, with a grain of salt!  (That, and don’t forget you are likely infected, so get your PC looked at!)  

 

Now, speaking only to our IT Professional / Tech Shop customers, here’s what you need to know as a tech/IT pro who maybe uses CCleaner through a custom app profile with our software:

Malicious code has infected 32bit binaries of the 3rd party software CCleaner, which can be found as a default/included custom app profile in our more popular tech-oriented/non-consumer Foolish IT apps dating back to the original d7, so there’s a high probability that someone is using it in their tech work and repair scenarios…  64bit systems are unaffected, and there isn’t a “Cloud” version in our example profiles for 3rd party applications, so you should know if that’s an issue because you created and use the customized profile.

It’s worthy of note the malicious code was planted … ok I haven’t read it all (it would seem at least before digital code signing) which means it was an “inside job” and therefore changing your download links in the custom app profiles won’t matter, it wasn’t that kind of breach…

For more technicals on the CCleaner thing, the folks at Cisco’s Talos Intelligence Group have a nice technical analysis in CCleanup: A Vast Number of Machines at Risk and thanks to our own Brantley for the link, who pointed out the pic of ClamAV near the bottom with the very first detection, good job!  (ClamAV is an anti-virus engine which seems like the historical last to recognize or do much of anything, another fine example of how things shift quickly, frequently, and wildly in this industry.)

 

d7II and d7x (Alpha)

CCleaner (under the default custom app in d7II/d7x) should re-download itself every 7 days, so if the affected version exists in your d7II 3rd Party Tools directory, and for example you lived under a rock and didn’t know about the breach, then the infected version will be there for at most another 5 days before it is replaced by Piriform’s most recent version which we would all hope is still as clean as it should be right now.

In fact, you can disable the re-download option right now (d7II Config for the custom app, persistent settings tab, you want the check at the top I believe) and it won’t ever update unless it isn’t there, so in a bench / network / office / USB flash drive scenario you’re good to go with the download you have, still a very good program for what it does and more than likely legit/clean at the moment, and it won’t update anymore so you can use it without worrying about the profile updating it to a version you don’t trust yet.

Of course you’re reading this, and hopefully you clicked on the alert in the lower status bar, then please just go delete the entire “\3rd Party Tools\ccleaner” directory, and the “\3rd Party Tools\ccleaner.zip” file if they exist from ALL of your copies of d7II/d7x, and be done with it; the (hopefully) still clean versions will download automatically as usual, as you decide to use them.

If you made it this far and you are a d7II subscriber, please also check out the d7x Alpha info page to understand what is different and consider testing it, the download is found in the new d7x Manual.

 

d7 (original/free)

I do believe it is a default option for maintenance, and although I don’t recall the specific download rules in the final v10.something, I do not believe it updates much.  Anyone using this tool should seek to do the same as mentioned above and delete your CCleaner files, let them re-download and use that if you insist, for the time being.  Then look into d7II and the upcoming d7x first and step up.

 

dSupportSuite (and dMaintenance)

Owners of dSupportSuite may know the software includes example custom app profiles for CCleaner/Defraggler as 3rd party downloads, and those who’ve deployed dSS profiles to your clients using these apps are of course affected.

So with every maintenance cycle of dSupportSuite (weekly) by default when an internet connection exists it should attempt to download the latest 3rd party tools configured for use.  Good for the fix, not so much when it was a problem!  The same automated re-download on every maintenance also applies to the older dMaintenance stand-alone apps (both the original tech version and later home edition.)

Although the issue has been corrected (for the moment) on Piriform’s end, and we’re sure that they (and their parent company alike) will be keeping a close eye on future releases, you wouldn’t be wrong to push out a new profile that doesn’t include it, at least for a time.

Also, those machines have infected code possibly running on them right now, and as much as any fix (which will more than likely be present in their security product already on their system within the next few days, if it isn’t already neutralized) your clients need to be made aware of the breach itself.

 

The same goes for many tech shops and repair guys out there, I think your customers need to hear it IF they can possibly be affected.  Probably most tech shops at one point in time or another have had at least one employee use CCleaner on a customer’s system, quite a few probably within the last month, world-wide…  That’s conservative, but my guess more than likely is that CCleaner is just part of the way things are done in many tech shops, by most if not all techs who are allowed to do their own thing, if not being some semi-to-official company mandate (depending on how large the company is they shy away from 3rd party apps without $$ agreements, but under 20 employees it’s completely possible.)  It surely is in the toolbox of most door to door guys, wouldn’t you think?

This wide-spread usage is for a good reason, let’s not forget.  I think most agree it’s also good at doing what it advertises.  Dispute the app’s necessity all you want (and I would personally do it in some other article to some degree) but I don’t ever recall finding fault with the company’s character, and we still have it in the custom app profiles our tech customers use for a reason.  As stated earlier it is a legitimate and long established “good” app and company, so don’t’ forget Piriform’s reputation and read up on how they are handling it well right now.

I’m sure since it’s so widely respected and used, a quick visit to your favorite tech forums and you’ll find plenty of tips and example scripts on what others are already saying to their customers.

I know it’s an ugly conversation with any client, depending on how one might view the situation, but if you approach it with honesty, it can be a good opportunity to reconnect with clients maybe you haven’t seen in a while, and show them some concern and care.  It’s good to build any of your client relationships through all seasons, and the integrity pays in good ways.

 

]]>
https://www.d7xtech.com/2017/09/ccleaner-piriform-malicious-code-breach-d7xd7iidsupportsuite-users-take-notice/feed/ 1 12907
d7II News: Critical Update to Custom Apps for Emsisoft a2cmd on Friday Includes Batch File Tips, Custom Apps Configuration Mini-Tutorial Here, and Yes, We Are d7IIx Alpha Testing on the d7x Code Platform! https://www.d7xtech.com/2017/02/d7ii-news-critical-update-to-custom-apps-for-emsisoft-a2cmd-on-friday-includes-batch-file-tips-custom-apps-configuration-mini-tutorial-here-and-yes-we-are-d7iix-alpha-testing-on-the-d7x-code-plat/ https://www.d7xtech.com/2017/02/d7ii-news-critical-update-to-custom-apps-for-emsisoft-a2cmd-on-friday-includes-batch-file-tips-custom-apps-configuration-mini-tutorial-here-and-yes-we-are-d7iix-alpha-testing-on-the-d7x-code-plat/#comments Tue, 07 Feb 2017 21:04:06 +0000 http://www.foolishit.com/?p=12086 In Today’s News:
    Critical Update to Emsisoft a2cmd
	Help fix my customized a2cmd config!

    d7II Custom Apps:  Configuration Options for Batch Files and Scripts
	Configuration Field Syntax
	Storage Locations (all additional files used with these settings)
	Today's Batch File

    d7II Custom App Config Explained:  Emsisoft a2cmd (All)
	Batch File as a Custom App
	Command Line Parameters/Arguments Passed to the Batch File
	WHY do it like that?
	Moving On...  What happened with a2cmd?
	Final Thoughts:  (More of this!)

    d7IIx Alpha Testing (with the d7x Platform Code)
	FEED Me (d7II/d7x Specific RSS/Atom info...)

Critical Update to Emsisoft a2cmd

Last Friday evening, we released an updated d7II default custom apps profile (#58) for the default Emsisoft a2cmd custom app configurations, due to changes that company made to their portable app’s distribution, which caused failures with newer versions of their download/installer changes.

If using any default custom apps, this update requires NO prior knowledge from the technician in usage/configuration, nor any adjustment of your customized auto mode profiles or other d7II configuration options.

If using any non-default custom apps based on the affected ‘a2cmd’ configurations (e.g. “Save a Copy” button used to save modifications to a custom app’s config, and/or renamed to a new app, etc.) or for any other reason have a non-functional custom app using a2cmd.exe, then you should recreate your custom app based on what we have done for this update, if possible.

We believe the few reasons to alter the default configurations (beyond the persistent settings options) would mostly be alteration of the command line parameters/arguments passed to the custom app’s main executable, to the preference of the technician or tech shop.  Should this be the case, and you see the size and complexity to this explanation, you may do well to spend just a minute or two on this quick fix for your own custom apps profiles using a2cmd.exe:

 

Help fix my customized a2cmd config!  

Nothing beyond step 1 is necessary if you use our default apps configuration!  You should only proceed with step 2 if you have a custom app that you copied/modified or created, which uses Emsisoft a2cmd, and is currently broken in any way (download failures, where automation is concerned, maybe you just can’t stop the user prompts for “installation” paths) then go to step 2!  

1. Update to ensure Default Apps #58 (released late on 2017-02-03)  If not updated, you should be notified at the lower status bar, and if not click d7II’s Main menu (top drop down) and then the “Check for Updates” menu item.

2. Find and select any of the Emsisoft a2cmd based custom apps in d7II Config on the Custom Apps tab.  Note the search is ‘pattern’ style, so select the “Default Apps” radio button, then search for “a2” in the box above the list, and you should see all of them.

3. Ensure you have clicked the “New / Edit App” tab so you can see the “Save a Copy” button, and do that to create a copy of our updated configuration.

4. Update fields from your custom app to ours, taking care not to disturb (add/remove/modify) ANY settings on ANY tab before “Execution” and there starting only with the “App Command Line Parameters:” field.

5. If the command line parameters field from your existing custom app’s configuration ever differed at all from original, you’ll want to copy the changes you made to this new custom app based on our settings.  I would strongly recommend pasting the entire configuration text field from both your original and the new custom apps into a text editor, or even just notepad.exe will do in a pinch 😉  The goal is to compare and ensure you have modified your parameters to utilize the different filenames (whitelist) and paths necessary in various parameters that you use.  Paste the changes back in to the new custom app.

6. Final Step – decision time, either:

Keep old custom app for reference?  Modify all of your Auto Mode profiles (or copy to new) in d7II config to implement the new custom app in place of the old.

Or…

Replace old custom app entirely?  Find/select the custom apps from the “User Created Apps” radio button view, located above the left column in the Custom Apps tab; this ensures the appearance of the “Delete” and “Rename” buttons below the listbox where the app will be selected/highlighted.

  1. From d7II Config, delete the old custom app, after ensuring you have copied the name exactly!
  2. Rename the new custom app to the exact name of the old custom app.

 

Finished!

… but don’t rush off too quick, there’s more to learn!   This update prompted the necessity of a very different custom app configuration, and I thought it was a good opportunity to take a few extra minutes and explain more about not only working with batch files, but also on how they can work with d7II custom apps system to solve a lot of unique problems…

 

d7II Custom Apps:  Configuration Options for Batch Files and Scripts

Some apps use batch files to accomplish extra tasks, and the setting for that is found in the configuration for the custom app under “Import Config Before Execution” which does some trickery many may not be aware of even with the mouse hover description.

Designed initially to copy configuration files (e.g. .INI/.CFG/.DAT/etc.) or anything with specific settings for the custom app into the app directory prior to running the app, and in this way customized settings for different apps can be carried along and used with the same configuration even in a d7II dir that doesn’t have any 3rd party apps downloaded yet, or re-downloads/re-installs the custom app.

Importing .REG files was also added to the functionality, as well as .BAT/.CMD and .VBS scripts which are copied to the app’s directory and run prior to running the app (but after any configured installer has been run for the app…)

Also note the “Save Config After Execution” checkbox setting will wait for the app to finish, at which point all files that were copied TO the app’s directory as part of the above functionality are then saved back to your d7II config directories, overwriting the old copy, which will be used for the next time the custom app is used on another PC (since you are most likely saving your config/profiles to either dCloud storage or your own local/cloud hosted FTP server, either can be configured as an automatic Start or End Session option if not already…)

The purpose for this is that updated settings in those configuration files, which you MAY have changed during a manual/non-auto mode run of the app, will be saved for the future and not lost, only to be used on this one machine…

Since it’s a dumb file copy, there isn’t much to say about the affect of this setting on .REG files (it doesn’t know what keys you configured or what to backup just by the import, so that isn’t done) and obviously the scripts aren’t usually dynamically changed, but if they were they would get updated/saved too, that’s just unlikely.

 

Configuration Field Syntax

  • Syntax is filename.ext without any path info, since it will always look in set paths relative to the d7II.exe file for them.
  • The setting support multiple files separated by a comma, and the syntax is:  “file1.dat,file2.cmd,file3,vbs,file4.ini
  • Batch/scripts would run in the order of input in the config field, as in the above example the .CMD file runs prior to the .VBS
  • All files (in the above bold example) including the .DAT and .INI, even though in a different order, should be copied to the directory before executing the batch/scripts…  Please note that “should” means if it doesn’t work, it isn’t a bug so much as I need to remember the exact mechanics before I go blog posting, and that I will need to verify but if that isn’t the case, then the expected behavior should then be to put them first in the field just as you would respect order of the the batch/scripts…

 

Storage Locations (all additional files used with these settings)

[Your d7II directory\Config\CustomApps\3rd Party Configs]  (Your created/modified custom apps.)   While at least the last subdir would not exist if you didn’t make it, it can be created or you can copy the same dir from our default app storage discussed below and remove what you don’t want…

[Your d7II directory\Config\CustomApps_d7II\3rd Party Configs]  (Our maintained default custom apps.)  

Important!  Everything from [CustomApps_d7II\*] including subdirs is overwritten on a custom apps update (in fact I believe the dir is completely deleted) so any changes you make there WILL be gone, with only one exception:  changes made from the “Persistent Settings” tab when configuring a custom app can persist, although only by using the “Save Custom Settings Only” button specific to that tab alone.  Configuration is saved separately only for those settings with respect to that default custom app, and when saved along with your d7II configuration profile locally and/or to/from cloud services, they do persist after a default apps configuration update…

I would strongly recommend rather than manually copying any default custom app configuration file [\CustomApps_d7II\*.*] to instead use the “Save a Copy” button in d7II Config, when you find and select the app from the list on the Custom Apps tab, and then choose the New/Edit tab.

Here’s why:  Apps with the same name in the two different directories WILL confuse d7II auto mode profiles in a big way, so please don’t do that!  This behavior is a side effect of the system used to intelligently find pieces of modified custom apps as necessary, as well as a limitation added from the configuration of other settings related to both the apps and d7II interface itself.

d7x Update Tidbit:  We do plan to work on removing this same-name app limitation using possibilities available in the new d7x platform code to replace older functionality that produces these limitations.  More below!

Please note that the “Save a Copy” button only saves the single Custom App configuration file to a new filename and perhaps there is another minor config modification, but it won’t create the [\CustomApps\3rd Party Configs] subdir for you, or copy any corresponding custom configuration or script from the [\CustomApps_d7II\3rd Party Configs] location.

Instead d7II.exe will intelligently determine which location has the config as necessary.  So a config for your copy will still be pulled from our maintained default apps storage, UNLESS you manually copy that to the new location.

If the same file exists in both different 3rd Party Config directories, your custom one should take precedence currently, however (another let me verify this) but if not already, the behavior for this will likely be changed in the future to consider the last modified date of the file itself, and possibly other factors.

 

Today’s Batch File:  

After updating to default apps 58 profile, check out the batch file!  (Ahem, right click / edit if you’re not used to that, but a double click won’t hurt anything if you make the mistake…)

[Your d7II directory\Config\CustomApps_d7II\3rd Party Config\a2cmd.cmd]

With all that said, I’ll leave the batch file lesson itself in the file itself which contains a few good practices in the bits of code/syntax that should be commented well for the interested, including a section that retrieves d7II “Session” data from the registry (path info in this use case) that creates a whitelist for the Emsisoft a2cmd scanner to protect d7II and other custom applications from being targeted during the custom app’s run (a task actually being done for most any custom app providing the opportunity, and though some utilize per-path direct command line arguments, others allow a whitelist file to be generated, which is performed by this batch file.

Note the context of the batch file code, which needs to know where it is located in the file system, and as the author you need to know that d7II copies this to the final app path, which is found in the d7II Custom Apps config field “32/64bit App Path/Executable Name” and if not a complete path, then by default it is the root of  [Your d7II directory\3rd Party Tools\]  directory for apps where this setting has no path but only a filename; likewise adding a partial path, e.g. [some subdir\file.ext] will prepend the 3rd party tools directory to this path (note there is no preceding backslash in the partial path.)  For partial paths, unless it is a complete path (static paths are accepted, but Windows environment and other d7II specific variables can be used here as well and are recommended where possible, as in certain other configuration fields.)

 

d7II Custom App Config Explained:  Emsisoft a2cmd (All)

The largest concept here that you wouldn’t normally see, is the idea that the batch file used with the custom app is used BOTH as the config setting/script to run BEFORE the app, AND as the custom app itself, causing it to be run twice as part of the app’s execution, and with both executing prior to the app itself.

 

Batch File as a Custom App

See the last paragraph of the last topic above for more on the d7II Config field “32/64bit App Path/Executable Name

For this custom app, we’ve chosen to configure this field from the “Execution” tab to actually launch our batch file (as well as the Pre-Execution tab’s “Import Config…” field) instead of the custom app’s main .EXE file.  Since our batch file exists in your d7II configuration, and NOT anywhere you want to just host it and download from your own FTP/web server, then it isn’t a complete custom app.  As such certain things must be satisfied to make it all come together, and it helps to have insight on a few little intricacies in how the spider web of d7II custom apps handles processing the order of certain config settings, such as the actions taken to get the apps setup/started and cleaned up later.

For one, having the download URLs configured means that the app is always expected to be there (if not installed it will be) at least if internet access is to be had and/or the installer exists in your [\3rd Party Tools] dir…  but there’s more to consider.

Since our batch file’s first run will be to run the app installers (after deciding on using the 32/64bit exe) there’s a problem – the batch file is copied to the app directory, which doesn’t exist until the installer is run.  Since d7II can’t do that for running the installer and the batch file will, the problem now is that even though d7II is downloading the installer, it isn’t running it, and still it will expect the app to have been installed to the actual (final/installed) custom app’s main path\executable directory (the one linked/explained above.)

The issue here is ultimately pretty silly compared to the normally powerful no-nonsense do it or else functions in d7II…  but specifically for the “Copy Config…” option, the functionality does not copy our batch file to the app directory (to execute it) when the app directory doesn’t exist first; it is in fact coded to skip creation on non-existence, unusual for d7/d7II, but it was for a reason!  Even with failure checking, there are little to no blanket recovery options other than try the same thing a second time and expect the different result (determination or insanity?)  So when different 3rd party apps fail differently from time to time, depending on the different ways they were coded in the different languages, with the different levels of whatever requirement is broken under various system conditions…

So it was reasoned this behavior would be more work on the tech using d7II when it came time to cleanup.  For example if it created the directory anyway, copied the config (or script, not originally an option I might point out) and then moved on to the next app, well it just essentially did that for no reason — since we know the app was not working already when it failed to install, the dumb planting of the config that created new directories was inviting hassle for our techs when it came noticing the resulting omissions in cleanup through automatic d7II tasks, and a minor pain in the PSU for the obsessive cleanup qualities that we techs mostly seem to share…

Since the dir creation would’ve been pointless, the foresight at the time of original development didn’t include it ever being necessary to set a custom app up in this way (one of many lessons learned for the d7x platform code and the design of the new custom apps system!)

Now the installers will normally download to our [\3rd Party Tools] dir, and that’s where we want the batch file to be, but you want a partial path/subdir of 3rd Party Tools else other issues can occur; it’s also can’t be in the final app path of [%systemdrive%\Emsisoft …..], which doesn’t exist until the installer completes.

A [\3rd Party Tools\Emsisoft_a2cmd\] subdir is created by the download syntax where the “Save As File” field will contain a filename with partial path (the subdir to create within 3rd Party Tools) which in this case was “Emsisoft_a2cmd\EmsisoftCommandlineScanner??.exe”   Naturally keeping it different in the 32/64bit settings for filename, so they can co-exist, the same directory can be used, and the batch code simplified a little as well as the entire process.

After this directory is created by the download, the installer setting is skipped, and the copy config setting triggers the first run of the batch file, which is copied to the directory created by the downloading of the necessary installer, and that only works because again, the batch file is configured as the custom app’s main path\exe.

 

Command Line Parameters/Arguments Passed to the Batch File

The concept works with logic contained within the batch file to act differently depending on how it was started, and this serves to prevent potential issues caused by the same tasks being performed twice; in this case it is a simple determination on whether or not the batch file was launched with any command line arguments/parameters.

With NOTHING passed, it performs the config/batch (pre-app execution) functionality necessary.

With ANYTHING passed, it will act as the custom app itself as far as d7II is concerned, but in fact the batch file just runs the custom app using the parameters passed to it by d7II, which of course were all intended for the custom app anyway, NOT the batch file…

You may have previously seen the “Wait for App Termination & …” checkbox used with this app in the past, and since we’re running our own console window (for the batch file) which d7II must wait on, the batch file is configured to identify itself (for the tech using it) and also it launches a2cmd.exe with syntax designed to wait on the process.

The potential problem with this is that the console window waiting on the custom app could be unknowingly closed by another app or accidentally closed by the tech manually, for whatever reason, at which point d7II would stop waiting on the closed console window.  The next d7II action is to continue with any configured post-processing for this app, or the execution of other custom apps in a running auto mode profile, which could interfere with this app’s operation.  Especially since it’s now “flying solo” and no longer part of anything d7II is paying attention to, many of d7II internal functions will cause problems as well, both manual and automated.

To prevent the issue above an additional measure was added to keep automation smooth, and just below the “Wait…” checkbox you’ll see the text field to add additional process names that d7II can look for and wait on those processes to terminate as well, before moving on to anything that could interfere with this custom app…  in this instance it will wait for the process named “a2cmd.exe” which is launched by the batch file, and of course that is the main executable for this custom app.

 

WHY do it like that?

Well a few reasons exist, but the convenience method here is that we don’t need multiple custom apps with chaining configured to do a few specific things, and these app profiles (if you use the defaults) we don’t want to replace the config with one using chained app configs, since you might need to re-think the setup – being a direct replacement design as we strive for with all default apps, no user (re)configuration of d7II should be required for the use or update of app itself nor the d7II auto mode profile order/arrangement.

Namely the issues here stem from being able to run the installer for a2cmd first within the custom app config, a 32/64bit issue.  Again, since this is a direct default apps replacement that shouldn’t require any user configuration changes, so separating 32/64bit app configs wasn’t a consideration.

With 32/64bit installers, downloads were usually either spawned from the same exe or they are zipped separately, and as such, the somewhat limiting configuration for the installer field in a d7II custom app, which by default assumes only one exe name for any 32/64bit install.

Keep in mind while separate zips might throw this off, they are usually saved under the same name or extracted to different locations or similar and a batch file, like the one we’re talking about, that carry out the installer based 32/64bit decisions and operations.

It’s also important to note that even single file .EXE installers are either wrapped in or entirely consisting of just another form of compressed file like .ZIP that extracts itself, and sometimes you can save the file as .ZIP/.7z/.RAR/.LZH/.???/etc.

If you learn the actual format of the file (7zip file manager > file properties) and name it appropriately, you can save an .EXE download as a .7z or whatever the appropriate format is in it’s “Save File As” field in d7II config, where it will be treated just like any other .ZIP or compressed file supported by d7II…

Use this technique to solve problems with EXE installers that automate things you don’t want done  (e.g.  automate extraction to avoid user prompting, certain “installation” tasks, etc.)

More often than not this works without issue, but it was NOT the solution for this custom app update!  See below!

(wow, yes I referenced the LHarc format above, did you spot it?  Surprised me too, I guess my muscle memory hit a long term thought?)

 

Moving On…  What happened with a2cmd?

This latest Emsisoft update did in fact move to an a2cmd installer (in EXE file format) but unlike the above mentions which is just education/side note material, this specific update uses Nullsoft installer as the extraction container (which to my knowledge doesn’t work as stated above, at least with d7II!)

What the Nullsoft installer will do, if configured to allow this at time of creation, is honor a silent extraction switch.  The silent switch that pushes the app to the default directory as pre-configured by the creator (which is not uncommon among .EXE installer files, at least when the creator allows silent usage) but Nullsoft is a bit finicky, frustrating many with an requirement quite odd these days with similar tasks:  it’s silent switch is “/S(caps required) and not “/s” or “/Silent” or anything else you’ll find in dated or incorrect documentation and even some example scripts found here and there.

 

Final Thoughts: (More of this!)

d7II subscribers who haven’t checked out our dMZ section of the website, where you can get a lot of info like this on many topics as they pertain/coincide with more advanced d7II configuration and usage.   (Note the dMZ/website has a login req which, for later recurring subscribers with no account changes, will likely equal your d7II/dCloud subscriber credentials; for any older subscribers would have dMZ/website credentials different credentials, most likely obtained at a later date.)

 

 

d7IIx Alpha Testing (with the d7x Platform Code)

The d7IIx binaries which will become the next d7II update are currently in a limited alpha testing, which is not freely open to all subscribers at this time.  Big update/little news we realize, but you can learn more on the d7IIx Alpha page.

 

 

FEED ME…

This is a great opportunity to point out the category feature to those who read the blog occasionally and/or use RSS/Atom feed readers, specifically to those not interested in all of our various blog content (e.g. techs and d7II subscribers who don’t follow our main blog due to the end-user CryptoPrevent stuff.)  

Instead of the main blog, follow only one of our specific blog categories!  Also by adding a “/feed/” to the end of any blog/category link makes it available for RSS/Atom/etc. feed viewers, e.g. https://www.bla/bla/d7x/feed/  (both styles demonstrated below for d7x categories!)

d7x Announcements  (Feed)  Includes all d7II/d7x news, Custom Apps, and Release Notes.

d7x Custom Apps  (Feed)  Includes d7II/d7x related custom app information only.

d7x Release Notes  (Feed)  Different than in the past, upon any new d7x public release, we plan to use the blog/RSS method for d7x release notes/revision histories, as opposed to a single static page…  by using a feed from the beginning, we would like to eventually take advantage of some additional in-app features that are possible with the d7x platform…

That’s all for today!

]]>
https://www.d7xtech.com/2017/02/d7ii-news-critical-update-to-custom-apps-for-emsisoft-a2cmd-on-friday-includes-batch-file-tips-custom-apps-configuration-mini-tutorial-here-and-yes-we-are-d7iix-alpha-testing-on-the-d7x-code-plat/feed/ 1 12086
JRT ‘custom app’ update for d7II (and the original d7 Premium) https://www.d7xtech.com/2016/01/jrt-custom-app-update-for-d7ii-and-the-original-d7-premium/ Thu, 07 Jan 2016 15:08:35 +0000 http://www.foolishit.com/?p=9843 Recent changes in JRT (an example custom app configuration distributed with d7II and the original d7 Premium) prompted a small but necessary fix in the 3rd Party Configs\JRT_Auto.cmd file which we use to manipulate the JRT.exe download/extraction and toi modify JRT’s GET.BAT file.

This update will fix automation issues with JRT that since one of their recent updates seems to have broken a clean exit of their GET.BAT which stalls in cmd.exe using the old last line of the file “start /wait get.bat” and is fixed by the new “start /wait cmd /c get.bat” forcing a new instance of cmd.exe to run GET.BAT and terminating at the end of the batch run.

This update also adds new whitelisting entries for CryptoPrevent and dSupportSuite.

Updated JRT_Auto.cmd for d7II:

@echo off&pushd "%~dp0"
start /wait JRT.exe -y -nr
pushd "%temp%\jrt"
if not exist "get.bat" pushd %systemdrive%\JRT
if not exist "get.bat" goto :eof
findstr /v /i "pause" get.bat>tmp.txt
findstr /v /i /b "notepad" tmp.txt>get.bat
echo.>>"%temp%\jrt\wl_services.cfg"
echo d7iisvc>>"%temp%\jrt\wl_services.cfg"
echo dSSEventSvc>>"%temp%\jrt\wl_services.cfg"
echo CryptoPreventEventSvc>>"%temp%\jrt\wl_services.cfg"
echo.>>"%temp%\jrt\wl_processes.cfg"
echo d7ii>>"%temp%\jrt\wl_processes.cfg"
echo dfunk>>"%temp%\jrt\wl_processes.cfg"
echo dSupportSuite>>"%temp%\jrt\wl_processes.cfg"
echo CryptoPrevent>>"%temp%\jrt\wl_processes.cfg"
start /wait cmd.exe /c get.bat

d7 Premium will have basically the same file, but with “d7” instead of “d7ii” and “malwarescan” instead of “dfunk” in relevant whitelisting entries.

Release versions:

d7II Default Apps update:  49

d7 Default Apps update:  58

Other resources:

d7/d7II/d7x Custom App News and Announcements (Blog)

d7/d7II/d7x Custom App News and Announcements (Blog RSS)

(Note this blog/feed was not previously used for this purpose, but going forward with d7x these categories will be used exclusively for all app release news.)

d7II Default Apps revision history

]]>
9843
d7ii Default Apps Update v45 https://www.d7xtech.com/2015/09/d7ii-default-apps-update-v45/ Wed, 02 Sep 2015 20:52:42 +0000 http://foolishit.com/?p=8884 JRT Download Link Updated
TrendMicro Online HouseCall Virus Scanner added

]]>
8884
d7ii Default Apps Update v44 https://www.d7xtech.com/2015/09/d7ii-default-apps-update-v44/ Wed, 02 Sep 2015 18:28:14 +0000 http://foolishit.com/?p=8882 Fiddler .NET 2 -Network diagnostics/monitoring for Windows 7 or lower
Fiddler .NET 4 -Network diagnostics/monitoring for Windows 8 or higher
Fiddler (Uninstaller) -chained to both apps above to automatically uninstall after use

Emsisoft a2cmd (all variations) -corrected download link

]]>
8882
Custom Apps updates today 7-13-15 https://www.d7xtech.com/2015/07/custom-apps-updates-today-7-13-15/ Mon, 13 Jul 2015 15:32:33 +0000 http://www.foolishit.com/?p=8298 Several consecutive custom apps updates this morning are available to resolve issues with JRT and HitmanPro.

JRT:  fixed closing d7II process and stopping auto mode by adding d7II to its whitelist on the fly before the app runs

HitmanPro:  fixed detection/removal of certain custom apps in the d7II 3rd Party Tools directory by correcting a broken variable which is supposed to point to a whitelist which is generated on the fly before the app runs

Check for Updates from your Main menu now if you haven’t already!  The current apps update is 42

]]>
8298
d7II Default Apps Update 6-19-15: Rogue Killer download loc update and info! https://www.d7xtech.com/2015/06/d7ii-default-apps-update-6-19-15-rogue-killer-download-loc-update-and-info/ https://www.d7xtech.com/2015/06/d7ii-default-apps-update-6-19-15-rogue-killer-download-loc-update-and-info/#respond Fri, 19 Jun 2015 20:29:27 +0000 http://www.foolishit.com/?p=8176 Reprint from the community:

Note the Default Apps update (v40) just released fixes a download link for Rogue Killer.

The symptom of the issue causing the update was the PC rebooting as soon as Rogue Killer was ran.  This was due to a bad download link – for some reason instead of a 404 that website does some redirects or something weird but d7II downloads a webpage from the non-existent links, causing it to think that is the downloaded program executable.

If you have previously used this app you will likely need to DELETE any existing copies of RogueKiller.exe andRogueKillerX64.exe from your d7II\3rd Party Tools directory.  This should really only be necessary if the executables are less than 100kb like a web page might be instead of the 15-20MB+ it should be.
]]>
https://www.d7xtech.com/2015/06/d7ii-default-apps-update-6-19-15-rogue-killer-download-loc-update-and-info/feed/ 0 8176
CryptoPrevent, ShadowExplorer, and VSSADMIN https://www.d7xtech.com/2015/06/cryptoprevent-shadowexplorer-and-vssadmin/ https://www.d7xtech.com/2015/06/cryptoprevent-shadowexplorer-and-vssadmin/#respond Fri, 12 Jun 2015 12:58:39 +0000 http://www.foolishit.com/?p=7917 ShadowExplorer (www.shadowexplorer.com) is an awesome application which I’ve used as a PC Technician many times in the past.  It is used to provide a graphical ‘front-end’ interface for a rather complicated command line utility called VSSADMIN.EXE (an internal Windows component) which handles “Volume Shadow Copies” of files made by Windows.  These are sort of ‘backups’ in a sense and the Volume Shadow Copy service in Windows is indeed used by various backup software to accomplish backup tasks.

ShadowExplorer is especially useful because it cuts your effort by 99% making it easy to find backup copies of files that were encrypted by CryptoLocker and other ransomware/malware.  Basically, by using this program, you have a chance to find and restore an unencrypted version of your important files which may have been encrypted by ransomware.

CryptoPrevent on the other hand seeks to block the malware that does the encrypting in the first place, but it ALSO blocks VSSADMIN.EXE from running.  This prevents malware from using that file to DELETE Volume Shadow Copies of your files, making it impossible for programs like ShadowExplorer to retrieve any good backups, and leaving you only with the encrypted files.

As the majority of all ransomware does the above, in our opinion it is ESSENTIAL to block VSSADMIN.EXE unless specifically used by certain backup software.  Unfortunately we don’t have a list of backup software that relies on VSSADMIN.EXE however if you TEST your backups to ensure they work properly with VSSADMIN.EXE blocked by CryptoPrevent, then you’re ok!  Likewise a failed backup means you should disable CryptoPrevent’s protection of VSSADMIN.EXE

Obviously blocking VSSADMIN.EXE with CryptoPrevent will stop ShadowExplorer from operating.  With this post I wanted to explain the situation and show you how to use CryptoPrevent to allow normal operation for ShadowExplorer, should it be necessary.

ShadowExplorer (full installation)

For the installed version of ShadowExplorer, CryptoPrevent will allow ShadowExplorer to operate normally even with the block on VSSADMIN.EXE.   For this to work however, you CANNOT be using the BETA protection.  See pic for proper settings:

cp-do-not-use-beta

 

Shadow Explorer (portable edition)

For the portable edition of Shadow Explorer, you must also unblock VSSADMIN.EXE by using the Advanced menu in CryptoPrevent to uncheck the option, and re-apply protection.  See pics below for the steps:

cp-adv-menu

 

cp-unblock-vssadmin

 

A note on the PC Restart requirement:

After applying new protection settings, CryptoPrevent will always prompt you to restart the PC.  The majority of the time this is NOT necessary, however we prompt you 100% of the time to ENSURE the settings will take effect properly.  For situations where you are trying to allow a program like ShadowExplorer to run, if you make protection changes in CryptoPrevent it is perfectly ok to try the blocked app (e.g. ShadowExplorer) without restarting the PC — this usually works right away and might just save you a few minutes.  When you are intentionally LOWERING your protection settings to use a particular app, it can’t hurt.  Just keep in mind that we strictly recommend the PC restart when applying NEW/Higher level protections (not removing them) as obviously we want the protections you think you are applying to actually be there!

cp-restart-prompt

 

Special thanks to Patrick from www.shadowexplorer.com, for the awesome app, and for pointing out the need to post this for users of both of our software.

]]>
https://www.d7xtech.com/2015/06/cryptoprevent-shadowexplorer-and-vssadmin/feed/ 0 7917