Develop Bugs

Hook API function WM6

I'm trying to hook api function "NKDbgPrintfW" from coredll.dll.
I use import table in-memory patch. It works fine for main module (exe file).
It hooks all calls from exe, but does not from dll it uses.
I think root of problem is that exe and loaded dlls use own import table and I patch only exe's one.
I use next function to hook exe api calls:
Code:
DWORD ic_PatchProcImports ( HANDLE hProc, DWORD dFind, DWORD dReplace )
{
DWORD ret = 0;
/* GODMODE ON */
BOOL bOldKMode = SetKMode ( TRUE );
DWORD dOldPerms = SetProcPermissions ( 0xFFFFFFFF );
/* get process ptr prom handle */
HDATA * hProcHD = ( HDATA * ) ( 0x80000000 | ( ( DWORD ) hProc & HANDLE_ADDRESS_MASK ) );
PROCESS * prc = ( PROCESS * ) hProcHD->pvObj;
/* get imports sections */
struct ImpHdr * blockptr, * blockstart;
blockstart = ( struct ImpHdr * ) MapPtrProc ( prc->e32.e32_vbase + prc->e32.e32_unit[IMP].rva, prc );
/* iterate thru imports sections */
for ( blockptr = blockstart; blockptr->imp_lookup; ++blockptr )
{
DWORD dOldProtect, tmp;
/* get vectors ptr */
DWORD * vectors = ( DWORD * ) MapPtrProc ( prc->e32.e32_vbase + blockptr->imp_address, prc );
/* count vectors */
DWORD * vptr = vectors;
while ( * vptr ) ++vptr;
DWORD vcnt = ( vptr - vectors );
/* try to unlock imports section memory */
if ( VirtualProtect ( vectors, vcnt * sizeof ( DWORD ), PAGE_EXECUTE_READWRITE, &dOldProtect ) )
{
/* find&replace */
for ( UINT i = 0; i < vcnt; ++i )
{
if ( vectors[i] == dFind )
{
vectors[i] = dReplace;
++ret;
}
}
/* lock back */
VirtualProtect ( vectors, vcnt * sizeof ( DWORD ), dOldProtect, &tmp );
}
}
/* GODMODE OFF */
SetProcPermissions ( dOldPerms );
SetKMode ( bOldKMode );
/* */
return ret;
}
I tried to find import table in loaded dll module but failed.
Here is the code I used:
Code:
DWORD ic_PatchModuleImports ( HANDLE hProc, Module* mod, DWORD dFind, DWORD dReplace )
{
DWORD ret = 0;
/* GODMODE ON */
BOOL bOldKMode = SetKMode ( TRUE );
DWORD dOldPerms = SetProcPermissions ( 0xFFFFFFFF );
/* get process ptr prom handle */
HDATA * hProcHD = ( HDATA * ) ( 0x80000000 | ( ( DWORD ) hProc & HANDLE_ADDRESS_MASK ) );
PROCESS * prc = ( PROCESS * ) hProcHD->pvObj;
/* get imports sections */
ImpHdr *blockptr, *blockstart;
blockstart = ( ImpHdr * ) MapPtrProc(mod->e32.e32_vbase + mod->e32.e32_unit[IMP].rva, prc);
/* iterate thru imports sections */
for ( blockptr = blockstart; blockptr->imp_lookup; ++blockptr )
{
// NKDbgPrintfW(L"%s", blockptr->imp_dllname);
//DWORD dOldProtect, tmp;
/* get vectors ptr */
DWORD * vectors = ( DWORD * ) MapPtrProc(mod->e32.e32_vbase + blockptr->imp_address, prc);
/* count vectors */
DWORD * vptr = vectors;
while ( * vptr ) ++vptr;
DWORD vcnt = ( vptr - vectors );
/* try to unlock imports section memory */
//if ( VirtualProtect ( vectors, vcnt * sizeof ( DWORD ), PAGE_EXECUTE_READWRITE, &dOldProtect ) )
{
/* find&replace */
for ( UINT i = 0; i < vcnt; ++i )
{
NKDbgPrintfW(L"Serach for: %x; Found: %x", dFind, vectors[i]);
if ( vectors[i] == dFind )
{
vectors[i] = dReplace;
++ret;
}
}
/* lock back */
// VirtualProtect ( vectors, vcnt * sizeof ( DWORD ), dOldProtect, &tmp );
}
}
/* GODMODE OFF */
SetProcPermissions ( dOldPerms );
SetKMode ( bOldKMode );
/* */
return ret;
}
I'm looking for any way to hook this function, but I prefer in-memory import table patch..

Hello!
Perhaps this will help:
http://forum.xda-developers.com/showthread.php?t=372496
I am also working on a program that needs hooks. My problem right now is that I need to create the header with all the structure definitions (PROCESS, THREAD, ect). I found this but it is most likely for an older CE version as it was written in 2003:
http://nah6.com/~itsme/cvs-xdadevtools/itsutils/old/cenk.h
Do you have these definitions for wince 5.x?

I think, you can find it in Windows Mobile Platform SDK .
MS sells that SDK, but if you google it, you'll find a place where you can download it for free

I was working on a similar problem but I decided to make a generic hook that didn't rely only on import table. Thanks to itutils I was able to hook some functions until when I found out that there two methods for making api calls, the standard one and the "speedy" one. I wasn't able to hook any function that was using the second method and after a bit I gave up. How did you overcome this problem?
Any suggestion is welcome, thank you

I still have not solved my problem. I am trying to hook calls to keybd_event in coredll from keypad.dll. I think the root of the problem is that that keypad.dll is in ROM. Therefore the thunk table that is actually inside keypad.dll is not readable or writeable at runtime. I think there is a thunk table created in RAM somewhere else where the function pointers are actually stored. I can find it by analyzing keypad.dll and finding the hex location to where the runtime thunk table is, but I cant find a way to figure it out at runtime so that my hook will work with any dll.

I use the PerformCallback4 DLL hooking and it's working with ROM files. But I'd also be interested if there's a way to inject into a process without needing to load a separate DLL.

Well process injection is not my problem. I am trying to hook calls from a service dll. All I did was add my dll as a service and I am kindly loaded at boot. Its the hooking I cant get to work. How are you accomplishing the hook? I just want to hook all calls from other services to keybd_event.

