Hello to all,

since awhile i am looking for Dissassembly and debug tools on a pocket PC (ARM). Little success, so far, i tried with an old Wdasm (92), olly, and with an ARM dissassembler (PODUMP), but none of them was really a breakthrough for what i had in mind. PE file tools and resource editors worked so far, but sure didnt show up alone with the results i looked for.

I nearly had asked here on this board (which i know for a long time already) for the state of the art of (CE) disassemblers and debuggers (since i searched with "PDA" with no result ;-) but finally the simple "Windows CE" searchstring hit.... stupid me.
(You wont believe, the "Wince" string brought up eve more....8-), quickly learning, eh ?)

Boy, i read JMIs post in hxxp://woodmann.com/forum/showthread.php?t=7184, i just escaped THAT one ;-), i read about evt and IDA possibilities. My first try with evc 3 failed, but then i found the hint of evc4 necessary for windows mobile 2003 (which i have). I found kaos website and different other papers - still enough to read.
Now, ida is already found, Evc4 will follow, and all the hints will (hopely) lead to an acceptable debug session workbench for me.

So far, thanks for the bunch of material i could find here and elsewhere pointed to.

Back to the reason of this post - little use of just telling about my lazy approach 8-)....here is the question(s) i should ask? (and i hope not to get hit for asking early...)

What i have to face is the fact, that the programm is usually inputting data from the pocket PCs com 1 (GPS data) - which will be occupied by the PC link during debugging session. Hm - and i have no idea about connecting the gps mouse in parallel.... hardware limitations of the pocket.

If i had a bluttooth pocket getting the data via blue......but i havent. any other idea except modifying the complete input procedure to read file data (which could be way over my head)??

Given that working or not, i am worrying about finding the places where to modify the code, since i have a different task than usual: no serial checking, since i own the software, which even has no serialization. Thus as well no debug protection fight.....i am targetting this (a GPS program) due to serious functionality bugs and necessary improvements, which seem to come out even more slow that my approach to fix them by myself.....;-)

The one thing i am looking for is some graphical sign i find in the display of the program - a green arrow which obviously is totally computed. No hint for it in the pe resources, nor in an attached bmp, where obviously all other graphics are stored.
Any hint for a method except plain downtracking it (and i doubt it will be painted directly to the screen), or a zen approach in recognising code snippets as that task(s), or tracking the speed info usage from the gps data (the arrow is modified due to the speed data)??

the second i am looking is similar subtle - modifying the conditions when sound messages are triggered, - depending on the speed compared to the different possible limits. There i suggest to have to backtrack jumps into any sound-related dlls, in forward tracking where the speed information of the gps ist stored and used for, - or is there any different approach thinkable?

Greetings to all.....

Hi

I have no experience with ARM debugging, but is there not a set of API's which define graphical and other functions that you can either monitor or determine from the disassembly? A graphical object could be generated entirely from a DIB section as raw data for example and displayed on the screen as a bitmap through an appropriate call. The sounds might be generated by direct I/O access to the speaker port if not through API channels. You speak of it as a regular PE file, so I'm a little unsure as to why it's so problematic.

Kayaker

Hello,

Can you install and run the application on an emulator, letting you use the PCs serial port for your GPS device, and still debug over TCP/IP?

I've done this in the past when developing such applications, unless there's more pda specific hardware that I'm using (which is when it becomes a right pain, you have to write the code in two bits essentially).

As for tracking the speed usage, the application is probably reading NMEA from the GPS device, which doesn't inherently have a notion of speed - it's probably extrapolating it from discrete position reports. Have a look at the NMEA specification, it's plain text, and the GPGGA message is the one with lat/longs in it, IIRC, it'll get chopped up and parsed somewhere.

cheers,

Martin

Yes, there is a set of APis, which sholud define most of the things in Ce similar to Windows. I will have to look and learn into these things.

I doubt it is a direct I/O acces for the spaker since standard Wav files are played - you could not know about this because i didnt tell, sorry.

Its standard PE since its Windows, but for ARM processor, and i have found little support in debugging these execpt on this board.

Thanks for the hints about the graphics, i will llo for this path.

Martin, i have no emulator available except the original PDA/ Pocket PC.
I doubt this will work with an (ARM) PocketPC Emulator running under win2k - this will emulate apocket pc but not attaching the sierial ports - or will it ?

regarding GPS - yes it is NMEA (hm, i believe it is, will recheck ist).
OOps - no speed in this protcol??
I have a Data logger for the GPS port ready and will check taht in detail before divin' into debugging. Thanks for the tips anyway.

I think you are missing the GPRMC message which also contains latitude/longitude, and additionally date, course in degrees and speed over ground in knots

In which case I was wrong on both counts!

You won't be able to run the app on an emulator unless you've specifically built it for the emulator.

Sorry, it's been a while.

@martin,

dont worry. Any input is very much apreciated, and gives new approaches for thinking anyway. (and it has...)

I have gotten ida to work now on ARM, what a tool ! wow!
I understand little of that what i see, but i will work through the manual and some API/DLL references before showing up with more questions.

CU

Hello to all,
i have made my first steps now in my new world of IDA and ARM debugging....
certain insights have been earned, but some general understanding problems do come up.

I have told in my first posts that i am looking for modification of some grapical screen elements that a program writes onto the screen.

I could track down (with IDAs help) some "polyline" and "polygon" subroutine (DLL?) entrys (heaven may know why i breaked at that ones first ;-), entries into dll and system calls.

I have found one of them which can divide the writing on the complete screen i am observing into several steps - good start i think. Strange is, that i cant track down to every single object there - the one i am looking for appears together with several others.

Since i am programming in delphi (usually) i know from there that writing onto a screen will show up inside of a (delphi)debugging session will only take effect when a "application.proccesmessages" has been inserted - making the windows subsystem (GUI?) transferring the "written" objects to the physical screen.

Now i am assuming that c++ (which the code in question is obviously written in) will work similar then my break is sitting somewhere inside of this "application.proccesmessages" of c++ - or how it is called there.
The code in question will be found by backtracing the calling sequence up to the upmost calling programm .....ahem - is that the right understanding?

And if - it would be interesting if EVT can write a protocol about the programm calling sequence instead of making me step this by hand... but i dare not to ask since i have not really checked the manual for this....=:-0 (blush)

Greetings to all.....

PS: To all interested, a nice GPS data description in hxxp://www.programmersheaven.com/2/Writing-Your-Own-GPS-Applications