[Catchercatcher] Status flag/parameter specifications

Emanuel VonAnkh vonankh at gmail.com
Fri Jan 20 03:09:23 CET 2012


Thanks for the time and effort in trying to answer these questions.

However, regardless of the this effort, there is unfortunately little
of practical use in most of your answers. That is, as the status is
right now, there is not enough details in the provided information to
be able to make it into something useful.


> I think I found the time to answer this post.

This is obviously much appreciated.


>> 1. How is the "status flag: X" calculated from the other parameters
>> (directly above it)?
>
> The "flag" is internally a status variable, updated every time
> some event occurs (cell change, new link established, etc)
> Probably you cannot put probes everywhere with android as
> I do in Osmocom, and maybe you also need polling.

a) Right, but can you specify the criteria for when/how it is updated.
b) Correct, I can't as long as I don't have direct application access
    to the Modem, which is not impossible...


>> 2. How does this output correlate to the various S/L detection
>> parameters?
>
> They are quite not correlated, for every line there is a match,
> and if positive, the flag is switched accordingly to the worst case.

This is the point of all my questions. When is a flag a worst case (or not)?


> The point is, you need a known plaintext to attack the key.
> A common issue is that the response of ciphering mode command,
> is totally predictable... except if the network ask the user
> to add its own ID, that should not be visible in cleartext.
> The "many times" argument is important.
> The real network know the right key, so the cipher mode complete
> is almost never retransmitted, as the message is correctly decrypted.
> If you don't give an ack to the mobile, it keeps sending the cipher
> mode complete, allowing an attacker to get more and more known data.

a) Interesting, is this a general behavior of mobile phones or just OBB ones?
    (Sound more like a bug?)
b) Currently, I don't have the faintest idea on how to implement this check
    on Android...


>> L1/2: This is okay, but need improvement: Your MS better be still,
>> because just waving my MS around I can get it to change LAC.
>
> I'm trying to see where to put it, there are many point where
> the mobile tries to select a new cell, without sending any data.

I have some ideas around this... PM if interested.


>> L5:   Question 3d:  What do you mean with "registration timer"?
> There is a timer called T3212, transmitted in System Information 3,
> that specifies the maximum time between two location updates.

"SI3" is too cryptic. Where can I find the spec's for this?
Would you have any ideas how to read this with an ATC?
(Or some other method?)


>> L6:   Since when an MS is switched on in a new LAC, it sends an
>> "IMSI Attach" request, which is cancelled after receiving the MS
>> acknowledgment message.
>> Question 3e:  Shouldn't this rather be a timing limit, and
>> not a flag?
>
> I have to see this, the idea is that the BTS force the mobile to
> transmit the IMSI as the periodic location update is not accepted.

It seem like two things going here:
a) MS (IMSI attach) ACK is never received because of i) timeout or ii)
just being ignored
b) what you say.

> We need some real IMSI catcher to see what happens :)

Just fire up you catcher phone at any "Occupy
<insert_favorite_dictatorship_capital_main_square_here>" event.


> The TP-DCS is set to 0xC0, definition in GSM/3GPP 3.40
>>  b) How is this checked? In what layer/sublayer?
>
> As said, the field DCS is checked, this should be available also
> at high level, if you can read the SMS as PDU.

It is, but documentation on TP-DCS bits 4-7 is really crap!
I guess that's how they have managed to hide this functionality
for so long.


> As from L8 on, we want to measure some time and then decide.
> Currently, the timer is firstly started after the immediate
> assignment, and restarted after the first valid message received.
> This goes further on, until a CC or SMS message is received.
> Some timer probes can be moved in Osmocom code, I didn't check
> where is the best point to measure.

Any hints where to look for (or where to implement) timer probes for
an AT controlled modem?
(Or in the RIL if that's available ?)



>> Question 4:  It would also be of help to know which of these you
>> consider more important? (How do you arrive at giving the parameters a
>> particular flag color?)
>> Question 5:  Could someone please better describe and elaborate on the
>> "show catcher" output?
>
> Mainly for expert users, except for the flag.
> This is going to change, as we discover new evidence, or decide to
> ignore some previously monitored condition.
>
> This is still very "on progress", so please ask and contribute!


Well, I though this list was for "expert" users! With this answer
it is hard to contribute and develop anything...

At this point I already feel that "You" (CatcherCatcher) are reluctant
to answer because of either:
a) You have a very busy day2day life with many other projects etc etc.
b) You are planning to publish something soon, about this on your own.
c) You just don't know and/or too lazy to find out/answer.
d) think these are annoying newbie questions.

My answers to these are:
a)   If you're too busy, you need more people involved and to provide those
      people with more specific answers, to get them more productive.
b,c)  that is ok! Just say so.
d)   Then don't ask people to contribute...


More information about the Catchercatcher mailing list