What _exactly_ do you guys want to do? I may be able to assist.
I know the answers to most questions I see here, but I will simply not give out the code to do this, because it is "dangerous" code. By that I do not mean it is not somewhat reliable, but dangerous to commercial developers as these techniques allow you to crack pretty any commercial app with minimal effort...
(see my notice about having easily bypassed the MS Marketplace "advanced protection" on various news sites for an example of how bad this can be)

Actually I'd be curious to know how to hook an API that can use the kmode speedup, that is one that's using g_pKmodeEntries. I'm not interesting into cracking anything but at this point I'm curious to know how to go ahead.
Thanx for any help.

I heard that the DLL injection hooks won't work for WinCE 6.0 (--> WM 7) but what about the mentioned "kmode speedup"?

bbbird1 said:
Actually I'd be curious to know how to hook an API that can use the kmode speedup, that is one that's using g_pKmodeEntries. I'm not interesting into cracking anything but at this point I'm curious to know how to go ahead.
Thanx for any help.
Click to expand...
Click to collapse
Well there are various ways to patch functions out. The problem is that there are several ways that a kernel function can ultimately be called. Of course there are also various ways to go about patching these functions. To name a few:
(1) Patch the apiset tables and overwrite the function address the trap jumps to. If this is the same table and address are used for the g_pKmodeEntries jump I am not sure - you would have to do some IDA'ing / testing to figure that one out
(2) Patch the import tables of the executable / dll calling this function, if you have a specific target in mind (with some small trickery this can be adapted to also patch 'dynamic imports', i.e. GetProcAddress, even after the call was made)
(3) Patch the export table of coredll (actually if this one matches your wishes, I usually use 4 instead)
(4) Patch the function inside coredll directly by (saving first and then) overwriting the first few instructions with a jump to your code
(5) Patch the actual function inside nk or the other exe server (closely related to 4)
Each method has it's own pros and cons, injection/controlled-leak/code requirements and may or may not work with certain way of calling the function. Some of these patches are much more difficult to do than others...
You'd have to figure out for your function which method might actually work. For example I usually have great results with method 4, however it will not catch some ways of kernel-internal calls, so you have to confirm first with some heavy IDA'ing to see if internal calls exist (completely bypassing coredll, for most functions they actually don't). Unfortunately that I recall I have not tried patching any g_pKmodeEntries intentionally (as in I might have patched such functions, but not knowingly).
RAMMANN said:
I heard that the DLL injection hooks won't work for WinCE 6.0 (--> WM 7) but what about the mentioned "kmode speedup"?
Click to expand...
Click to collapse
Well we'd pretty much have to start from scratch again, figuring a lot of stuff out, but I'm sure we'll find new and exciting ways of hooking kmode speedup might still be there, though, but likely in a different form.

Chainfire said:
What _exactly_ do you guys want to do? I may be able to assist.
I know the answers to most questions I see here, but I will simply not give out the code to do this, because it is "dangerous" code. By that I do not mean it is not somewhat reliable, but dangerous to commercial developers as these techniques allow you to crack pretty any commercial app with minimal effort...
(see my notice about having easily bypassed the MS Marketplace "advanced protection" on various news sites for an example of how bad this can be)
Click to expand...
Click to collapse
Hello chainfire! I am trying to hook keyboard events comming from the keypad driver. There is a service that runs to detect key interrupts and when it does detect them it calls keybd_event to broadcast the event. keybd_event is in coredll. The keypad service is loaded from keypad.dll (in most ROMs). So I want to hook calls from keypad.dll to keybd_event in coredll. The problem is that I want it to work regardless of ROM version and there are different versions of keypad.dll, and some ROMs dont have it at all. Therefore I want to hook all calls to keybd_event from services. I added my dll as a service so injection method is not a problem. Now I need to hook.
Using IDA I found the address of the IAT in keypad, but the IAT that exists in the dll itself is not readable or writeable. It seems that there is a thunk table that gets created in RAM separate from where the dll is loaded. Each process seems to create it's own RAM thunk table for loaded dlls (my guess is just those in ROM). I dont know how to programmatically find these thunk tables.
Do I make sense? This is of course targeting WM6.x (wce5). I just need some way to hook calls to keybd_event from all dlls loaded in the current process. Some of those dlls may be in ROM but they need to be hooked too.

Chainfire said:
Well there are various ways to patch functions out. The problem is that there are several ways that a kernel function can ultimately be called. Of course there are also various ways to go about patching these functions. To name a few:
(1) Patch the apiset tables and overwrite the function address the trap jumps to. If this is the same table and address are used for the g_pKmodeEntries jump I am not sure - you would have to do some IDA'ing / testing to figure that one out
(2) Patch the import tables of the executable / dll calling this function, if you have a specific target in mind (with some small trickery this can be adapted to also patch 'dynamic imports', i.e. GetProcAddress, even after the call was made)
(3) Patch the export table of coredll (actually if this one matches your wishes, I usually use 4 instead)
(4) Patch the function inside coredll directly by (saving first and then) overwriting the first few instructions with a jump to your code
(5) Patch the actual function inside nk or the other exe server (closely related to 4)
Each method has it's own pros and cons, injection/controlled-leak/code requirements and may or may not work with certain way of calling the function. Some of these patches are much more difficult to do than others...
You'd have to figure out for your function which method might actually work. For example I usually have great results with method 4, however it will not catch some ways of kernel-internal calls, so you have to confirm first with some heavy IDA'ing to see if internal calls exist (completely bypassing coredll, for most functions they actually don't). Unfortunately that I recall I have not tried patching any g_pKmodeEntries intentionally (as in I might have patched such functions, but not knowingly).
Well we'd pretty much have to start from scratch again, figuring a lot of stuff out, but I'm sure we'll find new and exciting ways of hooking kmode speedup might still be there, though, but likely in a different form.
Click to expand...
Click to collapse
I like the sound of (3). Why Use (4) instead? How do you find the export table programmatically? If I use this method, as long as my service is loaded first it should work.

Ok I just tried something and it worked. It seems that these RAM thunk tables are always loaded at 0x01bb5000 for every process. The following code worked:
Code:
coremod = GetModuleHandle(L"coredll.dll");
o_keybd_event = (_keybd_event)GetProcAddress(coremod, L"keybd_event");
my_kbe = (DWORD)(my_keybd_event);
addr = (DWORD*)(0x01bb5000);
VirtualProtect(addr, 4, PAGE_READWRITE, NULL);
while(ReadProcessMemory(GetCurrentProcess(), addr, &dat, 4, NULL))
{
if(dat == (DWORD)o_keybd_event)
{
WriteProcessMemory(GetCurrentProcess(), addr, &my_kbe, 4, NULL);
kbe_hkd = TRUE;
}
addr++;
VirtualProtect(addr, 4, PAGE_READWRITE, NULL);
}
The thunk tables seem to be back to back and ReadProcessMemory seems to always fail at the end of them, so the loop does not run too long. Chainfire, does this make sense to you?

JKingDev said:
...
Do I make sense? This is of course targeting WM6.x (wce5). I just need some way to hook calls to keybd_event from all dlls loaded in the current process. Some of those dlls may be in ROM but they need to be hooked too.
Click to expand...
Click to collapse
Using IAT patch to do this is certainly possible but a lengthy process as you'd have to keep track for all dll loads in services.exe and patch each and every dll as it loads. One of the other methods I described may fit better.
JKingDev said:
I like the sound of (3). Why Use (4) instead? How do you find the export table programmatically? If I use this method, as long as my service is loaded first it should work.
Click to expand...
Click to collapse
(3) is actually (IMHO) a very annoying patch to implement. It doesn't easily allow you to patch/unpatch at will. It doesn't cover coredll-internal jumps. The timing/load-order has to be perfect. It requires slightly more memory. And because you have to load it before anything else if you screw something up there's a good chance you'll need a hard-reset to recover (that's a real ***** with testing!). You can get the export table from the e32 structure of the module, though it isn't always easily patched
JKingDev said:
Ok I just tried something and it worked. It seems that these RAM thunk tables are always loaded at 0x01bb5000 for every process. The following code worked:
The thunk tables seem to be back to back and ReadProcessMemory seems to always fail at the end of them, so the loop does not run too long. Chainfire, does this make sense to you?
Click to expand...
Click to collapse
ROM DLLs create a seperate data section in memory for every process it is loaded into, the IAT is also stored there. Note that the addresses / virtual memory are the same across processes, but different physical memory is used for each process (same as data sections for normal DLLs, though those are located at the normal addresses). To figure out where this memory is look at the rwLow and rwHigh members of the PMODULE structure. (actually I'm surprised you found the location without this )

Chainfire said:
ROM DLLs create a seperate data section in memory for every process it is loaded into, the IAT is also stored there. Note that the addresses / virtual memory are the same across processes, but different physical memory is used for each process (same as data sections for normal DLLs, though those are located at the normal addresses). To figure out where this memory is look at the rwLow and rwHigh members of the PMODULE structure. (actually I'm surprised you found the location without this )
Click to expand...
Click to collapse
That is the vital info I needed! Quick question, do I start searching at rwLow and end at rwHigh, or start at rw Low and end at rwLow+rwHigh?
Thanks!
*edit* Answering my own question, start searching at rwLow and end at rwHigh. I was still having problems because my MODULE structure definition is incorrect, but I was able to find where the information I needed was so it doesnt really matter. Thanks so much!!

HTC Kernel I2C

Hi, right been looking at the Hero CDMA Kernel trying to get direct access to the light sensor.
I know its part of I2C, and have found some documentation, but its completely over my head! Anyone smarter than me know what this means/how to use it?
Thanks
Usually, i2c devices are controlled by a kernel driver. But it is also
possible to access all devices on an adapter from userspace, through
the /dev interface. You need to load module i2c-dev for this.
Each registered i2c adapter gets a number, counting from 0. You can
examine /sys/class/i2c-dev/ to see what number corresponds to which adapter.
I2C device files are character device files with major device number 89
and a minor device number corresponding to the number assigned as
explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
i2c-10, ...). All 256 minor device numbers are reserved for i2c.
C example
=========
So let's say you want to access an i2c adapter from a C program. The
first thing to do is "#include <linux/i2c-dev.h>". Please note that
there are two files named "i2c-dev.h" out there, one is distributed
with the Linux kernel and is meant to be included from kernel
driver code, the other one is distributed with lm_sensors and is
meant to be included from user-space programs. You obviously want
the second one here.
Now, you have to decide which adapter you want to access. You should
inspect /sys/class/i2c-dev/ to decide this. Adapter numbers are assigned
somewhat dynamically, so you can not even assume /dev/i2c-0 is the
first adapter.
Next thing, open the device file, as follows:
int file;
int adapter_nr = 2; /* probably dynamically determined */
char filename[20];
sprintf(filename,"/dev/i2c-%d",adapter_nr);
if ((file = open(filename,O_RDWR)) < 0) {
/* ERROR HANDLING; you can check errno to see what went wrong */
exit(1);
}
When you have opened the device, you must specify with what device
address you want to communicate:
int addr = 0x40; /* The I2C address */
if (ioctl(file,I2C_SLAVE,addr) < 0) {
/* ERROR HANDLING; you can check errno to see what went wrong */
exit(1);
}
Well, you are all set up now. You can now use SMBus commands or plain
I2C to communicate with your device. SMBus commands are preferred if
the device supports them. Both are illustrated below.
__u8 register = 0x10; /* Device register to access */
__s32 res;
char buf[10];
/* Using SMBus commands */
res = i2c_smbus_read_word_data(file,register);
if (res < 0) {
/* ERROR HANDLING: i2c transaction failed */
} else {
/* res contains the read word */
}
/* Using I2C Write, equivalent of
i2c_smbus_write_word_data(file,register,0x6543) */
buf[0] = register;
buf[1] = 0x43;
buf[2] = 0x65;
if ( write(file,buf,3) != 3) {
/* ERROR HANDLING: i2c transaction failed */
}
/* Using I2C Read, equivalent of i2c_smbus_read_byte(file) */
if (read(file,buf,1) != 1) {
/* ERROR HANDLING: i2c transaction failed */
} else {
/* buf[0] contains the read byte */
}
IMPORTANT: because of the use of inline functions, you *have* to use
'-O' or some variation when you compile your program!
Full interface description
==========================
The following IOCTLs are defined and fully supported
(see also i2c-dev.h):
ioctl(file,I2C_SLAVE,long addr)
Change slave address. The address is passed in the 7 lower bits of the
argument (except for 10 bit addresses, passed in the 10 lower bits in this
case).
ioctl(file,I2C_TENBIT,long select)
Selects ten bit addresses if select not equals 0, selects normal 7 bit
addresses if select equals 0. Default 0. This request is only valid
if the adapter has I2C_FUNC_10BIT_ADDR.
ioctl(file,I2C_PEC,long select)
Selects SMBus PEC (packet error checking) generation and verification
if select not equals 0, disables if select equals 0. Default 0.
Used only for SMBus transactions. This request only has an effect if the
the adapter has I2C_FUNC_SMBUS_PEC; it is still safe if not, it just
doesn't have any effect.
ioctl(file,I2C_FUNCS,unsigned long *funcs)
Gets the adapter functionality and puts it in *funcs.
ioctl(file,I2C_RDWR,struct i2c_rdwr_ioctl_data *msgset)
Do combined read/write transaction without stop in between.
Only valid if the adapter has I2C_FUNC_I2C. The argument is
a pointer to a
struct i2c_rdwr_ioctl_data {
struct i2c_msg *msgs; /* ptr to array of simple messages */
int nmsgs; /* number of messages to exchange */
}
The msgs[] themselves contain further pointers into data buffers.
The function will write or read data to or from that buffers depending
on whether the I2C_M_RD flag is set in a particular message or not.
The slave address and whether to use ten bit address mode has to be
set in each message, overriding the values set with the above ioctl's.
Other values are NOT supported at this moment, except for I2C_SMBUS,
which you should never directly call; instead, use the access functions
below.
You can do plain i2c transactions by using read(2) and write(2) calls.
You do not need to pass the address byte; instead, set it through
ioctl I2C_SLAVE before you try to access the device.
You can do SMBus level transactions (see documentation file smbus-protocol
for details) through the following functions:
__s32 i2c_smbus_write_quick(int file, __u8 value);
__s32 i2c_smbus_read_byte(int file);
__s32 i2c_smbus_write_byte(int file, __u8 value);
__s32 i2c_smbus_read_byte_data(int file, __u8 command);
__s32 i2c_smbus_write_byte_data(int file, __u8 command, __u8 value);
__s32 i2c_smbus_read_word_data(int file, __u8 command);
__s32 i2c_smbus_write_word_data(int file, __u8 command, __u16 value);
__s32 i2c_smbus_process_call(int file, __u8 command, __u16 value);
__s32 i2c_smbus_read_block_data(int file, __u8 command, __u8 *values);
__s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
__u8 *values);
All these transactions return -1 on failure; you can read errno to see
what happened. The 'write' transactions return 0 on success; the
'read' transactions return the read value, except for read_block, which
returns the number of values read. The block buffers need not be longer
than 32 bytes.
The above functions are all macros, that resolve to calls to the
i2c_smbus_access function, that on its turn calls a specific ioctl
with the data in a specific format. Read the source code if you
want to know what happens behind the screens.
Click to expand...
Click to collapse

Surely if you want to use the light sensor in an application, the correct path is via API calls, or do you have other intentions?
Regards,
Dave

Ideally yes, but when you use the API to get the light sensor values, you get the accelerometer values instead! Interesting its similar on the Samsung Moment, asking for the light sensor values returns the compass values!
Seems neither HTC or Samsung know what they are doing!

Solved .[eVC++] How to use "srand" function?

Hello.
I want to ask some skilled developers,how to use "srand" function?
I found in help this:
Code:
/* RAND.C: This program seeds the random-number generator
* with the time, then displays 10 random integers.
*/
#include <stdlib.h>
#include <stdio.h>
#include <time.h>
void main( void )
{
int i;
/* Seed the random-number generator with current time so that
the numbers will be different every time we run.
*/
srand( (unsigned)time( NULL ) );
/* Display 10 numbers. */
for( i = 0; i < 10;i++ )
printf( “ %6d\n”, rand() );
}
Problem is,when I use this example,I get errormessages:
CNS.obj : error LNK2019: unresolved external symbol time referenced in function "void __cdecl PrepareWheel(struct HDC__ *)" ([email protected]@[email protected]@@Z)
ARMV4Dbg/CNS.exe : fatal error LNK1120: 1 unresolved externals
Without this function,function "rand" returns all the time same sequence(as we know).
I am using Embedded Visual C++ 4.0 for PocketPC app development.
That's for now,thanks,Tomas.

HD2 Android board ID

I have been reading quite a lot regarding android-porting and notes to OEMs on writing bootloaders for android. However, due to the current situation of port on HD2, i have a small problem that is, stock android init recommends the bootloader to pass a hardware identifier string which it will use to do init. I know i cannot explain perfectly as english is not my native language, here is a quote from android-porting group:
After the kernel boot is complete, the init program in the Android root file system gets started. This program parses and executes the scripts init.rc and init.XYZ.rc, where XYZ is the name given by the hardware vendor. The XYZ has to be specified as a value for the kernel parameter “androidboot.hardware=XYZ”. The init program uses this parameter to know the name of the script it has to start. On the goldfish target, XYZ is goldfish. On HTC Desire, XYZ is bravo. ie. "androidboot.hardware=bravo" is included in the kernel cmdline, so init.bravo.rc is executed alongside.
Click to expand...
Click to collapse
I have seen roms using bravo, htcleo, leo as their hardware identifier tags. However using either one of them as static string in cLK would be impartial for either. As of MAGLDR, it passes no cmdline (as far as i've seen) since it uses the yaffs2 boot structure and there is no cmdline it attaches statically. This could also mean that the current kernels instead of depending on the bootloader supplied info, use spaghetti code which makes assumption that it is running on a leo board, which is a deterrent if we are to merge the leo codebase with mainline code such as cm-kernel.
The current possibile solutions for cLK i have brainstormed over are:
1) Let it go as it is and do not include the hardware parameter.
2) Cleanup kernel space, script file names in roms, include the hardware parameter.
3) Leave the script names as it is, cleanup kernel code and let the user supply the hardware string through fastboot.
Q) What about MAGLDR ? it is closed source, we cannot change the kernel commandline in it !
A) Ever since we had NAND boot on HD2, the devs included a special kernel atag that would signal that the kernel is booting through NAND, so if this particular atag is found then the kernel would use a static hardware string.
Code:
*ptr++ = 4; // Size of this atag. atag[0]
*ptr++ = 0x4C47414D; // NAND boot atag. atag[1]
*ptr++ = 0x004b4c63; // cLK sign tag. atag[2]
*ptr++ = 16; // cLK version tag. atag[3]
All this logic could be wrapped inside something like "#ifdef TARGET_HTCLEO" to make it more clean till i notify cotulla about this on irc and he does the needful before the mag 2.0 release.
This exact thing was put into light some time ago by Charansingh but had no proper outcome, the thread stands dead with no actual agreement between chefs.
I tried my best and read as much as i could before writting down this post, if you have any suggestions, insights, solution, correction. Please PM me and i will update this post.

