[A51] Next Encrypted SI 5 - Timing Advance - FPC

Basse Ang b4ss3k at gmail.com
Mon Apr 18 08:25:18 CEST 2016


hi All.. this conversation had been continued before.. hopefully it will
help others.. big thanks for great helpful explanation by Vadim..  :D

----------------------------------------------------------------------------------

Hello, Basse!

> Why we need to brute force the range of TA and MS power
> level, whereas we could actually get this value.. in case
> using wireshark, in SI5 packet, you could directly see its value.

Yes, we can see TA and MS power level for unencrypted packets, but
not after Cyphering Mode Command. Sometimes, if MS is very far from
BTS, these params may be changed in some range during dedicated
connection. So, as I previously said, we don't know which values
this params has after enabled encryption. Therefore we need to brute
some range of changing values. You can use gsmframecoder to prepare
some variants of SI packets with possible TA and MS power values.

> if you did not use gsmframecoder, so did you XOR directly the
> encrypted SI5 with its un-encrypted SI5? if you look into my
> attachment, it mean you XOR FN 200 with 404 and so on. is not it?

I wrote a small C-code which analyzes a dump with bursts and do all
the dirty work while I am drinking a coffee. :)
Firs of all this program finds the plain SI packets and saves them
to the buffer. Then, when it received the Cyphering Mode Command,
every new encrypted SI packed will be XORed with previously saved
plain SI packet because we don't know exactly which type of SI this
packet has (SI5, SI5ter, SI6). I am still not implemented TA and MS
power level range brute force due to lack of free time.

Looking at your scheme I have few questions:

1) What for do you use gsmframecoder in the left side of scheme?
I think this tool can be useful for you when you will try to guess
a set of TA and MS power level values for encrypted packet manually.
But it's better to write a program than doing it yourself in future.

2) What for you XOR the first four bursts in the bottom?

B1 XOR FN 200
B2 XOR FN 201
B3 XOR FN 202
B4 XOR FN 203

The result of XORing the same bursts will be a sequence of nulls.
Read about XOR and cryptography basics. In GSM every encrypted burst
a result of following operation (some things was simplified for
better understanding, used OsmocomBB code part):

uint32_t *a5_encrypt(uint32_t burst[114], uint32_t fn, uint8_t kc[8])
{
    ubit_t keystream[114]; // This is exactly what we are looking for
    int dch_ciph = 1;      // A5/1 cipher indication

    osmo_a5(dch_ciph, kc, fn, keystream);
    for (i = 0; i < 114; i++) burst[i] ^= keystream[i];

    return burst;
}

The XOR operation has an interesting feature:
a XOR b = c
a XOR c = b

Using this feature we can recover a keystream which Kraken can crack:
plaintext_burst XOR cyphertext_burst = keystream

> in XOR step, if gsmframecoder is not used, what kind of burst that
> should XOR with encrypted SI5? *in case timing advance is "0"

You should XOR encrypted SI with unencrypted SI assuming the last
have the same values for changing params we talking about. If there
will no results from Kraken, try to change TA and/or MS power level
in plain SI packet, encode it using gsmframecoder and XOR with
encrypted packet again.

> in case of we already know that timing advance is 1, MS level is 5
> for example.. the question is same, what kind of burst that should
> XOR with kind of encrypted SI5? or actually in whole process we
> dont need gsmframecoder? which is in my last case, the output of
> this step was used to next step.. or, then what is the alternative,
> like what you did, even you did not used gsmframecoder..

See my explainations above and keep in mind that those params can be
changed several times during transmission.

I hope it will help you. And it would be better if you'll CC your
mails to the mailing lists, it can be helpful for others.

Have a nice day! ;)

С наилучшими пожеланиями,
Яницкий Вадим.

2016-04-15 12:56 GMT+06:00 Basse Ang <b4ss3k at gmail.com>:

