1. Drivers Enforcement
2. Energia Drivers
3. Drivers Energy Dawson Ga
4. Enedo Drivers

PC Data Center Mobile: Lenovo Mobile: Motorola. ENE specializes in IC design focusing on mobile device, wireless charger, capacitive sensor button, embedded controller & embedded micro-controller. We provide timely service & excellent products to serve diverse demands. Our main customers include key-brand manufacturers of household appliances and various mobile devices. Download HP Pavilion dv7-1220ef ENE CIR Receiver Driver v.2.5.0.0 A for Windows 7, Windows 7 64-bit, Windows Vista, Windows Vista 64-bit. Download is free of charge.

Intro

ENE Technology Inc is a Taiwan based company founded in 1998. According to their website hxxp://www.ene.com.tw/index-en.php and Bloomberg summary: ENE Technology Inc. develops, manufactures, and markets IC (integrated circuit) products. The Company's products include application-specific integrated circuits (ASICs), controller ICs for power switches, and notebook keyboards.

Ene.sys is a Windows driver. A driver is a small software program that allows your computer to communicate with hardware or connected devices. This means that a driver has direct access to the internals of the operating system, hardware etc.

However most of you will probably know them by piece of software - a ridiculously bugged driver bundle that shipswith multiple software products of variety of hardware vendors,including but not limited to MicroStar, MicSys, ASUS, ASRock and someothers. It is written by a very interesting developer(s) and Ibelieve it is the same for all multiple variants of this driver bundle. Thefigure(s) behind this driver is awesome as I encounter their'creativity' multiple times and each time they manage to surprise me in a way when you expect that it can't be worse.

Lets say what will happen whenyou hire someone with mediocre C-language understanding, whodiscovered official documentation just in 2020 but has a great google searchskills? Nothing really bad, most of AV companies arefull of such people (its a joke), but at least they have someone who can controlthem. ENE Technology Inc software products that will be discussed nextis an example of what happens when no one control such people andtheir 'creativity'.

It's all about I/O

When it comes to hardware vendors giveio type drivers in 90% it is all based on three main sources:

• Windows DDK samples that are dated back to Windows NT 3.51 (hello Unwinder);
• WinRing0 open sourced library by hiyohiyo (CrystalMark author);
• WinIO open sourced library by Yariv Kaplan (from internals.com).
  

Just a coupe of bugs inside these sources:

1. No requestor access rights check - all driver devices are created with default security descriptor meaning everyone have read/write access to them;
2. No input parameters checking or they are insufficient/incorrect - easy way to crash your system from any user;
3. Unrestricted functionality - you can read/write anywhere, any ports, MSR's.
   

Currently hardware vendors are mostly blatantly copy-paste from these sources with minimal changes, if any. Sometimes their drivers contain functionality their products does not need at all.

Reasons why this is a bad approach:

• All of the above were created without any kind of security in mind. It was forgivable to old DDK samples but totally inappropriate for everything else. So this code is failure by design and created with Windows XP in mind;
• Original codebase contain obvious programming mistakes - HW vendors mostly don't care and rarely fix anything.
  

It is a common trend for almost EVERY gaming hw vendors available today.

When it comes to ENE Tech Inc drivers they are based on WinIO of 3.0 version. My first encounter was ASUS GLCKIo2 driver.

It was all about same copy-pasta, but with ridiculous addition. This driver was 'locked' for non trusted application access. This mean you have to 'register' yourself as a good caller before doing any other job with this driver. This is fascinating - author more worried about who will be using his driver more than quality of driver code he copy-pasted. The 'unlocking' process of GLCKIo2 driver was the following:

1. In client application - call GetCurrentProcessId(), modify result with SWAP_UINT32 macro;
2. Copy result to local 16 bytes length buffer;
3. Encrypt this buffer with AES ECB, using TinyAES open source code, as key they used slightly modified values found in Google search (😎);
4. Call driver with special IOCTL passing encrypted buffer as input parameter;
5. Driver processes this IOCTL, decrypts buffer (same TinyAES) and extracts PID to remember it in internal list of 'trusted' applications;
6. When other IOCTL called - driver checks if this call is from process with ID in trusted list - if so call allowed, otherwise access denied error will be returned to caller.