I just don't get it sorry

Hi Rick,
I'm not a dev, I only try to understand how Android works by reading your sources of cLK
But in order to be "Android compliant" it should be better to include a hardware parameter.
Now if I have correctly understood your post, this hardware parameter is stored by the boot structure on native Android devices.
In HD2, yaffs2 is used and there is no need to specify any parameters with it.
But on native Android devices, how is the boot structure? yaffs2 is also used? or this an other?

I dont really know too much but when im porting bravo roms with the the get prop=bravo i change it to leo to make it boot.

john_matrix said:
Hi Rick,
I'm not a dev, I only try to understand how Android works by reading your sources of cLK
But in order to be "Android compliant" it should be better to include a hardware parameter.
Now if I have correctly understood your post, this hardware parameter is stored by the boot structure on native Android devices.
In HD2, yaffs2 is used and there is no need to specify any parameters with it.
But on native Android devices, how is the boot structure? yaffs2 is also used? or this an other?
Click to expand...
Click to collapse
The boot structure on native devices including on cLK is as follows:
Code:
#define BOOT_MAGIC "ANDROID!"
#define BOOT_MAGIC_SIZE 8
#define BOOT_NAME_SIZE 16
#define BOOT_ARGS_SIZE 512
struct boot_img_hdr
{
unsigned char magic[BOOT_MAGIC_SIZE];
unsigned kernel_size; /* size in bytes */
unsigned kernel_addr; /* physical load addr */
unsigned ramdisk_size; /* size in bytes */
unsigned ramdisk_addr; /* physical load addr */
unsigned second_size; /* size in bytes */
unsigned second_addr; /* physical load addr */
unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */
unsigned unused[2]; /* future expansion: should be 0 */
unsigned char name[BOOT_NAME_SIZE]; /* asciiz product name */
unsigned char cmdline[BOOT_ARGS_SIZE]; /* kernel cmdline */
unsigned id[8]; /* timestamp / checksum / sha1 / etc */
};
/*
** +-----------------+
** | boot header | 1 page
** +-----------------+
** | kernel | n pages
** +-----------------+
** | ramdisk | m pages
** +-----------------+
** | second stage | o pages
** +-----------------+
**
** n = (kernel_size + page_size - 1) / page_size
** m = (ramdisk_size + page_size - 1) / page_size
** o = (second_size + page_size - 1) / page_size
**
*/
The cmdline argument is stored in the boot.img (for native devices and cLK) but cotulla felt that using yaffs2 is easier for testing many kernels, however you need a cwr zip package to flash a kernel in magldr, as using dwi.exe will format the phone while for cLK you can do "fastboot erase boot" and "fastboot boot zImage initrd.gz". However for cLK, the initramfs has to be reflashed with the new kernel.

