Access to GPS on a780

[mack]

I compared SEEM 0032_0001 of my phone and a GPS phone. Not too many bits differ. We could try them. Here's the list of different bits:

Offset 0x43: 0
Offset 0x8A: 3 4
Offset 0x8C: 0
Offset 0x8D: 0
Offset 0x93: 0
Offset 0x97: 3
Offset 0x9A: 0
Offset 0x9B: 2 3 5
Offset 0x9F: 1 2 3 4
Offset 0xA3: 1 2 3 4
Offset 0xC3: 1 3
Offset 0xC7: 0 2
Offset 0xCB: 0 1
Offset 0xCF: 1 3
Offset 0xD3: 1 3
Offset 0xEB: 0
Offset 0xF7: 1 2 3 4

Note that in 8A, only bits 3 and 4 are on in the GPS phone. Bit 5 (which was mentioned in this thread) appears to be off.

Anyway, before we start enumerating these 34 bits, does anyone know what some of these bits mean ?

[mack]

No luck. One of these bits did something GPS-related - it added the word "GPS" at the bottom of the status screen, below the transflash status. Wasn't clickable though.

Aside from that, nothing new. lapisrv still hangs and the dish is still crossed out.

Any other seems worth playing with ?

[samr7]

No luck. One of these bits did something GPS-related - it added the word "GPS" at the bottom of the status screen, below the transflash status. Wasn't clickable though.

Whoa, which one was that?

[mack]

I'm not sure. I didn't test them one at a time. I think it was one of the 8X or 9X ones. Anyway, it didn't get me anywhere. Just added the word GPS to the status without anything under it.

btw, samr7, did you take a look at the other seems downloaded from the phone ? Any idea why some of them contain GPS-related strings ? They look a bit like pieces of the BP code.

[samr7]

I'm not sure. I didn't test them one at a time. I think it was one of the 8X or 9X ones. Anyway, it didn't get me anywhere. Just added the word GPS to the status without anything under it.

btw, samr7, did you take a look at the other seems downloaded from the phone ? Any idea why some of them contain GPS-related strings ? They look a bit like pieces of the BP code.

Interesting.

All the strings that can be found in SEEM dumps also tend to appear in the CG2 section image from the firmware files. This is the "flex" / "BPFlex" configuration area. It is meant to be editable, and the motofan.ru guys think it's structured using Intel FDI as the wear-evening technology. In cases where RSA signatures are used, it is not protected so that it may be modified. Because of this, it seems unlikely that it contains any executable code.

At least some of those strings look like file names that were inserted by __FILE__ or such in the C language -- what else is a program going to do with a string like "/vobs/synergy_device_layer/code/dl_gps/src/dp_gps_sp_assist_data.cc" other than paste it into an error message? Strings of that sort are usually created and inserted automatically by the compiler, and are read-only. Storing them in the proprietary, read-write SEEM data store doesn't make much sense. There must be some other meaning.

[mack]

As you can see in those SEEMs, its not just the __FILE__ instances. It also contains some other strings such as "Voice mail" "service" "roam", and others, and they appear in the same area and same order as they do in the BP. I suspect some pieces of BP code somehow leak to certain (unused?) SEEM addresses. Some SEEMs appear to be unmapped (thus causing a crash when you read them). Maybe some others are mapped to some random memory. If this is the case, it could be very interesting, especially if we can find some writable piece of code through which we could gain an entry point to the Neptune.

By the way, besides the strings, there are some unicode strings in these SEEMs. For example, "/b/GPS_PHX.LOG" appears in the same SEEM where the __FILE__ instances appear.

[samr7]

As you can see in those SEEMs, its not just the __FILE__ instances. It also contains some other strings such as "Voice mail" "service" "roam", and others, and they appear in the same area and same order as they do in the BP. I suspect some pieces of BP code somehow leak to certain (unused?) SEEM addresses. Some SEEMs appear to be unmapped (thus causing a crash when you read them). Maybe some others are mapped to some random memory.

That's an interesting theory. The motokit SEEM dump function will certainly cause something in the phone to crash and reboot. But can you point to any one SEEM that reliably causes the crash when read from? There is always some last SEEM that it managed to read before the crash, and attempting to read this SEEM or its immediate successor does not appear to cause the same crash after the phone is rebooted. The point at which it crashes during a SEEM backup seems more like a function of where it started the backup. It is as if the crash occurs after a certain number of SEEMs have been read in rapid succession.

I'm still not convinced that any of the data that can be read by the SEEM backup resides outside CG2. It might be that the SEEMs represent some sort of patch data, some of which applies to the CG1 image. If this is the case, there would be some fixed table mapping SEEM IDs to the regions they apply to, and the presence of those strings is incidental due to somebody choosing to make a patch region too large.

If this is the case, it could be very interesting, especially if we can find some writable piece of code through which we could gain an entry point to the Neptune.

If you were to discover a security bug of this sort, it would be a great boon to those seeking to alter the native apps for a Neptune-only phone, but wouldn't mean as much for A780/E680.

[evaldas]

No luck. One of these bits did something GPS-related - it added the word "GPS" at the bottom of the status screen, below the transflash status. Wasn't clickable though.

Aside from that, nothing new. lapisrv still hangs and the dish is still crossed out.

Any other seems worth playing with ?

word "GPS" on the status screen is added by 3th 4th or 5th bit so it's very easy to test and find out which one of them enables this word and which one enables satellite icon.
btw mack, how do you access seem from linux? please post some code

[samr7]

btw mack, how do you access seem from linux? please post some code

I just noticed this too. Apparently Mack has discovered that /dev/mux13 is the AP's connection to the Neptune test command interface. This interface is common with other Neptune-only phones and is accessed by programs like PST/p2kman/moto4lin through a USB endpoint. With the A780, that USB endpoint appears to be served by the "ap_tcmd" program on the AP, which relays the commands through /dev/mux13, but rewrites them slightly along the way.

Mack probably knows a lot more about this subject and I'd be very curious to hear.

[mack]

btw mack, how do you access seem from linux? please post some code

Mack probably knows a lot more about this subject and I'd be very curious to hear.

hehe, actually, I don't know a lot more about it. I just straced ap_tcmd while doing some operations over USB-PST using moto4lin. I noticed that it does some rewriting before relaying the PST messages to the BP. For example, it adds some message-number field which is increased throughout the session. Anyway, I didn't bother decoding all of it. Just the messages for reading and writing a SEEM. In my code, you can see the message, and its easy to see where 0032 and 0001 are embedded in it. (two 16bits values).

You'll also find my code strange because it forks another process for reading the results. Its not because I'm crazy but because the driver is written without a buffer. When you send a command to BP through mux13, the result is written directly to the buffer of a waiting read(2). If none exist, the output is lost. I guess it was written with threads in mind.

Also attached is a tiny prog that diffs two seems and lists the different bits.

If someone has the time to write a more comprehensive tool that runs on the phone and edits seems using mux13, it would be quite useful.