2

I am trying to modify the mobile OS, so that I can control which call to take, and which one to reject, and also to run some signal processing.

I am playing with Android OS, but I need to talk to baseband OS, and I am sure there is some way as whenever we get a phone call, the mobile OS user interface comes to life, and whether we want to take or reject the call - this decision can be taken at mobile OS layer, which then gets transmitted to baseband OS!

I have tried to find in Google, but can not find a thing, on what kind of interface exists between baseband OS and mobile OS.

Help would be greatly appreciated!

user3001408
  • 310
  • 5
  • 20
  • For an example of a backdoor exploiting this interface, see [Samsung Galaxy Backdoor](http://redmine.replicant.us/projects/replicant/wiki/SamsungGalaxyBackdoor). This might make a good starting point into looking into how this interface works generally. – Michael Hampton Aug 05 '14 at 03:50

1 Answers1

1

The primary mechanism in Android for communicating with the radio is /dev/smd0, which implements an AT modem with many extended commands. I do not know how that device is implemented but I would recommend looking at its source. I believe it's essentially serial.

The OS (if I recall) has a daemon which monitors and interfaces with this device.

For example, when the phone needs the baseband to register on a mobile network, it can send AT+CREG=1 to that device, and the baseband will take care of it (and return 0). To dial a call it will send ATD8005551212 or something to that device. To pick up a call it will send ATA; to hang up it will send ATH, just like a modem.

The incoming call transaction on that device looks something like this. The baseband will print +CRING: VOICE on /dev/smd0, and the OS can send AT+CLCC to get the caller ID, which is formatted as an extended status message: +CLIP: "+18555551212",,,,"" or something.

I understand that sometimes the device name for this varies; it might be /dev/ttyUSB0, for instance, if the interface to the baseband is implemented as a USB serial port.

You'd be doing this at the system app layer, and not inside the kernel, which I believe would be the correct way of going about it.

Falcon Momot
  • 1,065
  • 8
  • 20