UIU Blog

rss
UIU Plug-ins 2.0 for SCCM – Updating your license key

Due to security upgrades, all new UIU license keys with an expiration date after December 31, 2019 require the use of the new updated software, both the UIU Plug-in Manager — UIUPM.exe (2.2.3) — and the components software — UIUPrep.exe (5.8.1).

The necessary steps to update your UIU license key are, in order, as follows. Details on each step follow this summary.

  1. Using your current UIU Plug-in Manager, download the latest UIU Components and driver set using the Update Repository function on the Repository Management Screen of the UIU Plug-in Manager.

  2. Perform or schedule an update for your UIU packages in SCCM. It is important that the latest copy of UIUPrep.exe, version 5.8.1 (or newer), is distributed before updating your license keys.

  3. Wait for package replication to finish.

  4. Update your copy of the UIU Plug-in Manager to version 2.2.3, if you have not done so already.

  5. Finally, follow the procedure to update your license keys, located here.

Additional notes on steps above


“Using your current UIU Plug-in Manager, download the latest UIU Components and driver set using the Update Repository function on the Repository Management Screen of the UIU Plug-in Manager.”

Link to User Guide topic

Updating the UIU Repository which contains the software and drivers used during deployments is independent of updating the UIU Plug-in Manager itself and can be performed with any version of the UIU Plug-in Manager.


“Perform or schedule an update for your UIU packages in SCCM. It is important that the latest copy of UIUPrep.exe, version 5.8.1 (or newer), is distributed before updating your license keys.”

UIUPrep.exe version 5.8.1. was released on January 8th of 2019, and you may already be up-to-date if you have performed updates this year. Viewing the Details tab of the File Properties of any copy of UIUPrep.exe will tell you which version it is. Copies of UIUPrep.exe are located in the repository source location under amd64\uiuprep.exe and x86\uiuprep.exe. These should be the same as the copies on your distribution points presuming you have performed an update distribution point operation on the UIU packages since the last time you updated the UIU Repository source location using the UIU Plug-in Manager.


“Wait for package replication to finish.”

This is to emphasize that you must have UIUPrep.exe 5.8.1 distributed before updating your license keys or your deployments that leverage the UIU Deployment Configuration will fail.


“Update your copy of the UIU Plug-in Manager to version 2.2.3, if you have not done so already.”

Only UIU Plug-in Manager version 2.2.3 can support keys with expiration dates after December 31st 2019.


“Follow the procedure to update your license keys here: …”

Link to User Guide topic

Now that all the software to support the new license key is in place, you should now proceed with actually updating the license key.


UIU Classic Mode to replace UIU Classic


The UIU 4.x, a.k.a. the UIU Classic has reached the end of the line. Originally developed in 2004 and continuously updated through 2017, the UIU Classic (4.x) will not function with UIU License Keys that expire after the end of 2019. The UIU Classic has been replaced by the UIU Classic Mode.

The UIU Classic Mode product, built on UIU 5 technology, will allow users to install device drivers in an online Master Image prior to Sysprep and prior to capture by an OS deployment solution that is presumably not based in WinPE technology. Big Bang has taken steps to preserve the flow of the UIU 4.x product’s GUI and has streamlined the process in the context of the operating system versions still supported today.

The UIU Classic (4.x) was developed to universalize Windows OS images by providing a set of applicable drivers, installed on a live operating system or “Master Image” prior to the execution of Microsoft Sysprep and subsequent capture for later deployment. This method was proven effective for many iterations of the Windows OS.

After the 2012 release of the fully-integrated UIU plug-ins for SCCM and MDT, Big Bang released UIU Classic’s successor, the “UIU 5” in 2013. Instead of installing drivers in an online OS prior to Sysprep, (which had some interesting difficulties with more modern operating systems), the UIU 5 applies only the relevant drivers for any specific target PC as discovered during a WinPE stage of Windows OS Deployment Solutions. The drivers are staged in the Windows Driver Store and are then accessed by the OS, during mini-setup’s enumeration process.