Thank you Rick to reply me
Is the HD2 boot "trick" can be explain by the utilization of YAFFS2 for the whole HD2 NAND instead of EXT for native Android devices?
For example, maybe you need to specify the hardware parameter if you use EXT on the HD2 NAND (I don't know if this is possible?)
Correct me if I'm wrong (certainly )
Edit: for me, this is better to use fastboot commands in order to "manipulate" my HD2 but for the other users, I don't know. Maybe they can say to us.

GT-S8500 Restarting ITSELF EVERY 30MIN

Hey Bada Users
I own Samsung GT-S8500, great phone, fast, smooth, nice camera, expecialy HD 720p VIDEO.
But my phone keeps restarting every 20-30MIN itself, while i doing something, like browsing internet, playing music etc....
I have installed few ROM, BADA 2.0, BADA 1.2, but allways the same problem.. restarting..
Can solutio be getting '' android '' on my device or something code that can fix this?
And which android ROM doesnt have '' modem '' bug and fully working network?
Thanks

It is a problem with the power module. Also my father's wave have this problem. (Not every 30 min but every 1-2 hours)
Sent from my GT-I9500 using Tapatalk 4 Beta

how to fix it?

If warranty is still valid use it. If not, you can't do anything. Is an hardware problem
Sent from my GT-I9500 using Tapatalk 4 Beta

Alberto96 said:
If warranty is still valid use it. If not, you can't do anything. Is an hardware problem
Sent from my GT-I9500 using Tapatalk 4 Beta
Click to expand...
Click to collapse
no warranty, i really need some fix, software or anything,,,,

No software fix available. The only solution is a new motherboard
Sent from my GT-I9500 using Tapatalk 4 Beta

i can get motherboard for 10$, but theres no samsung care center in my country, and its to expensive... why i need complet motherboard, when the problem is only in power modul?

You could try to find hint about your problem.
Set Debug Level to High...
Enter:
*#33284*#
Post Bluescreen here...
To leave Screen Upload data to pc. Press and hold END Key for few seconds... or use this Tool:
http://forum.xda-developers.com/showthread.php?t=1176189
RAM dump eXtractor
Best Regards

adfree said:
You could try to find hint about your problem.
Set Debug Level to High...
Enter:
*#33284*#
Post Bluescreen here...
To leave Screen Upload data to pc. Press and hold END Key for few seconds... or use this Tool:
http://forum.xda-developers.com/showthread.php?t=1176189
RAM dump eXtractor
Best Regards
Click to expand...
Click to collapse
Well i get blue screen, but i cant upload it to PC!
So addfree, what do you thing i suggest to do now? ( no warranty, no samsung care center )
Can i solve this by opening phone myself, or some software or code ( like setting low debug mode ) to fix this?
Could maybe android NaND or FnF solve this problem?
If i send you bluescreen INF, can you tell me whats wrong with my phone, and send me a fix or?

If i send you bluescreen INF, can you tell me whats wrong with my phone, and send me a fix or?
Click to expand...
Click to collapse
Without Screenshot/Photo or RamDump_Information(BS_DoubleFault).txt I have NO idea...
Sometimes it is possible, that Ram Dump eXtractor not detect handset...
But if, then it is easier... example:
Code:
Modem:Q6270B-KPRBL-1.5.45T
SHP:VPP R5 2.1.1
Build Host:S1-AGENT01
BuildAt:2010/05/12 01:04:23
App Debug Level : 0
ASSERTION_ASSERT:0 failed. (fi
le SysSecureBoot.c, line 3868)
BoAn3868
<Callstack information>
PC = 4010B063 OemDumpRegister
LR = 4010B067 OemDumpRegister
<Mocha Task Callstack>
_SysAssertReport
__SysSecBootReadNetLockInfoFro
mFile
If IMEI is not set...
What shows your Bluescreen?
Best Regards

adfree said:
Without Screenshot/Photo or RamDump_Information(BS_DoubleFault).txt I have NO idea...
Sometimes it is possible, that Ram Dump eXtractor not detect handset...
But if, then it is easier... example:
Code:
Modem:Q6270B-KPRBL-1.5.45T
SHP:VPP R5 2.1.1
Build Host:S1-AGENT01
BuildAt:2010/05/12 01:04:23
App Debug Level : 0
ASSERTION_ASSERT:0 failed. (fi
le SysSecureBoot.c, line 3868)
BoAn3868
<Callstack information>
PC = 4010B063 OemDumpRegister
LR = 4010B067 OemDumpRegister
<Mocha Task Callstack>
_SysAssertReport
__SysSecBootReadNetLockInfoFro
mFile
If IMEI is not set...
What shows your Bluescreen?
Best Regards
Click to expand...
Click to collapse
S/W version: S8530+BO+LD1
Modem: Q6270B-KPRBL-1.5. 45T
SHP: VPP R5 2. 1. 1
Build Host: S1-AGENT08
BuildAt: 2013/03/05 17:19:24
App Debug Level: 0
ASSERTI ON_ASSERT: FALSE failed
( file SysECOM c, line 81 )
Ecom V2 Assert : Allocated App
( symbol size [ EventMgr: 100 ] is
lesser than Given Symb [ 146:
Wml sEventHandl er Valid ] n
< Callstack information>
PC = 4031B42B OemDupmRegister
LR = 4031B42F OemDumpRegister
<Mocha tast callstack>
_ SysAssertReport
This i write manually, and theres 7 more pages, should i write them all? ( This is the 1st page that i write )
And why S/W version is: s8530+BO+LD1 when my device is s8500 wave?
And yes, now i have Bada 2.0, Turko SF latest version, and now its not rebooting so often like on other softwares, why's that?

As Template...
Code:
ALL HW Information:
HW VERSION : S8500_REV07
IMEI VERSION : Not Active
RF CAL DATE : Not Active
Bad Block Information:
nNumBMPs : 0
nAge : 0
Run Time Bad Block Occurred :
Init BMPs = [COLOR="Red"][B]1[/B][/COLOR], Current BMPs =
0
You could check if your OneNAND memory is okay, or have damaged blocks...
No need to post more infos.
For now I have no real idea... need to investigate for SysECOM.
Best Regards

adfree said:
As Template...
Code:
ALL HW Information:
HW VERSION : S8500_REV07
IMEI VERSION : Not Active
RF CAL DATE : Not Active
Bad Block Information:
nNumBMPs : 0
nAge : 0
Run Time Bad Block Occurred :
Init BMPs = [COLOR="Red"][B]1[/B][/COLOR], Current BMPs =
0
You could check if your OneNAND memory is okay, or have damaged blocks...
No need to post more infos.
For now I have no real idea... need to investigate for SysECOM.
Best Regards
Click to expand...
Click to collapse
Can you suggest me what to do?
how to chech OneNAND or damaged blocks?
whats with SysECOM, you are only one who can help me now.

...and theres 7 more pages...
Click to expand...
Click to collapse
Navigate with Keys on left side... + or -
HOLD +
Otherwise you jump between 2 pages... Then check again for this request:
http://forum.xda-developers.com/showpost.php?p=41853793&postcount=12
About SysECOM.c ... you can find it in apps_compressed.bin... or Google result:
SysEcom.h from GT-S5230_S5233_S5600.zip
Code:
/*
* Samsung Handset Platform
* Copyright (c) 2000 Software Center, Samsung Electronics, Inc.
* All rights reserved.
*
* This software is the confidential and proprietary information
* of Samsung Electronics, Inc. ("Confidential Information"). You
* shall not disclose such Confidential Information and shall use
* it only in accordance with the terms of the license agreement
* you entered into with Samsung Electronics.
*/
/*:Associate with "Embedded COM" */
#ifndef _SYS_ECOM_H_
#define _SYS_ECOM_H_
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
#include "ShpTypes.h"
typedef UINT32 ECOMCLSID;
#define ECOM_VTBL(name) name
#define ECOM_INTERFACE(name) \
struct _##name {\
struct ECOM_VTBL(name)* pVtbl;\
};\
typedef struct ECOM_VTBL(name) ECOM_VTBL(name);\
struct ECOM_VTBL(name)
typedef BOOL (*EcomDispatch)(UINT32 action, ULONG param1, ULONG param2, void* pParam3);
#define DECLARE_EBASE() \
UINT32 (*AddRef) (void);\
UINT32 (*Release) (void);\
BOOL (*Dispatch)(UINT32 action, ULONG param1, ULONG param2, void* pParam3);
#define DECLARE_ECOM_VTBL(name) name* pVtbl##name; \
ADDR sb;
typedef struct
{
void* pClass;
ADDR sb;
} EcomType;
#define GET_ECOM_PVTBL(p, name) ((struct _##name*)p)->pVtbl
#define SysGetVtbl(compID, compName) (((T##compName*)(pDllBaseEcomFactory[compID-CID_BASE].pClass))->pVtblE##compName)
#define SysGetSb(compID) (((EcomType*)(pDllBaseEcomFactory[compID-CID_BASE].pClass))->sb)
#define INIT_ECOM_VTBL(p, name, vt) (GET_ECOM_PVTBL(p, name) = (ECOM_VTBL(name)*)&vt)
/*
* EBase Definition
*/
ECOM_INTERFACE(EBase)
{
DECLARE_EBASE()
};
#define EBaseAddRef(p) GET_ECOM_PVTBL(p, EBase)->AddRef()
#define EBaseRelease(p) GET_ECOM_PVTBL(p, EBase)->Release()
/*
* EComp Interface
*/
ECOM_INTERFACE(EComp)
{
DECLARE_EBASE()
BOOL (*Create)(EComp* pEComp, ECOMCLSID clsID, void** ppObj);
void (*Destroy)(EComp* pEComp);
};
#define ECompAddRef(p) GET_ECOM_PVTBL(p, EComp)->AddRef()
#define ECompRelease(p) GET_ECOM_PVTBL(p, EComp)->Release()
#define ECompCreate(p,id,ppo) GET_ECOM_PVTBL(p, EComp)->Create(id,ppo)
#define ECompDestroy(p) GET_ECOM_PVTBL(p, EComp)->Destroy()
typedef struct _EcomClass EcomClass;
struct _EcomClass
{
void* pData; // Private data
EcomClass* pNextObj; // Pointer to next class in the list
ECOMCLSID clsID; // Class information
};
typedef struct _EcomComp
{
DECLARE_ECOM_VTBL(EComp)
UINT32 refCount;
EcomClass* pObjList;
BOOL (*Create)(EComp* pEComp, ECOMCLSID clsID, void** ppObj);
void (*Destroy)(EComp* pEComp);
} EcomComp;
typedef struct
{
ECOMCLSID clsID;
void* pClass;
} EcomFactory;
extern EcomFactory* pDllBaseEcomFactory;
extern ADDR dllBaseSb;
#ifdef __cplusplus
}
#endif /* __cplusplus */
#endif // _SYS_ECOM_H_
Hmmm...
Is your Wave used or bought from used condition...
Is your Wave repaired or Unlocked by some magic box ?
Best Regards
Edit 1.
Google result...
http://forum.xda-developers.com/showpost.php?p=40393606&postcount=6
Here I can see 2 damaged blocks...
Btw... Check to remove your SIM Card... maybe then more then 30 minutes stable...
Edit 2.
http://forum.xda-developers.com/showpost.php?p=19496159&postcount=31
Okay, seems features of SysECOM.c wide range... Embedded COM

