I am particularly interested in the wizard, however on a fundamental level WM will most likely operate the same across most models in respect to this issue (or at least that is the theory).
I realize that most GSM boards have processors on them which do things like channel syncing (which is fairly time sensitive since its tdma&fdma), a5, gsm framing, and all that. You more or less connect a sim, speaker and mic, and treat the gsm rf board as a black box.
I am hoping that somewhere someone has unearthed something that allows more direct control over the gsm board on these phones. I am aware of engineering mode, however that is not quite what I wanted.
I would like to be able to at the very least set the call parameters before a call goes out. For example, lets say that I want to disable A5, sinec there are 3 standard levels one being no encryption, and the tower and the phone negotiate and agree upon the highest common, something in the phone somewhere has to say that it supports encryption.
I am just uncertain if all that is burried away in a 'black box' somewhere and its not a software problem from within WM.
If anyone has any ideas I would greatly appreciate it, even if they are pointers to research material that may help me out a bit.
On WinMobile GSM part is isolated from the windows part, like in normal PCs modem hardware is isolated from mainboard. GSM part has its own CPU, RAM, ROM, operating system, and communicates with Windows via COM-port (or USB port in Universal). For example Universal has Qualcomm MSM6250 chip with some proprietary OS. HTC Himalaya had a different chip (I don't remember it now), and OS was based on nucleus RTOS. Anextek SP200 communicator had Siemens MC45 modem inside.
GSM hardware is a black box for WinMobile OS. MS specifies only some recomendations for OEMs, and controlling encryption is not among them. You can control it if GSM vendor supports some AT command, or some other proprietary method (maybe via dev_specific RIL command).
In the case of Universal, its GSM can be controlled from a PC with the usual Qualcomm diagnostic software (QXDM, QPST, etc), when you setup the device as a pass-through bridge between PC and GSM module. But I don't know any methods of doing the same from inside WinMobile.
mamaich said:
GSM hardware is a black box for WinMobile OS.
...
You can control it if GSM vendor supports some AT command, or some other proprietary method (maybe via dev_specific RIL command).
In the case of Universal, its GSM can be controlled from a PC with the usual Qualcomm diagnostic software (QXDM, QPST, etc), when you setup the device as a pass-through bridge between PC and GSM module. But I don't know any methods of doing the same from inside WinMobile.
Click to expand...
Click to collapse
That is what I was afraid of. Most of the GSM radio boards (or individual chips) are set up to act that way, and since its faster and cheaper I really dont know of anyone that hasnt done that in any phone that was made in the last few years.
At any rate, is there any documentation that discusses how to locate which com port or other method is used to access the GSM device within a wizard (or any other htc model, odds are many of them are similar, if not identical with this subcomponent).
Are there any known AT commands? my first project is to write something similar to the gsm engineer mode program, obtaining BTS information. I am unsure if this is obtained only via AT commands or if its something more involved, but welcome any information on this.
Found what appears the be half the answer at http://wiki.xda-developers.com/index.php?pagename=RIL While that gives me access to the radio for some stuff (location data app that can work with gsmloc.org for example) it does not appear to enable me to set any parameters for a new call.
So if anyone knows of any tricks that would help say for example disable a5 crypto (on a per call basis idealy) or something similar to the setup of a call I would still appreciate hearing about that.
I know that Typhoon ( spv c500 / i-mate sp3 /Dopod 565) memory block with gsm info data. I am trying to find it in Magican - but no results. I dont know how Typhoon place this info in mem.
Related
Is it that hard to get read-only access to GSM processor memory? I know that in smartphones memory is shared, but in PDAs it does not (I'm specifically interesting in Magician). Is there a kind of mechanism how main CPU can access GSM memory? I now itsme was trying to re-create rsupgrade that is able to flash radio-stack: http://www.xs4all.nl/~itsme/projects/xda/xda-rsupgrade.html, but it seems that no solution were found. There is also incomplete description of the correspodning protocol http://www.xs4all.nl/~itsme/projects/xda/serial-protocols.html, but it is not clear whenever we can access normal gsm RAM this way or only flash...
Can people share with me some ideas how this issue can be solved? May be there is simple way of doing that, but I cannot see it...
P.S. If someone is interesting - I want to get an access to information about nearby cell towers like this people do: http://celltrack.spv-developers.com/?act=demo[/i]
Hi all, I'm a newbie to HTC PPC's, and I've got to port a soft initially written for the HTC Universal on a HTC Apache. This soft provides a few non real-time services like chat and presence, and real-time applications like VoIP and legacy calls. I don't want to change anything to those applications, just make them work in a CDMA network context. The soft uses the windows mobile connection manager component to identify which connection to use, so I guess I will be forced to modify this part to enable CDMA connections. But I've no idea if there will be any major compatibility problem between those two devices for my soft, because for example of changes in the windows mobile API supported in the HTC Apache. I would be glad if someone could help me to identify the risks that exists in this attempt of porting.
Thanks a lot,
Antoine
How deep down to the hardware dos your app go?
Generally windows connection manager and windows sockets completely obscure the actual details of the cellular network so it should make no difference what so ever for the program if it is working with GSM, CDMA or WiFi.
If you are using RIL to actually send commands to the modem that would be a different story.
Unfortunately I have very little knowledge with this but my suggestion would be looking up CDMA mode commands in google as a start.
Normally, the soft only relies on the windows mobile connection manager API for connections, and the TAPI for calls. In fact, I was asking myself about the impacts on the display of my HMI on this new device or the codec issues...
I keep reading about problems with the radio not being compatible because the rogers radio is somehow different. What exactly is the radio? I'm betting it doesn't mean my phone will tune in to AM/FM stations....unless it does and makes me love my phone even more...lol
basically the phone radio controls your reception, with a newer radio you will usually get a better reception quality as well as GPS fix is faster.
the radio also controls how fast the camera is and a little bit of the quality(i don't know why i just know it's true
XwXDv8XwX said:
I keep reading about problems with the radio not being compatible because the rogers radio is somehow different. What exactly is the radio? I'm betting it doesn't mean my phone will tune in to AM/FM stations....unless it does and makes me love my phone even more...lol
Click to expand...
Click to collapse
In the context of phone hacking/hardware, the "radio" refers to the part of the phone which communicates with cellular towers. It is so named because the communication is done via radio waves. Specifically when people talk of flashing the radio, they are referring to the baseband processor. In most modern (2G and up) mobile phones, there are actually two processors. One is the application processor, which does all the work involving the operating system and apps. The other is the baseband processor, which actually deals with the GSM or WCDMA air interface (its a lot more complex than just broadcasting ones and zeros into the air).
Why would they use two processors instead of one? There are two main reasons. The first is that in order for cell networks to function properly, timing is key. For example, in the GSM system, each frequency is divided up into several time slots (TDMA means Time Division Multiple Access). The length of these slots are counted in the milliseconds. If a phone starts transmitting just a couple of milliseconds too late, it will overlap into the adjacent time slot and corrupt both its own and the neighboring transmission. Now, have you ever had your phone lag up because it was doing something complex? If the GSM stack ran on the same processor as the application stack, any system lagging introduced by the os/apps could cause the GSM connection to be unstable. The other reason is security. Especially in the age of smartphones, users are able to run code that may not be verified as secure. Separating the two functions prevents malicious code from tampering with the radio operations.
Note however that there are some flavors of Symbian which CAN run both the applications and baseband on the same processor. These are called real-time flavors of Symbian, so noted because the processor will always execute the baseband in real-time, regardless of how high apps are prioritized. This solves the timing problem, but other techniques have to be employed to add additional security.
Hello,
I would like to request your help in locating a SIM card sniffer in order to better learn/observe the SIM-GSM card.
Apart from hardware devices, I had an idea which I hope to confirm in this forum:
Do you think there is a way to hook/manipulate the phone's firmware/software (ex. WM Phone) in order to watch the transactions between the Smart Card and its peer (possibly a driver)? Eventually I’d like to get a sniff of APDU transactions which will assist me in understanding the protocol, and having a Soft-Sniffer seems much more cost effective and resource less.
Many thanks
A WM driver will most probably communicate with radio firmware using a higher level protocol. Radio firmware will actually issue SIM APDUs, so this is where such a sniffer is likely to be required to reside. There's usually no public/known API to plug into the radio firmware at this level and therefore no such sniffer either, AFAIK.
stepw said:
A WM driver will most probably communicate with radio firmware using a higher level protocol. Radio firmware will actually issue SIM APDUs, so this is where such a sniffer is likely to be required to reside. There's usually no public/known API to plug into the radio firmware at this level and therefore no such sniffer either, AFAIK.
Click to expand...
Click to collapse
ask viperbjk ... he can help /
QMAT allows sending APDUs via AT commands.
Functions for all mobiles with AT modes:
1. Send APDUs to SIM card
2. Read out all SMS with all headers
3. Send any AT command
Sniffing is a different story.
Hi
My idea should work like that:
You have 2 devices with installed this, and you can send an sms, do a call etc without connection to tower, just directly to other device.
It has sense, huh?
Also what about emulating an GSM tower with a device (+ additional antenna etc) which can receive common tasks from another devices?
It's a no. You're limited by hardware.
retsam88 said:
It's a no. You're limited by hardware.
Click to expand...
Click to collapse
Why? except firmware limits
Well, think as phone is like 'slave' for 'master' base station. You cannot change from slave into master, also you would need a huge processing power to differentiate between every cell phone. If you wan't more info, read tech pdf's about GSM cell structure.