This improved process allows for:
  • More accurate assessment of required drivers
  • More robust application of those drivers
  • Smaller UIU footprint in deployable images
  • More successful deployment experience

  • Whenever possible, Big Bang encourages all of its customers who have employed the UIU Classic (4.x) product to give the UIU 5 version an opportunity to make Windows OS deployments better. That said, Big Bang realizes that some customers have chosen OS deployment solutions that are not based in WinPE technology. It is with the intent to support those users that Big Bang has created the UIU Classic Mode product, initially released in January of 2019.


    Technical issues deploying 32-bit operating systems to modern hardware

    Technical issues deploying 32-bit operating systems to modern hardware

    WinPE technical limitations – Memory Allocation

    The UIU functions within WinPE in order to accomplish the daunting task of providing drivers on-the-fly to any make/model of business class PC. In order to accomplish this, the UIU requires access to the registry hive of the target PC from within WinPE. Occasionally, situations present themselves wherein the limitations of hardware architectures and components conspire to prevent proper execution of processes in WinPE.


    Problem Description:
    When attempting to mount an offline registry hive for a 32-bit OS image (at least through Win10 1703), (which requires WinPEx86), on hardware that has more than 4Gb of RAM installed, the allocation of memory blocks can be insufficient to mount the entire registry hive which causes part of the registry to be written to memory locations that cannot be properly addressed. Upon dismounting the offline registry hive, the part of the hive that was written to those locations will be truncated which results in a corrupted registry, and a BSOD upon reboot. The issue is seen on primarily (but not limited to) newer, 64-bit designed hardware.


    What is really going on?
    In particular instances, the following variables may combine to affect the mounting of an offline 32-bit OS registry hive into RAM while operating in WinPE:
    • RAM type
    • RAM quantity
    • RAM configuration
    • RAM block utilization


    In effect, if there are insufficient contiguous blocks of RAM to hold the mounted offline registry hive, the data is truncated and no error is presented at the time. After reboot, when windows attempts to mount the registry, the corrupted registry causes a system halt and subsequent BSOD. In the case of the UIU, the truncated mount also inhibits the UIU’s ability to determine necessary details of the target machine required to function as designed, culminating in a failed UIU-prepared deployment of the 32-bit OS to the target hardware.


    This is a known issue with WinPE:

    Win2008R2/Win7: STOP 0xF4 during Task Sequence / OS Deployment

    "This process is sometimes a problem when using an x86 boot image. Basically because WinPE has no page file, WinPE relies completely on what physical memory is available. The end result is that memory in WinPE gets very fragmented. With x64 WinPE this is not a big deal on most modern PCs because there is a lot of memory available. However with x86 boot images, there is a limit of how much memory can be addressed (around 3GB) regardless of how much memory the PC actually has. The end result is that when the memory gets very fragmented with an x86 boot image, there is less of a chance of there being a piece of contiguous memory that large enough to hold the registry that needs to be mounted. In these situations, when the registry gets mounted, it gets corrupted and part of the registry basically gets chopped off."



    In the instances where this issue is encountered, given the limitations of the x86 architecture, the UIU can only offer the following resolutions at this time:

    Potential Resolutions:
    • Remove all but 4Gb RAM from the offending hardware
    • Utilize native SCCM driver inclusion technology with customized UIU driver packages (provided by UIU Support)
    • Install/deploy a 64-bit OS version


    Please contact UIU Support for additional details.


    Audit Mode and the UIU

    What is Audit Mode?

    Although the feature has been an option since Windows 7, it has become increasingly necessary when deploying Windows 10 operating systems. Audit Mode allows the OS to enter a state using only the default, built-in Administrator profile so that system and application settings are only applied to the single instance of the profile. This becomes crucial in the preparation of a base image used in OS deployments, enterprise-wide.

    Why is Audit Mode a thing?

    Because Microsoft Sysprep is a thing… Windows 10 employs a method of Application Provisioning that can cause problems with Sysprep. During the OOBE (Out Of Box Experience) process, profiles (in addition to the built-in Administrator profile), will be created. As applications are installed, either as a function of the OS install or by the Technician, Windows 10 Application Provisioning will apply settings to available profiles which may cause Microsoft Sysprep to fail during execution.

    For more information, please review: Sysprep fails after you remove or update Microsoft Store apps that include built-in Windows images

    How do I use Audit Mode?

    Step 1 – Boot the base image PC (Windows 10) to Audit Mode
    Remove the base image PC from Internet Access.

    Establish the base image; install the Windows 10 operating system, presumably from DVD media.

    After Windows installs necessary operating system files, (potentially requiring several reboots), the administrator will be presented with customization options.



    Settings Dialog Box


    Disable Auto Updates


    Do NOT select any options on this screen!




    Instead, initiate Audit Mode with the key combination CTRL+SHIFT+F3. The machine will then reboot and enter Audit Mode. This will prevent the creation of user profiles and the built-in Administrator account will automatically sign-in. A Sysprep dialog window will launch and should be minimized.



    Note: Once a machine has been booted into Audit Mode, it will remain in that mode, (regardless of reboots during software installation and configuration), until OOBE is explicitly initiated with Sysprep, either manually by executing Sysprep.exe or through the use of the Sysprep Assistant.



    In Audit Mode, the built-in administrator account is enabled by the system and allows the administrator to make all changes desired. Once sysprep is executed (with OOBE), this account will be disabled by default. For more information, please review Enable and Disable the Built-in Administrator Account.


    It should be stressed that Windows Store apps must not be allowed to automatically update (which they are set to do by default). It is strongly advised to leave the machine disconnected from any networks until Windows Store apps can be disabled from updating automatically, or leave it unplugged for the duration of setup.

    To disable Windows Store automatic updates:
    • Run: gpedit.msc (elevated privileges)
    • Navigate to Computer Configuration > Administrative Templates > Windows Components > Store
    • ul>



      gpedit.msc


      Disable Auto Updates


      Select “Enabled” for the setting: “Turn off Automatic Download and Install of updates”





      After Windows Store Apps automatic updates are disabled, attach the base image PC to a network with Internet Access.

      Step 2 – Customize the Windows 10 image
      With Audit Mode enabled, all changes to system (OS) settings as well as application settings will be made to the Default User profile which will be used later to create local PC users. Consider two types of applications that may be installed. Applications that are installed from executable files (e.g. setup.exe) will be referred to as Application Installations. Applications that are part of the Microsoft Store (provisioned applications) will be referred to as Microsoft Provisioned Apps.

      Application Installations may be launched from Windows File Manager by browsing and launching the appropriate executable.

      In order to install Microsoft Provisioned Apps, it is recommended to utilize PowerShell with the integrated module, PackageManagement or OneGet. PowerShell may need to be launched manually from the Windows folder.

      Navigate to C:\Windows\syswow64\WindowsPowerShell\v1.0 and then execute the powershell.ise application.

      In order to enable the installation of software from a package provider, rights must be extended to run scripts:

      Set-ExecutionPolicy Unrestricted

      Next, a package manager or provider must be selected. The package manager requires unrestricted script execution policy, which is why it was set first thing after PowerShell is launched. Add the provider using the Get-Packageprovider <PROVIDER> command.

      More information on this command can be found here: Get-PackageProvider

      Step 3 – Install the software required on all machines
      In order to install Microsoft Provisioned Apps, apply the Install-Package script.

      For example, to install Google Chrome, Adobe Reader, 7Zip and Brave:

      Find-Package –Name GoogleChrome, AdobeReader, 7zip, Brave | Install-Package

      The system may require a reboot to install an application and will return to Audit Mode post-reboot.

      Step 4 – Installing Windows Update (if desired)
      The Windows Update Center is dependent upon OOBE mode in order to apply updates and will fail in Audit Mode for operating systems newer than Windows 8.1. In this case, the PoerShell module PSWindowsUpdate may be used.

      Windows Update PowerShell Module

      Excerpt from Technet:
      Module can be installed manualy (sic) by downloading Zip file and extract in two places:

      • %USERPROFILE%\Documents\WindowsPowerShell\Modules
      • %WINDIR%\System32\WindowsPowerShell\v1.0\Modules
      Be sure to run the PSWindowsUpdate.cmd, As Administrator. After all available Windows Updates have been applied, the extracted module may be removed from the Windows folder.

      Step 5 – Remove built-in applications (optional)
      If desired, built-in applications may be removed using the following scripts: (This may no longer be a complete list)

      Get-AppxPackage *Twitter* | Remove-AppxPackage
      Get-AppxPackage *CandyCrushSaga* | Remove-AppxPackage
      Get-AppxPackage *solitairecollection* | Remove-AppxPackage
      Get-AppxPackage *bingweather* | Remove-AppxPackage
      Get-AppxPackage *bingnews* | Remove-AppxPackage
      Get-AppxPackage *bingsports* | Remove-AppxPackage
      Get-AppxPackage *3dbuilder* | Remove-AppxPackage
      Get-AppxPackage *windowsalarms* | Remove-AppxPackage
      Get-AppxPackage *Appconnector* | Remove-AppxPackage
      Get-AppxPackage *windowscalculator* | Remove-AppxPackage
      Get-AppxPackage *windowscommunicationsapps* | Remove-AppxPackage
      Get-AppxPackage *windowscamera* | Remove-AppxPackage
      Get-AppxPackage *officehub* | Remove-AppxPackage
      Get-AppxPackage *skypeapp* | Remove-AppxPackage
      Get-AppxPackage *getstarted* | Remove-AppxPackage
      Get-AppxPackage *zunemusic* | Remove-AppxPackage
      Get-AppxPackage *windowsmaps* | Remove-AppxPackage
      Get-AppxPackage *Messaging* | Remove-AppxPackage
      Get-AppxPackage *ConnectivityStore* | Remove-AppxPackage
      Get-AppxPackage *bingfinance* | Remove-AppxPackage
      Get-AppxPackage *zunevideo* | Remove-AppxPackage
      Get-AppxPackage *onenote* | Remove-AppxPackage
      Get-AppxPackage *people* | Remove-AppxPackage
      Get-AppxPackage *CommsPhone* | Remove-AppxPackage
      Get-AppxPackage *windowsphone* | Remove-AppxPackage
      Get-AppxPackage *photos* | Remove-AppxPackage
      Get-AppxPackage *WindowsScan* | Remove-AppxPackage
      Get-AppxPackage *windowsstore* | Remove-AppxPackage
      Get-AppxPackage *Office.Sway* | Remove-AppxPackage
      Get-AppxPackage *soundrecorder* | Remove-AppxPackage
      Get-AppxPackage *xboxapp* | Remove-AppxPackage
      Get-AppxPackage *XboxOneSmartGlass* | Remove-AppxPackage


      Step 6 – Preparing to use the UIU

      UIU Classic

      Within Audit Mode: Run the UIU Classic (including the import of or creation of a Sysprep answer file)

      Shutdown and capture, then deploy.


      UIU5

      Within Audit Mode: Complete the base image setup by executing Sysprep with appropriate flags:

      C:\Windows\System32\Sysprep\Sysprep.exe /unattend:<path to file>\filename /generalize /oobe

      For more information, please review: Methods for Running Windows Setup

      Shutdown and capture, then deploy with the UIU 5 product:
      UIU 5 - Quick Steps


      UIU Plug-ins 2.0 for MDT/SCCM

      Assuming that a base image was created and imported into MDT or SCCM:

      Within Audit Mode: Complete the base image setup by executing Sysprep with appropriate flags:

      C:\Windows\System32\Sysprep\Sysprep.exe /unattend:<path to file>\filename /generalize /oobe

      For more information, please review: Methods for Running Windows Setup

      Shutdown and capture, then deploy with the UIU Plug-ins2.0 product:
      MDT UIU Plug-ins 2.0 for MDT - Quick Steps

      SCCM UIU Plug-ins 2.0 for SCCM - Quick Steps

    What is this “Keylogger” business?
    In an era where we are all sensitive to computing security issues, whether it be from foreign powers, internal leaks, or from nefarious hackers, we are increasingly bombarded with media reports about new and seemingly disastrous computer security vulnerabilities. Some of these threats are very real and some are a bit of a hyperbole. The reality of the situation is that each of these potential vulnerabilities must be assessed objectively for the impact that they may actually have on an organization or individual.

    For example, in 2017 when Equifax was breached and 145.5 million Americans’ personal information was exposed, the alleged culprit was a flaw in a design tool used to build web sites. The flaw was reported months before the attack. This is an example of a very real vulnerability resulting in very real losses.

    In another example, the KRACK wi-fi vulnerability, widely covered in the media, would allow malevolent parties to eavesdrop on the datastream when a device was connected to public wi-fi connections. This vulnerability seems very serious and indeed potentially could be. It must be stated that the reality of the situation is that devices are connected to various unknown or unsecured wi-fi routers on a regular basis without concern for the potential of exposed datastreams. Notably, the vulnerability could also be used to interject code, presumably malware, into unprepared websites in order to infect machines (think ransomware). However, an attacker would need to be within range of the targeted wi-fi network. This greatly diminishes the potential for damage in many cases. Also, the network traffic could be eavesdropped upon only if it is not encrypted (think HTTPS or VPN). So, is the vulnerability real? Yes. Is it serious? Well, it could be. If network services are sufficiently protected/encrypted, the risk is ultimately rather low.

    That brings us to the “keylogger” issue. Its name and description would lead us to believe that it is very dangerous, particularly when combined with other attacks designed to transfer the logged results of the keylogging to a nefarious party. In May of 2017, HP released an audio driver that contained the keylogger vulnerability. Again in December of 2017 HP released a touchpad driver that contained the same or similar vulnerability. The same questions apply. Is the vulnerability real? Yes. Is it serious? It could be. Again, if network services, particularly access to the logged results, are sufficiently protected, the risk is low. In the case of the touchpad driver, Synaptics claims that the keylogger feature is part of a “debug tool”:

    ”The debug tool cannot be turned on or used except by a person with Admin access and special developer tools. When turned on, the debug tool collects data in a proprietary binary format for a rolling memory buffer that gets either overwritten or deleted every time a power event happens.”


    That said, of course all of these vulnerabilities should be remediated. By the same token, steps should be taken, or in some cases should have been taken, to secure local access to machines and to secure communications over business (and public) networks. I know, I know… Mistakes happen; things get missed. We all do our best. On that note, Big Bang LLC takes each of these matters seriously when they are reported. We do our very best to insure that the drivers that are delivered with the UIU are the most recent and secure versions available from component manufacturers and OEMs. We encourage all of our customers to bring potentially vulnerable drivers to our attention so that we may update or eliminate them from consideration by the UIU.

    Reports of potentially vulnerable drivers may be submitted to UIU Support.

    Joining Lenovo Yoga laptops to a domain using an SCCM task sequence

    Factors:

    • Yoga model laptops
    • Windows 7x64
    • SCCM Current Branch
    • Domain Join
    • USB3 Ethernet dongle

    Summary:

    When deploying Windows 7 x64, particular Lenovo Yoga models do not successfully initialize the USB3 Ethernet dongle driver in time for the Join Domain function to succeed during mini-setup, resulting in a failure to join the domain.

    Testing:

    Big Bang Support has run a myriad of tests to isolate the USB3 driver, the Lenovo dongle driver, other dongle drivers, SCCM (Current Branch) Task Sequence settings, and hardware/BIOS settings.

    Results:

    • The drivers (USB3 and dongle) appear to install correctly in any case.
    • Non-Yoga models succeed in joining the domain (manually, through MDT, and through SCCM) each time.
    • Yoga models succeed in joining the domain when their BIOS (USB Boot) is set to disable USB3. (This is an expected result with Windows 7 as it is known to have some difficulties in general with USB3). Unfortunately, this disables USB3 support.
    • Incidental – the Yoga docking station will not PXE when the BIOS (USB Boot) is set to auto USB3. (Expected behavior according to Lenovo)
    • Various forums have revealed that this issue, (among others), appear to plague these models…

    Conclusions:

    Based on our findings, (for the Yoga series laptops specifically):
    • These models contain a proprietary set of on-board USB3 components, (presumably to accommodate the unique docking station connector).
    • These models appear to require an extended time period in order to install and initialize the USB3 hub and subsequently the USB Ethernet dongle.
      • In fact, when we manually installed the dongle driver (in WinPE), it took about 3½ minutes to simply install, which is an exceptionally long time to load. This is evidence that this is a hardware-related, timing issue.

    Proposed Solution:

    Add an additional Join Domain or Workgroup step to the SCCM task sequence (TS). Add the task post mini-setup; directly after the Setup Windows and Configuration task in the Setup Operating System group. This task will make an additional attempt to join the domain in the event that the mini-setup initiated join fails. Again, in the specific case of this hardware, it will attempt to join the domain after a sufficient amount of time has passed and the dongle driver (with its unusually long installation period) has successfully installed and initialized.

    Other solutions researched purported to accomplish the desired effect though scripting and other complicated configurations that required creating packages specific to the Yoga hardware, (which may interfere with other makes/models).

    Upon testing this procedure in SCCM Current Branch, we found that the Yoga tablet/laptop will successfully join the domain when the BIOS (USB Boot) is set to auto USB3.

    Additional Information:

    Furthermore, this additional Join Domain task appears to not cause an issue with other hardware, (which successfully join the domain during mini-setup), that is not susceptible to the proclivities of the Yoga hardware. Obviously, the procedure would need to be proven in any given customer environment and, if necessary, measures to isolate the additional Join Domain or Workgroup task could be scripted to isolate the process for the Yoga machines alone.

    Krack Wi-Fi vulnerability
    We at Big Bang have been following the news regarding the WPA2 hack known as Krack (key reinstallation attack).

    During the week of October 16, 2017, researchers announced the discovery of a vulnerability which exploits the WPA2 protocol and allows attackers to steal sensitive information from unencrypted communications. It may also allow attackers to inject code (presumably malware) into websites.

    "It’s important to keep the impact of KRACK in perspective: KRACK does not affect HTTPS traffic, and KRACK’s discovery does not mean all Wi-Fi networks are under attack."

    The list of Wi-Fi vendors/chipset manufacturers is extensive and Big Bang is in the process of searching/monitoring each vendor for updates to their wi-fi network drivers that specifically address the Krack vulnerability. This process is entirely subject to the availability of adequately-prepared drivers by the chipset manufacturers. We anticipate that this update will take place over a lengthy period of time and in fact, may not be realized for those vendors that are out of business, no longer supporting versions of chipsets or are not prepared to update their device drivers.

    If you become aware of a wi-fi network driver that specifically addresses the Krack vulnerability and you suspect that we have not yet encountered that driver, please bring it to the immediate attention of Big Bang Support.

    Thank you for your patience and assistance.

    For additional information, please refer to the following links:
    KRACK Vulnerability: What You Need To Know
    Key Reinstallation Attacks: Breaking WPA2 by forcing nonce reuse
    Here’s what you can do to protect yourself from the KRACK WiFi vulnerability

    Upgrade now to the UIU Plug-ins 2.0
    Automated driver management for OS deployments with the UIU just got even better!

    Big Bang is proud to announce the UIU Plug-ins 2.0. The UIU Plug-ins 2.0 is an upgrade to the existing 1.x versions of the UIU plug-ins for SCCM and MDT and is now available to all UIU customers.

    If you are currently using one or both of the UIU plug-ins for SCCM or MDT, please follow the appropriate UIU User Guides to download and install the UIU Plug-ins 2.0. The UIU Plug-ins 2.0 is designed to be installed alongside your 1.x implementation for a seamless upgrade experience.

    Once you have installed and verified that your 2.0 implementation is complete, you're ready to remove 1.x from your environment:

    1. Ensure that the UIU Machine Configuration Step has been removed from all Task Sequences. Task Sequences that still have the UIU Machine Configuration Step after the uninstall of 1.x will be unrecoverable without assistance of UIU Support. (Note: The 2.0 plug-ins will utilize the UIU Deployment Configuration Step.)

    2. Note that the 1.x uninstallation process will mandatorily remove files in the original source location! In order to preserve the existing UIU Repository, move the contents of the existing UIU Repository source location to a new UIU Repository source location to be used with the UIU Plug-ins 2.0. The UIU Repository source location is the root folder that contains the x86, AMD64, and Repository folders (some implementations may also contain SQL CE 4.0 and/or Components folders). Leave the empty source location folder there.

      UIU Plug-ins 2.0 Upgrade - Uninstall 1.x

    3. Modify the existing UIU Package in SCCM to use this new source location for use with UIU Plug-ins 2.0.

    4. Uninstall the UIU 1.x from Programs and Features in the Control Panel. When presented with the option to remove package(s), uncheck the box(es) to avoid removing the package(s)—this will allow for the removal of the UIU program files and the now-empty source location folder while preserving the package(s) in SCCM.

    UIU Plug-ins 2.0 Upgrade - Uninstall 1.x

    Please let us know how we can help, and we look forward to hearing what you think!

    HP Laptop Keylogger

    The problem

    An audio driver, supplied by Conexant for HP, may be covertly logging user keystrokes, creating a security issue.

    The driver software apparently monitors every keystroke a user makes due to a "debugging" section of code that was not removed prior to market release. The devices then store the key strokes in an file, unencrypted, on the hard drive.

    The audio driver provided by Conexant logs all keystrokes to a file or prints them to the system debug log, where the data, including user credentials, could be easily accessible.

    HP reports that "a potential security vulnerability caused by a local debugging capability that was not disabled prior to product launch has been identified with certain versions of Conexant HD Audio Drivers on HP products. HP has no access to customer data as a result of this issue."

    HP further asserts that the keylogger in question does not appear to be malicious. "There’s no evidence that the keylogger actually does anything with the keystrokes it captures beyond saving them to your PC."

    Impacted HP products are shown in the table at this link: HP Support Communication - Security Bulletin: Conexant HD Audio Driver Local Debug Log

    More resources: Ars Technica article: HP laptops covertly log user keystrokes, researchers warn


    How to Check if Your HP Laptop Has the Conexant Keylogger

    HP laptops released in 2015 and 2016

    Navigate to C:\Users\Public\ and see if you have a MicTray.log file. Double-click it to view the contents. If you see information about your keystrokes, you have the problem driver installed.

    If you do see data in this file, you’ll want to delete the MicTray.log file from any system backups it may be a part of to ensure the records of your keystrokes are erased. You should also delete the MicTray.log file locally to erase the record of your keystrokes.

    "To check whether this is happening, download and run Microsoft’s DebugView application (DebugView v4.81) . Look at the DebugView application and press some keys on your keyboard. If the Conexant audio driver is capturing keystrokes and printing them as debug messages, you’ll see many “Mic target” lines, each with a scancode. If you don’t see a MicTray.log file with keystrokes in it and you don’t have any “Mic target” output visible in DebugView, congratulations. Your system does not have the buggy audio driver software installed and running."

    How-To Geek article: How to Check if Your HP Laptop Has the Conexant Keylogger


    FIX

    HP has provided software updates for Conexant HD Audio Drivers: HP Support Communication - Security Bulletin: Conexant HD Audio Driver Local Debug Log

    If the fix hasn’t been released yet, or you can’t run Windows Update for some reason, you can remove the software that causes the problem. You will need to locate MicTray64.exe or MicTray.exe in Task Manager, right-click it, and select “End Task”. Then delete the MicTray.exe or MicTray64.exe file. This may inhibit some media function keys on your keyboard.


    When will Big Bang release a new UIU Driver Database?

    (As of May 18, 2017)


    UIU Support has acquired the repaired drivers for all available, UIU supported OS's and is testing a new database release at this time. This is our top priority, and please contact us if you'd like notice immediately upon release of this update.



    Fix a failed Application Install/Uninstall

    So, you’re sitting at your PC (or a customer/user’s pc) minding your own beeswax, just installing an application, or perhaps uninstalling an application when… BAM! Something awful hits the fan! Now the bloody thing is all locked up and not responding to any key strokes or mouse clicks. It won’t even let you open up Task Manager to see what in the hell it might be up to, even though you’re pretty sure that it’s up to absolutely nothing…


    Now, invariably, the user was standing, looking over your shoulder, absolutely clueless about the fact that you’re boned and about the fact that you too are absolutely clueless… (No, I’ve never been in that position!)


    If you’ve been working with PCs for any appreciable amount of time, any good troubleshooter knows that sometimes, for one reason or another, an install or uninstall will get “borked” and that usually happens at just the wrong moment, of course. Thank you Murphy, for that little gem of a “law”…


    What happens during application installation or uninstallation?

    Lots of stuff, really: files get copied, registry settings are potentially altered or created, active directory information may be read or altered, schema extensions may be initiated, operating system variables may be set, and Programs and Features registration is typically instantiated. Of course, it varies widely based on application demands and requirements… When, for various reasons, one of the necessary steps for an app install or uninstall doesn’t complete or fails outright, it can leave the app in a state of limbo, inhibiting the required re-installation of the app or, in extreme circumstances, it can inhibit the usefulness of the entire system. At the very least, it leaves administrators with a loss of confidence in the system and a dread that the problem is indicative of future time-consuming troubleshooting.


    What can you do when it all goes bad?

    I’ve personally used many methods in the past including registry/file scraping where I try to find all references to the app and ruthlessly (albeit recklessly) remove all discovered instances, in a subtle homage to Orson Wells. I’ve also tried clearing temp files and have, of course, resorted to the time-tested “restart and see if that helps” method, usually followed immediately by, “Ok, let’s see if a hard boot helps”. What else? I’ve restored from Restore Points, run OS diagnostics; I’ve even run some very questionable, 3rd party applications to “reset” the registry. Basically, I’ve tried everything short of waving chicken bones, drenched in the blood of the vanquished, under a full moon at midnight on a solstice. I’m saving that one for a really critical situation!


    Although some of these solutions have worked some of the time, most of them live in the “60% of the time, it works every time” category. Although there are not hard-and-fast, always effective methods, I’ve been made aware of some interesting tools from Microsoft and, so far, have had success with them. I thought others may appreciate knowing about them.


    Microsoft FixIt – Fix problems with programs that cannot be installed or uninstalled

    This tool is so simple to execute that I’m having difficulty elaborating, so perhaps for once, I won’t. Suffice it to say that the UI is intuitive.


    Download MS Fix It - Fix Problems - Install/Uninstall

    Choose desired level of automation:


    MS Fix It Troubleshooter

    Indicate when the problem occurs:


    MS Fix It uninstall install

    Select the affected product (this example = uninstall):


    MS Fix It select affected program

    When the process is complete, you’ll receive a results screen indicating that it was (or was not) able to resolve the problem. It’s that simple.

     

    Microsoft MsiZap

    This tool is a bit more involved and, I presume, a bit more risky — think of “malware detection programs reminding you that removing some discovered items may result in the untimely death of your OS” risky. The tool removes all Windows Installer information for one or more applications on a PC through the clever use of Product Codes. With command line options, you can also elect to remove rollback information, remove the “In-Progress” key, or even change ACL’s to Admin Full Control.

    Download MsiZap

    As the command line nature of the application can be a bit unwieldy, I’ve included a link to examples of its use as well. Heads-up! You’ll need to be able to determine Product Codes for applications that you’d like to target. Fun!


    Syntax Examples:

    MsiZap Examples


    That's all for now


    In summary, we all have our methods; some of those methods are more sound than others or at least more based in actual computer science and we’ll likely continue to employ what we perceive to have worked for us in the past. That’s great. Here are two more for your arsenal. Godspeed, John Glenn!




    Archives

    • 2019
    • 2018
    • 2017
    • 2015
    • 2014
    • 2013
    • 2012