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! ;)
С МаОлÑÑÑОЌО пПжелаМОÑЌО,
ЯМОÑкОй ÐаЎОЌ.
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..
thank you for your information..
Post by Ðадим ЯниÑкий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..
Post by Ðадим ЯниÑкий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.
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
Post by Ðадим ЯниÑкий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.
Post by Ðадим ЯниÑкий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?
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.
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
https://lists.srlabs.de/cgi-bin/mailman/listinfo/a51