It is merely a joke than anything else. Full unlocking -> https://gist.githubusercontent.com/hfiref0x/3d46c012eb6cffcba34f0006d38e5165/raw/b2792823f85bdd4d5a91a8c802d6f57320ad2cc1/GLCKIo2.c

Next I found ENE.sys driver signed with 'Ptolemy Tech Co' certificate. It was based on WinIO but missing all these locking features. Curiously enough it contain the following pdb string: d:winglckio_20180320amd64EneIo.pdb

It is hard to tell which one was the first, but ASUS lock feature may have explanation. Well, ASUS drivers were loved target for CVE scalpers - easy to get and sort of 'addition' to infosec portfolio. If you google for GLCKIo driver you will find a lot of CVE noise around it, for example https://seclists.org/fulldisclosure/2018/Dec/34. With initial discovery in the end of 2017. So we can assume that this GLCKIo2 is a sort of response.This could explain caller registration introduction and code base switch. As 'fix' it is pathetic and fixes nothing. This is not an ASUS only fault - all the above mentioned companies does the same. In general they give zero fuck about security of their customers, especially MSI.

Looking for more ASUS bugged drivers (there are LOT of them) I found an interesting coupe next. AsIO.sys (device name Asusgio) and AsIO2.sys (device name Asusgio2). First driver is an old standard copy-paste which has CVE noise assigned, second one is from our beloved ENE Tech Inc coders.

Specific code similarities found inside both drivers led to idea that they are both created by same author/team. It is slightly modified WinIO codebase (no bugs fixed, instead added more chaos) with another 'driver lock', implemented in unusual way. The unlocking is only allowed from process that has specific PE resource inside named 'ASUSCERT'. That is how it generated:

1. Query current timestamp with GetSystemTimePreciseAsFileTime;
2. Convert it to seconds since 1970;
   
3. Copy value to 16 bytes length buffer and encrypt it using AES ECB (TinyAES again);
4. AES key again found in Google search and slightly modified;
5. Move result encrypted buffer to PE resources as 'ASUSCERT' (without quotes).

When caller does request to the driver (any IRP_MJ_*) driver will query full image path of the caller, read file into buffer and parse for PE timestamp and RCDATA resource named ASUSCERT, decrypt it and extract timestamp. Next AsIO2 will check if the difference between PE timestamp and decrypred timestamp < 7200 (2 hours). If it is - then caller will be allowed to use driver. Thus to be able use this driver you just need a properly generated resource.

This obviously can't be threatened as security fix.

Using same pattern I found several other drivers. For example driver called EneTechIo.sys (E:GitSourceCodeEneSmbusSDKdriver_srcEneIox64ReleaseEneIo.pdb)

WinIO based, locked driver as usual. However they again changed unlocking algorithm. Instead of using PE resource they now passing encrypted buffer directly in each driver call as part of input data structure. Every payload driver function now checks if the call time within a small time window (few seconds). Unlocking it looks like this:

Worth to mention some debug version of Ene driver. It is lock free, has multiple DbgPrint's and contain the following pdb string (d:winglckio_20180320amd64EneIo.pdb).

As of recent EneTechIo driver from fresh up-to-date of this post MSI Dragon Center bloatware (E:GitSourceCodeIoAccessSmbusSDKdriver_srcEneIox64ReleaseEneIo.pdb).

Key changes:

1. TinyAES is no longer used, they switched to CNG (maybe also found it while doing usual Google searches for copy-pasta ready code);
2. MSR related code removed;
3. Introduced new requestor whitelisting check.

Driver setups image load notify callback (PsSetLoadImageNotifyRoutine) and looks for event when SB_SMBUS_SDK.dll is loaded. Note that name of dll is case sensitive. This dll is an API layer for interacting with EneTech driver. If filename contains SB_SMBUS_SDK.dll then driver will register process by it ID extracted from notify callback. No further checks implemented, so basically you can create dumb empty dll with SB_SMBUS_SDK.dll name, load it in your process and this driver will register you as trusted caller. Everything else will be the same as AES encoding mode is same and their implementations of course has no differences.

