[Windows Mobile Software Development] smb_gaiden:
Thank you for the further elaborations. I managed to use my phone a lot less today and had a good few sessions in the debugger. Unfortunately no IDA Pro here...

First, I was able to verify the local PI code by using the Silicon Labs si4703 USB dongle. Then I Added some code to do a mem search forwards and backwards for the PI code triggered off of lpInfo. Neither way worked. lpInfo is a pointer to the stack. (SP is in the general area as lpInfo). Result from the above: The structure doesn't give any PI data near it. Nothing inside the structure looks like a pointer to extended memory either.

I put 0xbabeb00b as the third parameter in the registration function and received it back as lpData. As suspected, it is a user parameter that is passed back. I traced the structure it is retrieved from before calling the callback and it didn't lead to anything exciting. It is loaded off a PC relative address, so they probably have a global variable to hold that structure. I checked the adjacent pc relative address and it didn't lead me anywhere.

I traced back further to see what the parameters to the function that calls the callback are and they seem to be two also. One is the aforementioned structure that holds the CB data. Another is a region in RAM (not stack this time) which mirrors the data inside the lpInfo structure (regarding PS Scrolling and RadioText). I did some look around the area and no raw RDS was present, so I looked for any pointers in the same area to jump to and did not see much promise nor any raw RDS or PI code value.

The FMSDK call stack is 4 deep before it gets to the callback. The base address that leads off seems to be some library function. Probably some timer or wndproc or equivalent of sorts. I am just going to focus now on breaking at the top of this stack and walking through the code. The highest level callstack item is a loop which calls into the callback a few times, so I suspect there is some RDS data processing taking place there. We'll see!

-=-=-=-=-=-=-=-=-=-=-=-=-

EDIT - More Info, discussion points and to keep my memory on track when I revist

More notes, more for journal. Sorry for polluting your thread, please let me know if you'd rather I avoid posting these items!

As I was saying there seems to be some loop and between the loop and the callback there is an update to the PS Scrolling and RadioText. I was able to recognise this loop (I never broke when it was entered, just as a follow on after I switch stations). I believe it to be a thread rather than WM or WndPorc, since it never terminates until the app is closed. It also does not terminate when I press the Power OFF button.

At address 0x01910920 is where the buffer is where the PTY is 7, the char before it is changing sometimes, it may be the present buffer ptr into the RadioText field (I did not verify that point, just a hunch). Following the PTY is the PS scrolling text. Following that may be space or may directly be the RadioText buffer. When the RT buffer blanks (between songs for instance), it is replaced with all space chars 0x20 rather than NULL 0x00.

Before I get to the main loop, these are the modules loaded during execution of the program:

Load module: FMRadio.exe

Load module: commctrl.dll.0409.MUI

Load module: commctrl.dll

Load module: aygshell.dll

Load module: ossvcs.dll

Load module: coredll.dll.0409.MUI

Load module: ole32.dll

Load module: coredll.dll

Load module: WS2.dll

Load module: BtCECommon.dll

Load module: FmRadioSdk.dll

Load module: checkime.dll

Load module: OLEAUT32.dll

Load module: HTMLVIEW.DLL

Load module: eT9ime.dll

Load module: eT9DisInput.dll

Load module: eT9Dictionary.dll

Load module: ShUtil.dll

Question: Anyone know how I can know which address these are loaded to? in PC Land I can call LoadLibrary() and get the address, but that doesn't seem valid on this platform since the LoadLibrary to FMRadioSdk.dll returns what looks to be a handle than an address, especially since the VTable function pointers are vastly different than the HMODULE. Would eb good to do what I do in PC land and find the load address and do a dumpbin /exports LIBRARYNAME, and then I Can know which library functions are invoked from the code and comments that follow.

A Little comments about the main loop. You can see a few local jumps and a few calls to code. I will explain the little that I know.

Main Loop

7804E30C ldrb r3, [r4, #0x15]

7804E310 cmp r3, #0

7804E314 bne 7804E37C # This is never executed in the operation, r3 is zero (didn't check during termination)

7804E318 ldr r0, [r4, #4]

7804E31C mvn r1, #0

7804E320 bl 7804E89C # This is really a jump table (maybe thumb/arm switch) to some possible library WinAPI fn, since the addr is not familiar to me. It Might be similar to WaitForSingleObject or whatnot. I am not positive it freezes here until more RDS, but it is my current hunch.

7804E324 ldr r1, [r4, #0x10]

7804E328 mov r3, #1

7804E32C add r2, sp, #0

7804E330 str r1, [sp]

7804E334 mov r1, r5

7804E338 mov r0, r4

7804E33C bl 7804E17C # This one causes the PS Scrolling, RT, and char before PTY at 0x01910920 to change! I have to trace into here in detail later.

7804E340 cmp r0, #0

7804E344 beq 7804E37C # Not jumped while operational

7804E348 ldrb r3, [r4, #0x15]

7804E34C cmp r3, #0

7804E350 bne 7804E370 # Sometimes jumps, must mean there's nothing to tell the CB Function Listener.

7804E354 ldr r2, [sp]

7804E358 cmp r2, #0

7804E35C ldrne r3, [r4]

7804E360 movne r1, r5

7804E364 movne r0, r4

7804E368 movne lr, pc

7804E36C ldrne pc, [r3] # Kicks off a call chain that gets 4 deep before reaching our callback function...

7804E370 ldr r3, [r4, #4]

7804E374 cmp r3, #0

7804E378 bne 7804E30C # The end of the loop kicking us back to the start

7804E37C ldr r0, [r4, #0x18] # Setting a BP here only is hit when I exit the app, not on the Power OFF button.

Hope this helps the discussion along and helps me keep my state machine in my mind the next time I am able to revisit this code.

-=-==--=-=

EDIT

I may have hit the end of the road. I traced into the BL above and the text gets changed during a Bx statemnt, that's a branch or function call.

The command is BX R5, where R5 = 0xf000aebc

I could not F11 step into that, it came from this address:

03F75470 bx r5

I don't know who was loaded in 0x03F75470, but when I pressed F11 there it just did a step over and I saw the memory in the 0x01910920 change to add more RT.

Since it seems, to me at least, that the parsing is occurring inside a protected memory zone, I am looking at some alternatives. Hopefully not replacing FMRadioSdk.dll cuz that's a lot of work. Any chance using 13 C 0000399C FM_SetRdsMode could request for RAW data instead of the parsed data?