Database Users

Simple Reverse Engineering

I'm currently doing a little reverse engineering of Coredll so that I can understand how a few functions work. Occasionally I run across a function call to an address similar to F000BDD8. Is this a function call into the kernel or does it correspond to an address in the dll? If someone could point me to the correct reference, I'd appreciate it.
This is how it is layed out:
LDR r0, &0000b650
MOV lr, pc
MOV pc, r0
And at address 0000b650 the value is F000BDD8.
Thanks!

it is something like a "syscall" command on WinCE. The "FIRST_METHOD" value (0xF0010000) is subtracted form the given address, then value is divided by 2 (in your case we get -8468 or 0xff..ffdeec). If the value is negative it is "API call to an implicit handle. In this case, bits 30-16 of the method index indicate which entry in the system handle table." (probably its a typo in comment, bits 8-22 are used instead of 30-16). Lower bits are offset in SystemAPISets[] table for the function address.
For more information look into PrefetchAbort function in "PRIVATE\WINCEOS\COREOS\NK\KERNEL\ARM\armtrap.s" file, and ObjectCall function in "PRIVATE\WINCEOS\COREOS\NK\KERNEL\objdisp.c"
You should get PlatformBuilder and look into Wince 4.20 partial source code that is coming with it. It does not have much information on indexes inside SystemAPISets table for any table except for SystemAPISets[SH_WIN32] (SH_WIN32 == 0).

see this page for a list of systemcalls.
and this page for a description of how systemcalls work.
to convert a trap address ( like 0xF000BDD8 ) back to the syscall nrs:
Code:
$a= (0xf0010000-$addr)/4; # = 0x108a
$api=$a>>8; # 0x10 = SH_GDI
$call=$a&0xff; # 0x8a = ExtCreateRegion
( call defined in public/common/oak/inc/mwingdi.h )
hmm. not sure which is correct though, my wince-systemcalls page lists a different call signature than the headerfile. they should match.

Thank you for the information. I actually have the sample source that comes with the Platform Builder demo. In this case, the call I was investigating was the GetSysColorBrush API.
That brings me to another point. In several of the APIs a check is made to a value (KData->lpvTls[-20], I believe) to see if the 0-bit is 1. The only thing I can determine is whether or not this is checking for the ready state of the API. Whatever the case, it seems that this bit determines whether the function I mentioned earlier is called or whether a function address is loaded from RAM. It's really weird.
The main reason I'm doing this is so that I can access the system's brush cache for the system colors. I've noticed that if I intercept calls to GetSysColor and GetSysColorBrush, it only works for applications that have not called them yet. So, if I override the color for COLOR_BTNFACE, menubars for newly launched applications are colored correctly, but buttons (which belong to GWES) do not use the appropriate color. It's weird because my code has been injected into GWES.Exe.
I guess that brings me to my ultimate question of whether or not someone can point me to the location in RAM where the system brush cache is stored.
Thanks!

is the '-20' in bytes ?
in PUBLIC/COMMON/OAK/INC/pkfuncs.h
#define PRETLS_THRDINFO -5
#define UTLS_INKMODE 0x00000001 // bit 1 set if in kmode
#define IsThrdInKMode() (UTlsPtr()[PRETLS_THRDINFO] & UTLS_INKMODE)
this must be the bit that is set when calling 'SetKmode();'