Code to unlock -> https://gist.githubusercontent.com/hfiref0x/bff37d328cb16d3df92f8743b4b054ca/raw/595531f209771943cecce799afd954029ba02b80/enetech_new.c

ENE Tech Inc authors doing everything possible (for them) to complicate their driver usage by third-party actors. Instead of fixing generic WinIO 'bugs and features' they constantly (and with no success) reinventing the wheel.

P.S. Very company, very ENE Technology Inc.

When I found their website in Feb 2020 I was very surprised by it English section, because it was all full of 3rd party web injected links.

Hashes:

175eed7a4c6de9c3156c7ae16ae85c554959ec350f1c8aaa6dfe8c7e99de3347

61a1bdddd3c512e681818debb5bee94db701768fc25e674fcad46592a3259bd0

06bda5a1594f7121acd2efe38ccb617fbc078bb9a70b665a5f5efd70e3013f50

9fc29480407e5179aa8ea41682409b4ea33f1a42026277613d6484e5419de374

810513b3f4c8d29afb46f71816350088caacf46f1be361af55b26f3fee4662c3

38c18db050b0b2b07f657c03db1c9595febae0319c746c3eede677e21cd238b0

The section includes the following topics about the operation of the HID class driver:

• Operational features of the HID class driver
• Binding the operation of the HID class driver to a HID minidriver
• Communicating with a HID minidriver

See Creating WDF HID minidrivers for more information.

Operational features of the HID class driver

The HID class driver does the following:

• Provides and manages the upper-level interface that kernel-mode drivers and user-mode applications use to access the HID collections that an input device supports.

  The HID class driver transparently manages and routes all communication between upper-level drivers and applications and the underlying input devices that support HID collections. It manages the different data protocols that are used by different input devices and input queues that support more than one open file on the same HID collection.

  The upper-level interface to HID collections consists of the HID class driver IOCTLs, the HIDClass support routines, and the HIDClass structures.

• Communicates with a HID minidriver by calling the minidriver's standard driver routines.

• Creates a functional device object (FDO) for HIDClass input devices enumerated by a lower-level bus or port driver.

  For example, the HID class driver creates and manages the operations of an FDO that represents a USB HID device enumerated by the system-supplied USB driver stack.

• Provides the functionality of a bus driver for the child devices (HID collections) supported by an underlying input device.

  The HID class driver creates a physical device object (PDO) for each HID collection supported by an input device and manages the collection's operation.

Binding a minidriver to HIDClass

A HID minidriver binds its operation to the HID class driver by calling HidRegisterMinidriver to register itself with the HID class driver. The registration operation does the following:

• Saves a copy of the entry points (pointers) to the HID minidriver's standard driver routines in the HID class driver's device extension.

  A HID minidriver sets its entry points in the driver object that the minidriver receives as input to its DriverEntry routine. The HID minidriver sets these entry points before it registers with the HID class driver.

• Resets the entry points in the minidriver's driver object to the entry points for the standard driver routines supplied by the HID class driver.

The HID class driver supplies the following standard driver routines:

• AddDevice and Unload routines

• Dispatch routines for the following I/O requests:

The registration process also allocates memory for the HID mindriver device extension. Although the memory is allocated by the HID class driver, only the HID minidriver uses this device extension.

Communicating with a HID minidriver

The HID class driver communicates with a HID minidriver by calling the HID minidriver's AddDevice, Unload, and dispatch routines as follows:

Calling the AddDevice Routine

When the HID class driver's AddDevice routine is called to create a functional device object (FDO), the HID class driver creates the FDO, initializes it, and calls the HID minidriver AddDevice routine. The HID minidriver AddDevice routine does internal device-specific initialization and, if successful, returns STATUS_SUCCESS. If the HID minidriver AddDevice routine is not successful, the HID class driver deletes the FDO and returns the status returned by the HID minidriver AddDevice routine.

Calling the Unload Routine

