Drivers ENE Others

• Drivers Ene Others Email
• Drivers Ene Others Meaning
• Drivers Ene Others Wanted
• Drivers Ene Others Crossword Clue

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. Download Acer support drivers by identifying your device first by entering your device serial number, SNID, or model number.

ENE offers Municipal Utilities and other organizations customized and comprehensive EV Awareness and Education program services including:

• Branded EV resources website
• EV Specialist support services via web, email and phone
• Marketing strategy, planning and collateral development
• Events planning and execution – display and/or test drives
• Charge management, Level 2 and vehicle incentive programs
• Dealership engagement and incentive programs
• EV Ambassador training and support programs
• Commercial charging utility infrastructure programs (public, multi-dwelling units, retail, etc.)
• Collaboration with leading EV service providers and local EV advocacy partners
• EV consulting services tailored to the client’s need

Get information about local and state rebates for electric vehicles and home charging equipment, as well federal incentives that lower the cost to purchase or lease.

Get connected with the EV champion local car dealers and certified home charging equipment installers to make shopping for and setting up an EV that much easier.

Get the latest local and regional EV news and events information to stay connected with the accelerating technology and your local EV community

• 5 Hampshire St., Suite 100
  Mansfield, MA 02048
• 508-698-1200
• 508-698-0222

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.

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.

Drivers Ene Others Email

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

Drivers Ene Others Meaning

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.

Drivers Ene Others Wanted

Hashes:

Drivers Ene Others Crossword Clue

175eed7a4c6de9c3156c7ae16ae85c554959ec350f1c8aaa6dfe8c7e99de3347

61a1bdddd3c512e681818debb5bee94db701768fc25e674fcad46592a3259bd0

06bda5a1594f7121acd2efe38ccb617fbc078bb9a70b665a5f5efd70e3013f50

9fc29480407e5179aa8ea41682409b4ea33f1a42026277613d6484e5419de374

810513b3f4c8d29afb46f71816350088caacf46f1be361af55b26f3fee4662c3

38c18db050b0b2b07f657c03db1c9595febae0319c746c3eede677e21cd238b0