adfree said:
Navigate with Keys on left side... + or -
HOLD +
Otherwise you jump between 2 pages... Then check again for this request:
http://forum.xda-developers.com/showpost.php?p=41853793&postcount=12
About SysECOM.c ... you can find it in apps_compressed.bin... or Google result:
SysEcom.h from GT-S5230_S5233_S5600.zip
Code:
/*
* Samsung Handset Platform
* Copyright (c) 2000 Software Center, Samsung Electronics, Inc.
* All rights reserved.
*
* This software is the confidential and proprietary information
* of Samsung Electronics, Inc. ("Confidential Information"). You
* shall not disclose such Confidential Information and shall use
* it only in accordance with the terms of the license agreement
* you entered into with Samsung Electronics.
*/
/*:Associate with "Embedded COM" */
#ifndef _SYS_ECOM_H_
#define _SYS_ECOM_H_
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
#include "ShpTypes.h"
typedef UINT32 ECOMCLSID;
#define ECOM_VTBL(name) name
#define ECOM_INTERFACE(name) \
struct _##name {\
struct ECOM_VTBL(name)* pVtbl;\
};\
typedef struct ECOM_VTBL(name) ECOM_VTBL(name);\
struct ECOM_VTBL(name)
typedef BOOL (*EcomDispatch)(UINT32 action, ULONG param1, ULONG param2, void* pParam3);
#define DECLARE_EBASE() \
UINT32 (*AddRef) (void);\
UINT32 (*Release) (void);\
BOOL (*Dispatch)(UINT32 action, ULONG param1, ULONG param2, void* pParam3);
#define DECLARE_ECOM_VTBL(name) name* pVtbl##name; \
ADDR sb;
typedef struct
{
void* pClass;
ADDR sb;
} EcomType;
#define GET_ECOM_PVTBL(p, name) ((struct _##name*)p)->pVtbl
#define SysGetVtbl(compID, compName) (((T##compName*)(pDllBaseEcomFactory[compID-CID_BASE].pClass))->pVtblE##compName)
#define SysGetSb(compID) (((EcomType*)(pDllBaseEcomFactory[compID-CID_BASE].pClass))->sb)
#define INIT_ECOM_VTBL(p, name, vt) (GET_ECOM_PVTBL(p, name) = (ECOM_VTBL(name)*)&vt)
/*
* EBase Definition
*/
ECOM_INTERFACE(EBase)
{
DECLARE_EBASE()
};
#define EBaseAddRef(p) GET_ECOM_PVTBL(p, EBase)->AddRef()
#define EBaseRelease(p) GET_ECOM_PVTBL(p, EBase)->Release()
/*
* EComp Interface
*/
ECOM_INTERFACE(EComp)
{
DECLARE_EBASE()
BOOL (*Create)(EComp* pEComp, ECOMCLSID clsID, void** ppObj);
void (*Destroy)(EComp* pEComp);
};
#define ECompAddRef(p) GET_ECOM_PVTBL(p, EComp)->AddRef()
#define ECompRelease(p) GET_ECOM_PVTBL(p, EComp)->Release()
#define ECompCreate(p,id,ppo) GET_ECOM_PVTBL(p, EComp)->Create(id,ppo)
#define ECompDestroy(p) GET_ECOM_PVTBL(p, EComp)->Destroy()
typedef struct _EcomClass EcomClass;
struct _EcomClass
{
void* pData; // Private data
EcomClass* pNextObj; // Pointer to next class in the list
ECOMCLSID clsID; // Class information
};
typedef struct _EcomComp
{
DECLARE_ECOM_VTBL(EComp)
UINT32 refCount;
EcomClass* pObjList;
BOOL (*Create)(EComp* pEComp, ECOMCLSID clsID, void** ppObj);
void (*Destroy)(EComp* pEComp);
} EcomComp;
typedef struct
{
ECOMCLSID clsID;
void* pClass;
} EcomFactory;
extern EcomFactory* pDllBaseEcomFactory;
extern ADDR dllBaseSb;
#ifdef __cplusplus
}
#endif /* __cplusplus */
#endif // _SYS_ECOM_H_
Hmmm...
Is your Wave used or bought from used condition...
Is your Wave repaired or Unlocked by some magic box ?
Best Regards
Edit 1.
Google result...
http://forum.xda-developers.com/showpost.php?p=40393606&postcount=6
Here I can see 2 damaged blocks...
Btw... Check to remove your SIM Card... maybe then more then 30 minutes stable...
Edit 2.
http://forum.xda-developers.com/showpost.php?p=19496159&postcount=31
Okay, seems features of SysECOM.c wide range... Embedded COM
Click to expand...
Click to collapse
What can i do, how can i fix it?
Best Regards

