I don't know what the potential issue(s) may come with installing an older/newer version of the battery.dll driver on a given device so I'll say now that I am providing versions here for each device people request in this thread (see below for what is currently available). These are NOT the same as the version released by Chainfire. You have to use a HEX editor to check the DLL version that comes with your device, so its somewhat a pain. Hopefully people that know how can post here elaborating on the specific device they have and what version DLL it comes with.
- 2009.09.24 All versions *.1
- Updated Q-Mobile (Code) certificates to last until 2035.01.31.
Yes, I'm an idiot and the Q-Mobile certificates I created originally lasted 30 days. If yours is still working you don't need this until/unless you reinstall and need a new version. They won't expire again I promise
Thanks to LifeStealer for providing the battery.dll that comes with US Sprint Touch Pro 2 devices.
Thanks to twolostminds for providing the battery.dll that comes with US Verizon Touch Pro 2 devices.
In case people want to know more precisely what's happening here I'll briefly mention what is involved in the hack.
The actual modification of the stock battery.dll on the device is merely four (4) bytes. This is due to a simple return statement. There exists a subroutine within the driver that is called with a precise percentage of the battery level. The subroutine then uses an algorithm to determine a 10% increment level to return, which is then subsequently reported by the driver. By simply inserting a return statement at the beginning of the subroutine it returns the same 1% increment value that was passed to it to begin with. Voila! So no need to worry about any adverse effects the hack could have.
The trick of course is that since it runs as a driver on the machine it needs to be digitally signed (on a stock/secured device, that is). Changing those four bytes invalidates the current digital signature of the file, so it needs to be signed again. Of course, merely signing the DLL file won't work as your signature probably isn't trusted in the device's certificate store. So as part of the CAB installation process, the certificate you signed with must be installed in the "Privileged Execution Trust Authorities" store on your device so that when the file loads the certificate is recognized as a trusted authority for digitally signing code that can run on the device.
This is where things get sort of interesting. It is common practice here on XDA Developers for people to use the SDK sample certificates to sign files, and then request that you install trust for those certificates. The obvious security flaw here is that ANYONE can sign files with those certificates (even malicious code), thus invalidating the security mechanism in the first place. This essentially puts you in the same group of people who disable security prompts on their device (manually or by installing a CAB that does so), and ROM developers who disable it or install the SDK certs as trusted.
Of course there is no real "problem" per se with disabling (or allowing the circumvention) of the security features of the new version of windows mobile, its just that you are disabling/crippling a potentially useful feature.
Hence, I sign my files with my own 2048 bit certificate that is strictly under my control. Thus by installing any Q-Mobile application (and in the future ROM) your security will remain tight with the only applications implicitly trusted are those I signed.
Anyway, enough for now, that's probably way more than you ever wanted to know. Cheers!