[Catchercatcher] Status flag/parameter specifications

Luca Melette luca at srlabs.de
Thu Jan 19 04:20:23 CET 2012

On Sun, 15 Jan 2012 19:49:59 +0200
Emanuel VonAnkh <vonankh at gmail.com> wrote:

I think I found the time to answer this post.

> 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.

> 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.

> S2/3: If I have understood the ciphermode/attachment procedure right,
> 	then it is the MS that sends ciphermode complete
> (CIPH_MOD_COM) message, after it has received the Set Cipher Mode
> Command (CIPH_MOD_CMD).
> http://www.gsmfordummies.com/gsmevents/attach.shtml 
> 	Question 3a:  Why do you care about how many times the
> handset sends, instead of how many times it receives the request?

I add also this question
> S4: 	This is not clear, it just doesn't make sense.
> 	Question 3b:  Where does it say that the IMEI should also be
> transferred (in this response)?

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.
> 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.

> L4: 	I read somewhere that the network always should query the
> IMEI after location update, i.e. its standard.

I don't know where... probably you mean IMSI.
> 	Question 3c:  Did I miss something? And if I did miss
> something, how would this query fit in with normal operation
> procedures?

IMEI should not be asked more than once, at first loc.upd.
However, this is just to mark a "suspect" behaviour.

> 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.

> 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.
We need some real IMSI catcher to see what happens :)

> L7: 	Ok, but:
> 	Question 3f:
> 	a) What is the SMS class enumeration (TS 23.038) for this?
> 	(CLASS_1, CLASS_2 or something else?)

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.
> L8:  	Question 3g:  If you by "paging" mean the (MT) RR Paging
> Request, this should also be a timing "flag", right?
> L9/10:   Please elaborate!
> L11/12: Please elaborate!

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.

> 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?)

Each flag indicates a suspect, with a color, but also with a "text",
that you have been caught by an IMSI catcher.
Of course, some are just suspects, some are quite clear proofs.

> 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!



More information about the Catchercatcher mailing list