Can i solve this by opening phone myself, or some software or code ( like setting low debug mode ) to fix this?
Could maybe android NaND or FnF solve this problem?
Click to expand...
Click to collapse
You can only try to identify problem... then maybe cheap solution.
Maybe it is Hardware, maybe it is Software problem...
Bluescreen message about SysECOM.c ...
I have NO idea, what exactly this means abour your Wave...
You could try to install Android...
http://forum.xda-developers.com/showthread.php?t=1851818
If it also restart/shut down... then 88,88 % Hardwaretrouble...
Again, your Wave shows damaged blocks?
Yes or no ?
Easy task.
http://forum.xda-developers.com/showpost.php?p=41853793&postcount=12
Next Bluescreen, navigate to site/page 2 and read info...
Best Regards

adfree said:
You can only try to identify problem... then maybe cheap solution.
Maybe it is Hardware, maybe it is Software problem...
Bluescreen message about SysECOM.c ...
I have NO idea, what exactly this means abour your Wave...
You could try to install Android...
http://forum.xda-developers.com/showthread.php?t=1851818
If it also restart/shut down... then 88,88 % Hardwaretrouble...
Again, your Wave shows damaged blocks?
Yes or no ?
Easy task.
http://forum.xda-developers.com/showpost.php?p=41853793&postcount=12
Next Bluescreen, navigate to site/page 2 and read info...
Best Regards
Click to expand...
Click to collapse
Again im set high debug level, and yes, i get bad block information.
Bad Block Information:
nNumBMPs: 0
nAge: 0
Run Time Bas Block Occurred:
I ni t BMPs = 2, Currect BMPs= 0
What does this mean?

