Archive of original discoveries by disappointed EFiX™ customer

The following is an archive of the original finding by a disappointed EFiX™ customer. The author was forced to take down his site due to legal threats from ASEM (maker of the module). Although these threats are baseless we all know that it takes time and money to fight a legal challenge, thus its more economical to abide by their request. ASEM is trying to silence whistle blowers ... but the community will not let them. This is my small contribution.

More here:
http://www.tomshardware.co.uk/asem-efix-mac-chameleon,news-31841.html
and another copy of this here:
http://efixsucks.wordpress.com/
community of ex-efixers:
http://efixusers.com/

Here are autopsy pictures of my v1.1 showing the only difference being the hack addition of two caps and a replacement regulator on the back:

September 10, 2009 – 3:56 pm

The EFiX™ dongle does not use DSDT patching. You can easily proof it by dumping the DSDT with ioreg. But the Gigabyte DSDTs are having problems with AppleIntelCPUPowermanagement.kext and AppleRTC.kext. If you try to boot OS X with an original, unmodified DSDT it will crash. So EFI-X™ must use something like Disabler.kext. Under Chameleon with Disabler.kext you can see that it is loaded with kextstat:

Under EFiX™ there is nothing like Disabler.kext visible. kextstat shows only 2 kexts with are ASEM related. I marked this 2 green:

Studying dmesg outputs I found out, that EFiX™ does inject a AppleIntelCPUPowermanagement.kext. Why they are doing this? For this kext Apple did not released the source code. So I made a kextstat on a system with a original Apple AppleIntelCPUPowermanagement.kext:

…

The original Apple one is much bigger in size 0×1f000 instead of 0×2000 under EFiX™. EFiX™ also has a much higher version number, higher as the latest version from Apple; 79.0.3 vs. 76.2.0. Could it be, that EFiX™ is using Disabler.kext only renaming it to AppleIntelCPUPowermanagement.kext? Yes, I think so. The sizes are equal. They must use something to disable the AppleIntelCPUPowermanagement.kext, because they use an unpatched DSDT. The higher version number is necessary to load the kext from the EFiX™ instead the one from the OS X installation. And finally EFiX™ produces the same Syslog-messages as Disabler.kext.

Do you remember what ASEM told us about EFiX™. There are some interviews available in the net: here or take this one. Two quotes:

…First of all, the EFiX is absolutely not related to the hackintosh underworld. It doesn’t use a single line of patched code, and I am going to explain to you why…

What is your company’s stance on the linking of the EFiX BPU to the Hackintosh/OSX86 world?

DR: Although I don’t have any personal grudge towards them, linking us to them is not correct. Our approach is entirely different, and contrarily to them all our code and development is our own only, and we don’t hack anything at all.

No comments about that. EFI-X™ is SCAM!!! They are using work from the OSx86 community without admitting it. They are even trying to stealth the usage as much as possible. But this does not help at all. Time will tell the truth.

September 10, 2009 – 3:49 pm

As promised here are some new infos and highres photos of the disassembled EFI-X™ dongle. If you ever wondered what’s inside the EFiX™, what’s behind the “myth” created by ASEM around this device, here you will find some answers.

I could find out which microcontroller is used for the EFI-X™. It was not that difficult. Searching for a microcontroller:

1. with a 64-Pin TQFP package
2. and USB support
3. an oscillator connected to pins 5 & 6
4. USB D-/D+ connected to pins 44 & 45

… gaves me very quickly a Cortex™ M3 from STMicroelectronics. A test with a spectrum analyser ruled out, that the microcontroller runs very likely at 72Mhz. Got a peak at 8Mhz (the resonator frequency), a small peak at 36Mhz, a strong peak at 72Mhz and another small peak at 108Mhz (72+36). So the microcontroller must be a STM32F103Rx. To figure out the exact model one must connect a JTAG debugger. The pads to do so are there.

Sealing the PCB with a black plastic, lasering off partnumbers, being that “insane paranoid” (WD know what I mean , didn’t help at all to find out of what the EFI-X™ is made of. For nothing.

The EFI-X™ V1.0 has no ESD Protection for the USB data lines D+/D- and a very simple 3.3V DC/DC converter. This is important and could explain, why so many EFI-X™ V1.0 modules are disappearing from BIOS, are going defect, like mine did. Another hint in this direction is the EFI-X™ V1.1 module itself: USB data line ESD protection, overvoltage controller, high quality Quartz Resonator. And have a look at the expresshd.com Bestseller List. 2nd place is EFI-X™ V1 Replacement