When the HID class driver Unload routine is called, the HID class driver completes releasing all resources associated with FDO and calls the HID minidriver's Unload routine.

Calling the Dispatch Routines

To operate a device, the HID class driver primarily calls the HID minidriver dispatch routine for internal device control requests.

In addition, when the I/O manager sends Plug and Play, power, or system control requests to the HID class driver for an FDO, the HID class driver processes the request, and calls the HID minidriver's corresponding dispatch routine.

The HID class driver does not send the following requests to the HID minidriver: create, close, or device control.

Operation of a HID minidriver

A HID transport minidriver abstracts the operation of a hardware bus or port that your input device attaches to.

HID minidrivers can be built using one of the following frameworks:

• UMDF – User Mode Driver Framework
• KDMF – Kernel Mode Driver Framework
• WDM – Legacy Windows Driver Model

Microsoft recommends using a Frameworks based solution (KMDF or UMDF (on Windows 8 only)). For more information on each of the driver models, please visit the following sections:

• KMDF-based HID minidriver, see Creating Framework-based HID Minidrivers
• UMDF-based HID minidriver, see Creating UMDF-based HID Minidrivers

The following section talks about registering a WDM based HID Minidriver but much of it is pertinent to a KMDF based Frameworks driver also. All HID minidriver must register with the HID class driver, and the HID class driver communicates with the minidriver by calling the minidriver's standard driver routines.

For more information about the functionality that a HID minidriver must support in its standard driver routines, see the following topics:

• Registering a HID Minidriver
• HID Minidriver Driver Extension
• Using the HID_DEVICE_EXTENSION Structure
• Standard Driver Routines Provided by a HID Minidriver

For more information about the HID class driver, see Operation of the HID Class Driver

Drivers Enforcement

Registering a HID minidriver

After a HID minidriver completes all other driver initialization in its DriverEntry routine, the HID minidriver binds its operation to the HID class driver by calling HidRegisterMinidriver.

When the HID minidriver registers with the HID class driver, it uses a HID_MINIDRIVER_REGISTRATION structure to specify the following: HID revision, the HID minidriver driver object, the size of a HID minidriver device extension, and whether devices are polled or not.

HID minidriver extension

A HID minidriver device extension is device-specific, and is only used by a HID minidriver. The HID class driver allocates the memory for the minidriver device extension when the class driver creates its device extension for a functional device object (FDO). The HID minidriver specifies the size of its device extension when it registers the minidriver with the HID class driver. The size is specified by the DeviceExtensionSize member of a HID_MINIDRIVER_REGISTRATION structure.

Using the HID_DEVICE_EXTENSION structure

A HID minidriver must use a HID_DEVICE_EXTENSION structure as the layout for the device extension created by the HID class driver for a functional device object (FDO). The HID class driver sets the members of this structure when it initializes the FDO. A HID minidriver must not change the information in this structure.

A HID_DEVICE_EXTENSION structure contains the following members:

• PhysicalDeviceObject is a pointer to the physical device object (PDO) that represents the underlying input device.

• NextDeviceObject is a pointer to the top of the device stack beneath the FDO.

• MiniDeviceExtension is a pointer to the HID minidriver device extension.

Given a pointer to the FDO of an input device, the following GET_MINIDRIVER_DEVICE_EXTENSION macro returns a pointer to a HID minidriver extension:

PDEVICE_EXTENSION is a pointer to a device-specific device extension declared by a HID minidriver.

Similarly, a HID minidriver can obtain a pointer to the input device's PDO and the top of the device stack beneath the input device's FDO.

When a HID minidriver sends an IRP down the device stack, it should use NextDeviceObject as the target device object.

Standard minidriver routines

A HID minidriver must provide the following standard driver support routines:

• HID Minidriver DriverEntry Routine
• HID Minidriver AddDevice Routine
• HID Minidriver Unload Routine

A HID minidriver must also support the dispatch routines described in Dispatch Routines Provided by a HID Minidriver.

DriverEntry routine

The DriverEntry routine in a HID minidriver does the following:

• Creates a driver object for the linked pair of drivers (HID class driver and a HID minidriver).

