[Gsmmap] snoopsnitch Logging filters

E:V:A xdae3v3a at gmail.com
Thu Mar 5 11:31:18 CET 2015


Hi Luca,

Thanks for your prompt reply and sorry for my delayed one.

On Wed, Feb 25, 2015 at 2:22 AM, Luca Melette <xxx> wrote:
> 1)
> What you see in that file is what we could sniff on the USB cable,
> after enabling the interesting debug features on the mobile.
> I don't know exactly what these commands do, I just see some long
> initialization vectors for the debug subsystem, all generated by
> Qualcomm tools. I wouldn't edit this file anyway, it works :)

Aha, so you (or someone):
1. Enabled QXDM debugging on device, then connected and
2. used QXDM to edit and export the baseband filters.
3. Then sniffed USB to see what was sent.

Great, that's what I thought, but knowing and documenting
the actual protocols would be far more useful for reducing
the amount of info getting dumped from there. For example,
the (now useless) ciphering info could be filtered for to enable
the ciphering info to be used for a small indicator app.


> 2)
> diag_import (and the library behind it) fetches the output of dev/diag
> and does some filtering on the message types (reverse engineered).
> We receive many messages from the baseband, but we discard most of
> them and focus only on the ones that contain radio payloads.

It is in fact this filtering that is interesting. The format of the diag
messages from /dev/diag is far from obvious, and understanding
the structure of these would be extremely useful. Because it
looks as it is not only GSMTAP messages baked in there, but
a bunch of other things. So how is that filtering done? Would it
be possible to use your library to get the output in a more friendly
output that can be used for other types of inspection. The libraries
you require seem to be rather huge, so I assume the RE you
mention was generalized and not specific for Qualcomm?


> 3)
> I'm not the right person to talk about Android, but I know that the
> OEM_HOOK_RAW was reliable for us.

I think you meant "valuable"?

It seem as though the XMM based phones are using the same RF
tools as QC ones, and thus the problem might be purely interface
and not messaging. Look at the similarity of Samsung IPCv4 and
how raw QMI is used... So if we could find and sort this out, we
could support a far wider range of devices.

Many thanks again.
Cheers,
E:V:A


On Wed, Feb 25, 2015 at 2:22 AM, Luca Melette <xxx> wrote:
>> To that end, it would be very helpful if someone could better explain
>> the contents of the filtering mechanism. In particular the meaning and
>> use of the hex strings in the file:
>>
>> /SnoopSnitch/src/de/srlabs/snoopsnitch/qdmon/SetupLoggingCmds.java
>>
>> 1) Are they QMI sub-service commands, just filters or something else?
>> 2) What is the relationship of this file to the binary helpers
>> diag_import.c and diag-helper.c
>> 3) I think we might be able to extend some of this to the XMM BPs, via
>> OEM_HOOK_RAW as the format is very similar... Any thoughts on this?
>
> 1)
> What you see in that file is what we could sniff on the USB cable,
> after enabling the interesting debug features on the mobile.
> I don't know exactly what these commands do, I just see some long
> initialization vectors for the debug subsystem, all generated by
> Qualcomm tools. I wouldn't edit this file anyway, it works :)
>
> 2)
> diag_import (and the library behind it) fetches the output of dev/diag
> and does some filtering on the message types (reverse engineered).
> We receive many messages from the baseband, but we discard most of
> them and focus only on the ones that contain radio payloads.
>
> 3)
> I'm not the right person to talk about Android, but I know that the
> OEM_HOOK_RAW was reliable for us.
>
> Cheers,
>
> LM
> _______________________________________________
> Gsmmap mailing list
> Gsmmap at lists.srlabs.de
> https://lists.srlabs.de/cgi-bin/mailman/listinfo/gsmmap



More information about the Gsmmap mailing list