What does this mean?
Click to expand...
Click to collapse
Good Question...
0 bada blocks could be 100 % perfect.
My S8500 test device with broken Display and attached with soldered wires to my RIFF JTAG Box works with some minor problems...
Not all things tested/used... because my SIM Cards are not active...
So no Calls, SMS etc...
http://forum.xda-developers.com/showpost.php?p=13582911&postcount=13
With JTAG I can see the address where the bad block is located...
Here my Thread about bad blocks...
http://forum.xda-developers.com/showthread.php?p=42030607#post42030607
Maybe if more users could check about bada blocks and problems of their Waves...
Its like defect clusters in PC world...
If your Harddisk is damaged... with bad clusters...
A.
You can try to """Low Level Format"""... but this ""dangerous""...
Risk of data loss sooon or in future is much higher...
B.
Replace HD by new one...
Same for your Wave... maybe the 2 bad blocks are ignorable...
But maybe this is one more sign, that your Hardware is not 100 % okay...
One more scenario...
I have NO idea about your country... nor about your Wave, if it is from Operator... Branding...
With Serial Number S/N under your battery you can check with Kies, which Firmware is exactly for your Wave...
Because it seems few Differences for different countries and mixed Firmware can cause in some sideeffects/problems...
http://forum.xda-developers.com/showpost.php?p=36482821&postcount=315
Check Firmware from Kies...
Best Regards