• Sets the required driver entry points in the HID minidriver driver object.

• Calls HidRegisterMinidriver to register the HID minidriver with the HID class driver.

• Does device-specific configurations that are only used by the HID minidriver.

AddDevice routine

The HID class driver handles creating and initializing the functional device object (FDO) for an underlying input device. The HID class driver also operates the FDO from the perspective of the upper-level interface to the underlying device and its child devices (HID collections).

The HID class driver AddDevice routine calls the HID minidriver AddDevice routine so that the minidriver can do internal device-specific initialization.

The parameters that are passed to the HID minidriver AddDevice routine are the minidriver driver object and the FDO. (Note that the HID class driver passes the FDO to the minidriver AddDevice routine, not to the physical device object for the underlying input device.)

The HID minidriver AddDevice routine obtains a pointer to the minidriver device extension from the FDO.

• Typically, the HID minidriver AddDevice routine does the following:

• Initializes the minidriver device extension. The device extension is only used by the minidriver.

• Returns STATUS_SUCCESS. If the minidriver returns an error status, the HID class driver deletes the FDO and returns the error status to the Plug and Play manager.

Unload routine

The Unload routine of the HID class driver calls the HID minidriver Unload routine. A HID minidriver releases any internal resources allocated by the minidriver.

Dispatch routines

A HID minidriver must supply the following dispatch routines: create, close, internal device control, system control, Plug and Play, and power management. Except for internal device control requests, most of these dispatch routines provide minimal function. When the HID class driver calls these dispatch routines, it passes the minidriver driver object and the functional device object (FDO).

IRP_MJ_CREATE

In compliance with WDM requirements, the HID class driver and a HID minidriver provide a dispatch routine for create requests. However, the FDO cannot be opened. The HID class driver returns STATUS_UNSUCCESSFUL.

A HID minidriver only needs to provide a stub. The create dispatch routine is never called.

IRP_MJ_CLOSE

In compliance with WDM requirements, the HID class driver and a HID minidriver must provide a dispatch routine for close requests. However, the FDO cannot be opened. The HID class driver returns STATUS_INVALID_PARAMETER_1.

A HID minidriver only needs to provide a stub. The close dispatch routine is never called.

IRP_MJ_DEVICE_CONTROL

A HID minidriver does not need a dispatch routine for device control requests. The HID class driver does not pass device control requests to a minidriver.

IRP_MJ_INTERNAL_DEVICE_CONTROL

A HID minidriver must provide a dispatch routine for internal device control requests that supports the requests described in HID MinidriverIOCTLs.

The HID class driver primarily uses internal device control requests to access the underlying input device.

The HID minidriver handles these requests in a device-specific way.

IRP_MJ_SYSTEM_CONTROL

A HID minidriver must provide a dispatch routine for system control requests. However, a HID minidriver is only required to pass system control requests down the device stack as follows:

• Skip the current IRP stack location

• Send the request down the FDO's device stack

IRP_MJ_PNP

A HID minidriver must supply a dispatch routine for Plug and Play requests.

Energia Drivers

The HID class driver does all the Plug and Play processing associated with the FDO. When the HID class driver processes a Plug and Play request, it calls the HID minidriver Plug and Play dispatch routine.

A HID minidriver Plug and Play dispatch routine does the following:

• Handles sending the request down the FDO's device stack and completing the request on the way back up the device stack, as appropriate for each type of request.

• Does device-specific processing associated with certain requests to update information about the state of the FDO.

  For example, the minidriver might update the Plug and Play state of the FDO (in particular, whether the FDO is started, stopped, or in the process of being removed).

IRP_MJ_POWER

The HID minidriver must supply a dispatch routine for power requests. However, the HID class driver handles the power processing for the FDO.

Drivers Energy Dawson Ga

In compliance with WDM requirements, a HID minidriver sends power requests down the FDO's device stack in the following way:

• Skips the current IRP stack location

• Starts the next power IRP

• Sends the power IRP down the FDO's device stack

Enedo Drivers

Typically, the HID minidriver passes power requests down the device stack without additional processing.