> seems I should re-questioning myself..
>
> - in XOR step, if gsmframecoder is not used, what kind of burst
> that should XOR with encrypted SI5? *in case timing advance is "0"
>
> - in case of we already know that timing advance is 1, MS level is 5 for
> example.. the question is same,  what kind of burst that should XOR with
> kind of encrypted SI5? or actually in whole process we dont need
> gsmframecoder? which is in my last case, the output of this step was used
> to next step.. or, then what is the alternative, like what you did, even
> you did not used gsmframecoder..
>
> Vadim, please make correction of what I understand here if you think thats
> mine is wrong.. seem there are step that I still missing. and again, I
> apologize for such probably rushing you with my question..
>
>
>
> On Fri, Apr 15, 2016 at 1:43 PM, Basse Ang <b4ss3k at gmail.com> wrote:
>
>> thank you for your information..
>>
>> 1) I think this guide will help you (a great Sylvain's explanations):
>>> https://lists.srlabs.de/pipermail/a51/2010-July/000804.html
>>>
>>> vadim, since take a look at that Sylvain's explanation.. I want to
>> confirm several things here..
>>
>>
>>
>>> Some networks broadcast SI packets in random sequence and also the
>>> Ciphering Mode Command
>>> is now always sent after constant count of frames. So, this method can
>>> be useless for you.
>>>
>>> You can use a frame number to guess if this burst is related to SI5,
>>> SI5ter of SI6.
>>> Also if you are use OsmocomBB, try to use this condition:
>>> if (burst->flags & BI_FLG_SACCH) { ... }
>>>
>>> SI5 is not the only message type you can use to find keystream. There
>>> are also SI5ter,
>>> SI6 and the "LAPDm U func=UI" packets. The last one is more difficult to
>>> guess.
>>>
>>>
>> So far, Actually, I still did it manually,  so recognizing SI5, SI5ter,
>> SI6 easier using wireshark and got the frame number also using wireshark.
>> just need to understand how exactly it works first. Later on, implementing
>> in coding if after all PoC already completed, hopefully. Needed to mention,
>> I did not do it in real time but I already have some cfile (recorded using
>> USRP), in these cfiles I work on.
>>
>>
>> 2) I've never used the gsmframecoder. All I know is that Timing Advance
>>> is not
>>> the only changing value. There is also MS Power Level, and it can be
>>> changed
>>> (sometimes often) during transmission too. Both of these parameters
>>> negatively affect
>>> the cracking success, i.e if at least one of them will be changed, the
>>> Kraken will find
>>> nothing or even give you some false positive results.
>>>
>>> Last PoC I have done and successfully get its Kc, was using cfile that
>> srlabs provided (vf_call6_a725...cfile). With gsmframecoder I got 4 burst,
>> it was needed because the Timing Advance is active (said by the sheet).
>> These 4 burst (output of gsmframecoder) then XOR with next encrypted SI5
>> (add with 204 from open SI 5, or 102 refer to what I got). I attached the
>> whole process of my last PoC.
>>
>>
>>> I think there is a way to solve this problem. We can try to brute force
>>> some range
>>> of possible values for TA and MS Power Level. This way we should prepare
>>> a couple
>>> of modified SI packets (4 bursts each) using the one original. And then
>>> we will be
>>> able to XOR every supposed encrypted SI packet with each prepared
>>> plaintext packet.
>>>
>>>
>> Why we need to brute force the range of TA and MS power level, whereas we
>> could actually get this value.. *in case using wireshark, in SI5 packet,
>> you could directly see its value.
>>
>> if you did not use gsmframecoder, so did you XOR directly the encrypted
>> SI5 with its un-encrypted SI5? if you look into my attachment, it mean you
>> XOR FN 200 with 404 and so on. is not it?
>>
>
On Tue, Apr 12, 2016 at 2:29 PM, Вадим Яницкий <axilirator at gmail.com> wrote:

> 1) I think this guide will help you (a great Sylvain's explanations):
> https://lists.srlabs.de/pipermail/a51/2010-July/000804.html
>
> Some networks broadcast SI packets in random sequence and also the
> Ciphering Mode Command
> is now always sent after constant count of frames. So, this method can be
> useless for you.
>
> You can use a frame number to guess if this burst is related to SI5,
> SI5ter of SI6.
> Also if you are use OsmocomBB, try to use this condition:
> if (burst->flags & BI_FLG_SACCH) { ... }
>
> SI5 is not the only message type you can use to find keystream. There are
> also SI5ter,
> SI6 and the "LAPDm U func=UI" packets. The last one is more difficult to
> guess.
>
> 2) I've never used the gsmframecoder. All I know is that Timing Advance is
> not
> the only changing value. There is also MS Power Level, and it can be
> changed
> (sometimes often) during transmission too. Both of these parameters
> negatively affect
> the cracking success, i.e if at least one of them will be changed, the
> Kraken will find
> nothing or even give you some false positive results.
>
> I think there is a way to solve this problem. We can try to brute force
> some range
> of possible values for TA and MS Power Level. This way we should prepare a
> couple
> of modified SI packets (4 bursts each) using the one original. And then we
> will be
> able to XOR every supposed encrypted SI packet with each prepared
> plaintext packet.
>
> С наилучшими пожеланиями,
> Яницкий Вадим.
>
> _______________________________________________
> A51 mailing list
> A51 at lists.srlabs.de
> https://lists.srlabs.de/cgi-bin/mailman/listinfo/a51
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.srlabs.de/pipermail/a51/attachments/20160418/047f78d7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: my PoC success.png
Type: image/png
Size: 19519 bytes
Desc: not available
URL: <http://lists.srlabs.de/pipermail/a51/attachments/20160418/047f78d7/attachment.png>


More information about the A51 mailing list