adfree said:
Good Question...
0 bada blocks could be 100 % perfect.
My S8500 test device with broken Display and attached with soldered wires to my RIFF JTAG Box works with some minor problems...
Not all things tested/used... because my SIM Cards are not active...
So no Calls, SMS etc...
http://forum.xda-developers.com/showpost.php?p=13582911&postcount=13
With JTAG I can see the address where the bad block is located...
Here my Thread about bad blocks...
http://forum.xda-developers.com/showthread.php?p=42030607#post42030607
Maybe if more users could check about bada blocks and problems of their Waves...
Its like defect clusters in PC world...
If your Harddisk is damaged... with bad clusters...
A.
You can try to """Low Level Format"""... but this ""dangerous""...
Risk of data loss sooon or in future is much higher...
B.
Replace HD by new one...
Same for your Wave... maybe the 2 bad blocks are ignorable...
But maybe this is one more sign, that your Hardware is not 100 % okay...
One more scenario...
I have NO idea about your country... nor about your Wave, if it is from Operator... Branding...
With Serial Number S/N under your battery you can check with Kies, which Firmware is exactly for your Wave...
Because it seems few Differences for different countries and mixed Firmware can cause in some sideeffects/problems...
http://forum.xda-developers.com/showpost.php?p=36482821&postcount=315
Check Firmware from Kies...
Best Regards
Click to expand...
Click to collapse
A.
How to do Low Level Format, guide?
B.
How can i replace HD by new one?
C.
My country is Bosnia And Hercegovina, not from operator, i bought it from used condition. I will try this.

Galaxy3HELL said:
A.
How to do Low Level Format, guide?
B.
How can i replace HD by new one?
C.
My country is Bosnia And Hercegovina, not from operator, i bought it from used condition. I will try this.
Click to expand...
Click to collapse
Brate,sto jednostavno ne probas android,ako i tamo zeza,onda je harver upitanju..