Yeah, the -20 is in bytes. Here's the disassembly of what I was looking at:
00B5EC E59F6068 LDR r6, &0000B65C
00B5F0 E59F5060 LDR r5, &0000B658
00B5F4 E5960000 LDR r0, [r6, #0]
00B5F8 E5101014 LDR r1, [r0, #-20]
00B5FC E3110001 TST r1, #1
00B600 15950000 LDRNE r0, [r5, #0]
...
00B650 F000BF08 ANDNV r11, r0, r8, LSL #30
00B654 01FC6758 MVNEQS r6, r8, ASR r7
00B658 01FC6760 MVNEQS r6, r0, ROR #14
00B65C FFFFC800 SWINV &FFC800 <-- Points to KDataStruct
What you said makes sense, yet it seems kind of strange that this API would be looking at an offest of -20.

so what you are seeing, is a call to 'IsThrdInKMode()' .
there is a space of thread local storage used by the kernel, just before the publicly accessible thread local storage. - look for SIZE_PRETLS, and PRETLS_RESERVED in the wince source.
this function ( well implemented as a macro actually ) is not a very strange function to call from a system call.
btw, you should have a look at IDA from datarescue. it will give you a much more readable disassembly. the stuff in your example from 00b650-b65c will be recognised as a constant pool, and the references to it, like at 00b5ec will be disassembled as 'LDR r6, =0xffffc800'

The only problem I have with IDA is that I can't afford it and their demo doesn't handle ARM processors. The generated output was done with a fairly simple program and has forced me to learn quite a bit about the underlying code in the OS. I've had to go back and forth between the disassembly and the shared source, but I've managed so far (with this exception).
I do have one other question while I have your attention. I've managed to inject a dll into all of the running processes and I've successfully managed to intercept several APIs by patching an application's IAT (and all attached modules, too) in an attempt to provide a better color handler for the system. It appears, however, that some programs, like Gwes.exe, don't use call my functions, but instead call the functions built into Coredll. For example, the GetSysColorBrush I mentioned earlier. This is what prompted me to begin reverse engineering Coredll in the first place. Do you know if the addresses are being stored somewhere? If so, that would explain why even though I've patched the IAT that the original function is still being called.

contact me in PM, I can help with IDA 4.51 full

gwes.exe is the program implementing the API, so quite likely it either calls it's api's directly, or calls the systemcalls directly.
and maybe someprograms are linked to a statically linked version of coredll?
a while back I experimented with trapping systemcalls, by modifying the method table in an API. ( see hookapi.cpp )
I do remember that my device became very unstable. so I guess that it somewhat worked, but haven't figured out what exactly I did wrong yet.
btw, I would be quite interested to see your code to trap calls via the IAT.

When you have a look to romimage.exe source code in platform builder you will notice that there is a special handling for coredll.dll.
All programs included in the MODULES section will directly resolve calls to coredll.dll. Only if you build a new XIP section a warning will appear "missing coredll.dll ... will late bind".
This means that a hook to coredll.dll will not be visible for in ROM programs since they will call the system functions directly (without the trap).
John

itsme said:
btw, I would be quite interested to see your code to trap calls via the IAT.
Click to expand...
Click to collapse
Unfortunately, I'm not at the computer where I have the code, so I'll have to upload it to you tomorrow. However, it involves extracting the IAT from the PPROCESS structure of a given program, then enumerating through the entries until I find the API I'm looking for. It's actually pretty straight forward. Give me your email address and I'll send it to you as soon as I can.
JohnSmith said:
When you have a look to romimage.exe source code in platform builder you will notice that there is a special handling for coredll.dll.
All programs included in the MODULES section will directly resolve calls to coredll.dll. Only if you build a new XIP section a warning will appear "missing coredll.dll ... will late bind".
This means that a hook to coredll.dll will not be visible for in ROM programs since they will call the system functions directly (without the trap).
Click to expand...
Click to collapse
I don't have the full source code, only what's available in the shared source, so I'm not sure what modules would be affected. However, I'm really only interested in a few of the Gwes APIs. I know it's possible at least at some point to hook into those as I've seen it done, though the individual who did it is under an NDA and can't tell me how he did it.
Itsme's process looks to be about the best so far, assuming I can get it to work. The only thing is that I need to find a way to translate the physical address to a virtual adress (and vice-versa) for MIPS, SH3 and the emulator, not just the ARM/XScale processors. If I could do that, then I might be able to get things to work.
Thanks for all of your help so far. I appreciate the time you have spent in explaining a few things to me.

[email protected]
for translating physical to virtual you would need to find the translation tables for each process, which I assume must exist somewhere, but have not found them yet. - my guess is it may be the 'pPTBL' entry from the process struct, but have not verified this yet.
( you know that virtual addresses can not uniquely be translated back to physical without knowing what process they are for? for instance the virtual address 0x11000 is visable in each process, and mapped to a different physical address each time. )

Fortunately, I've written an OS before, so I know what you mean about address mapping. If the pTBL does contain the page mappings, that would make sense. I found it easier in my OS to keep the TLB entries with the process they belonged to. That way the OS wouldn't have to search through its memory chain looking for the process's mappings.
Also, if the pTBL does contain the TLB entries, then it should be relatively easy to decode the addresses. After reading your code, itsme, I determined that the CINFO structure holds a pServer field which points to the process which contains the APIs. So, for example, the GDI and USER API sets are being held in Gwes.exe (at least, according to the pServer field). The ppfnMethods field is a VA referring to the pServer. If pServer is NULL, then the ppfnMethods field seems to be a PA. So, what I could do is check for pServer. If it is NULL, I could use the current process's pTBL structure to map the PA to a VA. If the pServer field is non-NULL, then I could try the pServer's pTBL field to do the mapping and then do the replacement that way.
If this works, I owe you big!

here is another experimental program, that investigates all the handles present in the system.
I used it to generate this overview of handles.

Progress So Far
I just thought I'd post an update on my progress so far. It appears that I can overwrite the API table pretty easily. Instead of taking a physical address, the table takes a pointer to a function in virtual memory. You just need to map it to slot 0 using MapPtrToProcess.
I've come across two issues in doing this. The first thing is that I can't call the original function address. For example, I store the original address contained in ppfMethods[x] and then attempt to typecast it to the proper function type, passing the incoming variables.
The other issue is that it appears that the API table is NOT refreshed upon a soft-reset. Fortunately, I was playing around with it on the emulator. Had I not, I would have been forced to hard-reset my device.
Does anyone have ideas on either of these issues?
Thanks again for your help so far!

a thing that just occurred to me, is that if you duplicate the apiset struct, the memory pointed to by ppfnMethods should be readable from the process specified in pServer.
so you should allocate the memory in the address space of pServer.
or set pServer to yourself, and add some hook code which does not modify the stack, so you can just pass most calls directly to the original server.
to call the original function address, you have to somehow switch process context, and then call it.

Well, in the case that I tested, I replaced the QueryAPISetID API which exists in Wn32 and therefore has no pServer. It appears that if there is no pServer, then there is no context switch needed. I've been able to verify that the API will execute my code and the generated assembly does not modify the stack in any way.
This one is really weird. Thanks for the suggestions.

chmckay said:
itsme said:
btw, I would be quite interested to see your code to trap calls via the IAT.
Click to expand...
Click to collapse
Unfortunately, I'm not at the computer where I have the code, so I'll have to upload it to you tomorrow. However, it involves extracting the IAT from the PPROCESS structure of a given program, then enumerating through the entries until I find the API I'm looking for. It's actually pretty straight forward. Give me your email address and I'll send it to you as soon as I can.
Click to expand...
Click to collapse
Hi,
Just wondring if you could post/PM/email me the code that lets you replace the API call. This is for the purpose of hooking a different DLL to do my own thing, or see here:
http://forum.xda-developers.com/viewtopic.php?p=131857#131857

I just sent you a PM with the information you requested.

converting ASCII to Unicode

hi ther i wonder if you could help me on this simple task. I'm creating a GPS application to run on the XDA2, i'm using eVC++ to do the implementation.
at the moment i'm reading the GPS signal via bluetooth over a virtual COM port, the signal coming from the GPS if a ASCII sinal and i'm duimping this into a char buffer.
However i need to convert this to UNICODE in order to display it on the Pocket PC, how's best to convert a buffer full of ASCII into Unicode so i may display it?
I tried using MultiByteToWideChar(), but it doesn't seem to work properly, maybe i haven't set it up correctly? Could someone point me in the right direction!
Below is an example of what i tried:
Code:
char buf[50]; // contains output from GPS
TCHAR Message[50]; //where i intended to put the message so i could display it
MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, buf, -1, Message, 0);
Thank in advance

I'm sure it's not the right way to go about it, but I generally wsprintf for short strings.
However, don't listen to me, I'm a mad man. Check this page out instead:
http://www.i18nguy.com/unicode/c-unicode.html
V

Thanks for that, out of curiosity, how would you use wsprintf to convert ASCII to unicode, i tried that before with no real success!

The last value passed to MultiByteToWideChar tells this function the size of the result buffer, Message in your case. You have passed zero, all that does is makes the function return the size of a TCHAR variable it needs to put the Ascii input buf into.
You need to put sizeof(Message) as the last parameter and not zero.
The other way (better way ?) of doing this is first you call the MultiByteToWideChar function with the zero parameter as you have and then you malloc the result * sizeof(TCHAR).

Thanks for the advise, after looking into the function more i realised this is where i was going wrong, and i have now managed to make the conversion. Thanks for pointing that out though!

How to know if connected to GPRS/EDGE or UMTS/HSDPA

Hi all,
Do you know a software which let met know what connection type I'm using between GPRS/EDGE and UMTS/HSDPA ?
The E icon tweak doesn't work on HTC TyTN... Thanks!

It has been posted on this forum that you do not need the tweak as the TyTN will show you the network that you are connected to. I would undo what you have done and check that you are really in UTMS coverage.
... or even try a search for other threads on this :roll:

Really?? So what should be displayed if I'm connected to HSDPA?

'U' I believe. Should say in the manual.

Ok, so this is my point.
I want to know if I'm connected to UMTS or HSDPA.
and the same beetween GPRS and EDGE.
I never saw a "E" on my screen ...

Right you are Taron.
I never saw "E" on my TyTN, though I'm sure I was under EDGE coverage.
I think TyTN just doesn't show clearly what precise kind of network you are connected too.
It just shows "G" if you are under GSM network data coverage (GPRS and EDGE).
It will show "U" if you are under 3G network (UMTS and HSDPA).

what a pity, but thank you for the confirmation
One more question http. Do you have the voicemail icon working fine on your TyTN?
I'm on SFR, and when I have a voicemail, there is no icon neither SMS (even if my voicemail is configured to send a notification)...
Thanks,

just so you know there is a registry hack to show the E instead of G when you are on the edge network. this works seamlessly. i dont know for sure but there is probably a similar registry hack for the same thing with the UMTS/HSDPA connections.

Thanks for the tips, but it was said that this hack doesn't work on TyTN

You can use HSDPA in France ?

Yes, SFR is claiming to provide HSDPA in some regions :
http://www.sfr.fr/info_nouveautes/3G/3Gplus/index.jsp

taron said:
Hi all,
Do you know a software which let met know what connection type I'm using between GPRS/EDGE and UMTS/HSDPA ?
The E icon tweak doesn't work on HTC TyTN... Thanks!
Click to expand...
Click to collapse
I have been trying the same,but in vain.
The reg tweak working for the previous models is not working on the Hermes.
Which brings me to the following question:
Previously with ADDING this new reg key the EDGE differentiation started after rebooting the device.
So some .dll obviously checked for this key, parsed and decoded it and invoked the function in the device.
Question:
How is a (secret) reg key added to the registry parsed ?
Will we find somewhere in a .dll the string "EnableDifferGprsEdgeIcon" (or in the case of the Hermes something else) in real text ?
Can we look for such a value this way ?
Come on all experts here!
I cannot believe that nobody can detail on this here!!!
(P.S. Whenever I try to analyze the ril.dll with a hex editor it just shows zeros. Why ?)

Actually it is not that simple.
First you need a proper ROM dump, with the files intact.
Then you have to know which DLL is responsible for the feature. I don't think it's RIL, it may be device.exe or whatever is showing the taskbar.
Then you need a good decompiler like IDA, which will find the strings.
Keep in mind that all strings on the device are in Unicode so when you look at a string with a hex editor you will see something like this:
65 00 66 00 67 00 68 00
for ABCD
With IDA though you get a special window showing you the list of strings.

there could be difference between what info different operators send to phones connected to their network
so this could explain why ppl expiernce different things connectionwise

help me understand this. i usually just intall 2 cabs on my 8125 after hard reset. one is the GPRS settings for media net and the Edge icon. now that cab only changes my GPRS to icon to E. prob is it dosnt change. now if i install all the extended cab files my connection is ONLY g. that must mean that there is another cab somewhere in there that enables the switch. idk someone help
this sucks. i cant even tell if i have Edge or not.

levenum said:
Actually it is not that simple.
First you need a proper ROM dump, with the files intact.
Then you have to know which DLL is responsible for the feature. I don't think it's RIL, it may be device.exe or whatever is showing the taskbar.
Then you need a good decompiler like IDA, which will find the strings.
Keep in mind that all strings on the device are in Unicode so when you look at a string with a hex editor you will see something like this:
65 00 66 00 67 00 68 00
for ABCD
With IDA though you get a special window showing you the list of strings.
Click to expand...
Click to collapse
Hi levenum,
you mean a dump of all files which can be seen in a file explorer (e.g. Resco) but cannot be read, as they are marked ROM or hidden or system, don't you ?
Well there seems to be a tool for extracting such files on buzzdev, called "WM5 Files Dumper".
Unfortunately it won't work with my TyTN as it tries to write the files on to a predefied directory on "Storage Card". Unfortunately in the German version the Storage Card location is called Speicherkarte.
I do not know if it is safe to change this temporarily to Storage Card without destroying all other links and no longer be able to access or start the programs installed on the storage card.
Maybe someone could fix that rather in the "WM5 Files Dumper" where the output directory is hard-coded.
What a painful restriction ! I can imagine that this utility would be valuable for many of us trying to find out more about their devices...
I know that most of the strings are encoded in Unicode.
The Cygnus HexEditor is able to look for Unicode strings, so this wouldn't be the problem.

levenum said:
Actually it is not that simple.
First you need a proper ROM dump, with the files intact.
Then you have to know which DLL is responsible for the feature. I don't think it's RIL, it may be device.exe or whatever is showing the taskbar.
Then you need a good decompiler like IDA, which will find the strings.
Keep in mind that all strings on the device are in Unicode so when you look at a string with a hex editor you will see something like this:
65 00 66 00 67 00 68 00
for ABCD
With IDA though you get a special window showing you the list of strings.
Click to expand...
Click to collapse
Hi levenum,
you mean a dump of all files which can be seen in a file explorer (e.g. Resco) but cannot be read, as they are marked ROM or hidden or system, don't you ?
Well there seems to be a tool for extracting such files on buzzdev, called "WM5 Files Dumper".
Unfortunately it won't work with my TyTN as it tries to write the files on to a predefied directory on "Storage Card". Unfortunately in the German version the Storage Card location is called Speicherkarte.
I do not know if it is safe to change this temporarily to Storage Card without destroying all other links and no longer be able to access or start the programs installed on the storage card.
Maybe someone could fix that rather in the "WM5 Files Dumper" where the output directory is hard-coded.
What a painful restriction ! I can imagine that this utility would be valuable for many of us trying to find out more about their devices...
I know that most of the strings are encoded in Unicode.
The Cygnus HexEditor is able to look for Unicode strings, so this wouldn't be the problem.

well for t-mobile at least, when your on 3g you are on HSDPA, where ever there is UMTS signal there is HSDPA signal (i asked the question to t-mob cs)

accelerometer(Incite) method signatures

I am trying to create a managed wrapper(.net) for the CT810(incite) accelerometer, just hit the wall--
I have dumped my ROM, and extracted the accelsensor.dll
but am unable to extract any signatures
I though I get lucky and just be able to tlbimp it, no such luck
next tried dumpbin /EXPORTS accelsensor.dll
Dump of file accelsensor.dll
File Type: DLL
Section contains the following exports for ACCELSENSOR.dll
00000000 characteristics
2C05A62B time date stamp Thu May 27 22:42:03 1993
0.00 version
1 ordinal base
11 number of functions
11 number of names
ordinal hint RVA name
1 0 000015E0 ACC_Close
2 1 0000141C ACC_Deinit
3 2 000021CC ACC_IOControl
4 3 00001F40 ACC_Init
5 4 000015DC ACC_Open
6 5 00001520 ACC_PowerDown
7 6 00001574 ACC_PowerUp
8 7 000015E8 ACC_Read
9 8 00001618 ACC_Seek
10 9 00001600 ACC_Write
11 A 00001620 DllEntry
Summary
1000 .CRT
1000 .data
1000 .pdata
1000 .reloc
4000 .text
But this does not show any vector data I could subscribe to
Does PEBrowse work with ARM?
Any advice on what to do next?
Regards
_Eric

could you please post the dll for others to work with?in no dev but have been looking forapps that will work with the incite accelerometer but most are made for HTC. you have a step up on most you the fist ive seen in past 4mo of looking who even trying hopefullu little team work with some guys who developed few apps that work with htc g sensor.if you could repost this with included dll. thanks

I now own a LG GM750 (WM6.5) and it also uses the accelsensor.dll.
Some MS applications like IE6 and picture viewer use it when turning the phone but all the nice HTC apps are not working.
There is HTCEmu for Samsung which probably could be adapted for LG.
Anybody trying to do this ?

Hmm.. since this old thread was bumped, I just wanted to link this for reference if it's helpful:
http://www.lg-incite.com/index.php?topic=2791.0
dll & mbn are at 3rd post

Hi
first sry 4 my englisch im german.
Im very interested to get the motion/g-sensor to work with htc apps. I got my lg last week and have the same problem that no apps work on it exepting ie and some windows apps.
If i can help to post some detail or if somehone has a conclusion how to use plz help.
i testet the samsung emu but it do not work also.
THX much

attached the.dll of the lg gm750 in case they serve of something

solution for LG GM750
First take a look at the Unified Sensor Api at codeplex.
My solution is based on the Samsung sensor class, modified to meet the peculiarities of the LG GM750.
First of all, the import of the DeviceIoControl in NativeMethods.cs must be modified such way dwIoControlCode is type uint, and the buffers are byte:
Code:
[DllImport("coredll", CharSet = CharSet.Auto, SetLastError = true)]
public static extern bool DeviceIoControl(IntPtr hDevice, uint dwIoControlCode, [In] byte[] inBuffer, int nInBufferSize, [Out] byte[] outBuffer, int nOutBufferSize, ref int pBytesReturned, IntPtr lpOverlapped);
After a long time dissassembling the accelsensor.dll and and a lot of trial and error testing I came to this conclusion that works:
The constant that starts/stops data output becomes:
Code:
const uint ACCOnRot = 0x1014EE8;
const uint ACCOffRot = 0x1014EE8;
and for reading values:
Code:
const uint ACCReadValues = 0x1014F10;
The difference between start and stop comes from the input given in DeviceIoControl method as follows:
Code:
public static LGAccSensor Create()
{
DeviceIoControl(ACCOnRot, new byte[1] {1}, new byte[4] );
return new LGAccSensor();
}
protected override void Dispose(bool disposing)
{
base.Dispose(disposing);
DeviceIoControl(ACCOffRot, new byte[1] {0}, new byte[1] );
}
The DeviceIoControl inside the accelerometer class becomes
Code:
public static void DeviceIoControl(uint controlCode, byte[] inBuffer, byte[] outBuffer)
{
IntPtr file = NativeMethods.CreateFile("ACC1:", 0, 0, IntPtr.Zero, ECreationDisposition.OpenExisting, 0, IntPtr.Zero);
if (file == (IntPtr)(-1))
throw new InvalidOperationException("Unable to Create File");
try
{
int bytesReturned = 0;
int inSize = sizeof(byte) * inBuffer.Length;
int outSize = sizeof(byte) * outBuffer.Length;
if (!NativeMethods.DeviceIoControl(file, controlCode, inBuffer, inSize, outBuffer, outSize, ref bytesReturned, IntPtr.Zero))
throw new InvalidOperationException("Unable to perform operation.");
}
finally
{
NativeMethods.CloseHandle(file);
}
}
Note that the accelerometer device is called ACC1:.
Further the method that returns the three component vector becomes
Code:
public override GVector GetGVector()
{
byte[] outBuffer = new byte[4];
DeviceIoControl(ACCReadValues, new byte[1] {1}, outBuffer);
GVector ret = new GVector();
int accx = outBuffer[2];
if (accx <=31)
ret.X = accx/2.17;
else
ret.X = (accx-64)*0.47;
ret.X = -ret.X;
int accy = outBuffer[1] ;
if (accy <=31)
ret.Y = accy/2.17;
else
ret.Y = (accy - 64) * 0.47;
int accz = outBuffer[0] ;
if (accz <=31)
ret.Z = accz/2.17;
else
ret.Z = (accz - 64) * 0.47;
double somefactor = 1; return ret.Scale(somefactor);
}
Note that the when called with AccReadValues parameter, the DeviceIoControl returns three bytes each of them containing a signed 6 bit 2's complement value.Basicly there are values on 6 bit ranging from -32 to +31. In the docs below there are tables that put in correspondence these values with acceleration in range -1.5g +1.5g which are the limits of the device. The code I wrote returns acceleration in meters/second2 where 1g=9.8 m/s2. That information I extracted from the technical specifications of the MMA7660FC accelerometer, as found at(try a google search). Also, the type of the accelerometer circuit is found in the service manual (I only found the service manual for LG GM730 which is pretty close).The same thing I also posted at codeplex.

All that means that you are in a good way to make the gm750 sensor act like samsung' s, even htc's, sensor???
Oh, iamspv, please make it work, I begging you!

jowl_tnt said:
All that means that you are in a good way to make the gm750 sensor act like samsung' s, even htc's, sensor???
Oh, iamspv, please make it work, I begging you!
Click to expand...
Click to collapse
It already works! There is nothing more to do about it than use the code in your applications (I speak as a programmer and for programmers). I only showed everyone interested in developing for LG GM750 the steps to modify the SamsungGSensor class from "Unified Sensor Api" at codeplex to work with a LG. Just get the rest of the code from there and put it toghether.
Now there are two directions:
Direction #1
If you want to develop applications that aim to be portable between HTC, Samsung, LG, Toshiba, etc, and you want to use Unified Sensor Api then..
the person responsible for the unified api project at codeplex should make the update to the library as soon as possible such way the library should keep compatibility with the adressed devices. I'm just contributing with some results. That's because the initial code was not very general (ie. the initial parameter types to deviceiocontrol invoked from coredll didn't work with this solution) I had to make some modifications to the code that work with the LG but affect other devices' sensor classes. Now, if the update doesn't come up soon, no problem, anyone just gets the code from codeplex, adds a new class for LG, copies code from Samsung, renames Samsung with LG, adds my modifications, corrects syntax errors, compiles, et voila . . the library is updated to support LG GM750.
Direction #2
If you develop only for LG, just write a LG class as presented above and don't care about other devices.
If you don't know how to use your new class, the project at codeplex has some examples and you'll easily see inside the code how to instantiate sensors, how to read data at certain moments using a timer, and how to capture screen rotation events.
And for your long awaited joy to see it working, I attached the sensor test program along with a version of sensors.dll compiled by me, that works for GM750.
Now get your fingers toghether on the keyboard and start developing for LG

Thanks a lot for this! I can now play sensory-overload on the LG750
I downloaded the game and replaced the sensor.dll with your version.
Now I'll need to find out how to use this with SPB Mobile Shell...

Thanks for your help but I'm not a programmer and I don't understand much of these.
I think the solution is to make a modified HTCSensorSDK.dll for gm750. Then all gsensor apps for htc will work on our lg. Is that right;

That is what so many users have been waiting for.
It works for LG GM735 as well.
much appreciated !. Well done!.

roolku said:
Thanks a lot for this! I can now play sensory-overload on the LG750
I downloaded the game and replaced the sensor.dll with your version.
Now I'll need to find out how to use this with SPB Mobile Shell...
Click to expand...
Click to collapse
roolku, please confirm that when playing sensory-overload the Y axis is reversed. It is an issue of the Sensor API I encountered while testing.
The theory says,
"The positive X axis is from the center of the screen to the right.
The positive Y axis is from the center of the screen to the top.
The positive Z axis is from the front of the screen towards the viewer."
but this isn't the case in sensor api.
I respected this theory when I returned the acceleration values, as you can see in my sensor test program. But also you will see the api considers Portrait as Reverse Portrait.
Developers should be aware of these issues and make the appropiate changes to the library when writing code.

iamspv said:
roolku, please confirm that when playing sensory-overload the Y axis is reversed. It is an issue of the Sensor API I encountered while testing.
Click to expand...
Click to collapse
Yes, you are right. I couldn't quite put my finger on what was strange when playing it.
iamspv said:
I respected this theory when I returned the acceleration values, as you can see in my sensor test program. But also you will see the api considers Portrait as Reverse Portrait.
Developers should be aware of these issues and make the appropiate changes to the library when writing code.
Click to expand...
Click to collapse
Hm, I wonder if it is more sensible to conform to the established convention rather than expect everybody else to change their ways. Unless I misunderstood you?
Would you mind supplying a version of sensor.dll that is compatible with the Samsung one (i.e. reversed y-axis)?

thank you, clublgmobile you thanks, expect that works with all applications

I don't understand how that works. How can i play RescoBubbles for example;

this is excellent news. now if we could just get the GW820 (expo,IQ) accelsensor.dll dissasembled we'd be cookin with gas

killerskincanoe said:
this is excellent news. now if we could just get the GW820 (expo,IQ) accelsensor.dll dissasembled we'd be cookin with gas
Click to expand...
Click to collapse
Yes, it would be very much appreciated! Ive been looking for a htc wrapper for our sensor since i got the phone.
I attached the accelsensor.dll from the eXpo in case that will help at all. I wish i had the knowledge to do more myself..
edit:
Also, theres a game that comes stock on At&t's model gw820 called Ferrari GT Evolution that uses the gsensor. Its made by gameloft so maybe its not as hard to get to as the incites?

to roolku:
Here is a modified version of sensors.dll with reversed Y axis that will a allow you to normally play sensory overload on your GM750. Using the GSensorTest you will see Portrait is now detected correctly.
Also, this version of sensors.dll works on HTC and Samsung as the original one , I managed to separate code. See the attachement.
to theyllib
I dissassembled the gw820 accelsensor.dll you provided. Looks like the interesting part is here
this is some data
Code:
.text:100027CC dword_100027CC DCD 0x32100C ; DATA XREF: ACC_IOControl+25Cr
.text:100027D0 dword_100027D0 DCD 0x321008 ; DATA XREF: ACC_IOControl+250r
.text:100027D4 dword_100027D4 DCD 0x321004 ; DATA XREF: ACC_IOControl:loc_1000263Cr
.text:100027D8 off_100027D8 DCD unk_10005650 ; DATA XREF: ACC_IOControl+8Cr
.text:100027D8 ; ACC_IOControl+138r ...
.text:100027DC dword_100027DC DCD 0x22200C ; DATA XREF: ACC_IOControl+80r
.text:100027E0 dword_100027E0 DCD 0x222008 ; DATA XREF: ACC_IOControl+74r
.text:100027E4 dword_100027E4 DCD 0x222004 ; DATA XREF: ACC_IOControl+68r
.text:100027E8 dword_100027E8 DCD 0x222010 ; DATA XREF: ACC_IOControl+48r
.text:100027EC off_100027EC DCD aAcc_iocontrol0 ; DATA XREF: ACC_IOControl+30r
.text:100027EC ; "ACC_IOControl(%08x)"
and this is where they are adressed
Code:
.text:10002440 LDR R3, =0x222010
.text:10002444 CMP R6, R3
.text:10002448 BHI loc_100025D4
.text:1000244C BEQ loc_10002588
.text:10002450 MOV R3, 0x222000
.text:10002458 CMP R6, R3
.text:1000245C BEQ loc_100025C0
.text:10002460 LDR R3, =0x222004
.text:10002464 CMP R6, R3
.text:10002468 BEQ loc_10002540
.text:1000246C LDR R3, =0x222008
.text:10002470 CMP R6, R3
.text:10002474 BEQ loc_10002518
.text:10002478 LDR R3, =0x22200C
.text:1000247C CMP R6, R3
.text:10002480 BNE loc_10002660
.text:10002484 LDR R3, =unk_10005650
.text:10002488 LDR R3, [R3]
.text:1000248C CMP R3, #1
.text:10002490 MOVNE R3, #0
The codes that must be sent to DeviceIoControl in coredll.dll are probably the 0x22200C, 0x222008 and stuff. The 0x321008 and stuff are some power get/set codes. But you need a programmer with an actual gw820 device to make it work as it need lots of testing. Hope this information helps and someone with such device will make it work.

Can anyone check if the Incite comes with ACCAPI.DLL, and if so can it be posted ?

[Q] How to Modify BattDrvr.dll (So as to remove FlashLightPowerUnavailable)??

I have been searching for quite a while (~2 weeks) & have not been able to find anything that helps me do what I want. I have been working on a modified HD2 ROM for my TMOUS HD2 {based on 2.13 ROM}. I have made many changes & have been able to apply most all the mods that interest me the most. There are many references to my problem; but no permanent fixes, & I am tired of the the tempory fix.
The tweak that has eluded me is the "FlashPowerUnavailable" registry entry. I have traced everything within the ROM & could not find the registry setup for this feature. After an extensive search thru all the .DLLs, I was finally able to find the settings. They are located in Battdrvr.dll. From what I understand; the .DLL reads the battery level & automatically inserts a registry key that disables the camera's flash whenever the battery level reaches 20% or less. Even if you delete the registry entry, the .DLL will reinsert it as soon as the battery goes below 20%. Personally I am tired of having to edit the registry everytime I want to take a pic when the battery level is low. The flash adds no real power drain & therefore the "FlashLightPowerUnavailable" is a BS setting that is completely unneeded.
So, here is my question to the community. Is there anyone that can rewrite the HD2's Battdrvr.dll so as to remove any reference to the "FlashLightPowerUnavailable" registry? If it's not possible to remove it completely; is there a way to change the trigger from 20% to 1%?
With the exception of changing graphics & text; I will not even pretend to know what I am doing when it comes to modifying a .DLL file. As such, I have not even attempted to modify this .dll. I have PEexplorer, Restorator, & ResHack on my machine, but I only use them for editing graphics & icons {& occasionally text}. If someone could modify the .dll, I would be extremely grateful. Of course; I'm sure that I am not the only one that would like to have this mod done. Of course; I am also willing to try & learn if someone would want to walk me thru modifying a .dll file.
I have attached BattDrvr.dll in the below .7z file. The zipped folder contains the original module {pulled from 2.13.531.1}, as well as the actual .dll itself. Any help is greatly appreciated.
Thanx:
Hippie

I'm not too familiar with Battery drivers but if you could find a way to have it be associated with Power Saving Mode you could just have power saver kick in at %1..?
But like I said I have no idea how it works..

Sorry for the delayed responce.
BattDrvr adds a registry entry when the battery reaches 20%. It is also readded to the registry upon every reboot. One would need to create an event to monitor the status of the reg entry, & delete/change it when it is activated. Personally; I am not real familiar with the event system & have not dealt with it too much {except to deactivate events thru DotFreds task mngr}.
Would creating an event utilize any system resources? I am trying to do this without adding another footprint to the system {no matter how small}. I know that modding the .Dll will accomplish what I want without creating any new footprints. This is why I posted this question to the community to begin with.
Personally I can't believe that this hasn't been done already. I also can't believe that there seems to be no interest in this whatsoever. I can't be the only one that uses the flash after the battery is below 20%.

I didn't test it, don't have device
What i did was:
Open hex editor, Search for "00 53 E3 35 00 00 9A 1C 37 91 E5 02 00 53 E3" the number before that found should be "14" (which is "20" in decimal) change to "01" (which is "1" in decimal).
I used IDA and HxD
The modded file is in attachment

Vico100 said:
I didn't test it, don't have device
What i did was:
Open hex editor, Search for "00 53 E3 35 00 00 9A 1C 37 91 E5 02 00 53 E3" the number before that found should be "14" (which is "20" in decimal) change to "01" (which is "1" in decimal).
I used IDA and HxD
The modded file is in attachment
Click to expand...
Click to collapse
Little Off topic .. but you seem to know howto hex edit stuff
Been woundering why no one has hexed skyfire so it doesnt check for the skyfire server .. and just goes to google or so other website ..
I was able to get SkyFire working today kinda .. by "tricking" it and made it goto google .. after that .. I was able to surf NP ..
Just a thought

hmmm..i don't know about android...never tried.

Vico100 said:
hmmm..i don't know about android...never tried.
Click to expand...
Click to collapse
No No .. Skyfire is also for WM

Vico100 said:
I didn't test it, don't have device
What i did was:
Open hex editor, Search for "00 53 E3 35 00 00 9A 1C 37 91 E5 02 00 53 E3" the number before that found should be "14" (which is "20" in decimal) change to "01" (which is "1" in decimal).
I used IDA and HxD
The modded file is in attachment
Click to expand...
Click to collapse
Glad I found this. Will try it out when TMOUS sends me my two free HD2s. Thanks. If anyone can report back as to weather it works or not, please do. Might take me a while since mine are on backorder.