ptrkrysik / gr-gsm

Gnuradio blocks and tools for receiving GSM transmissions
Other
1.34k stars 430 forks source link

Unable to decrypt voice traffic on TCH / F with multi-rate #465

Open desazhuk opened 5 years ago

desazhuk commented 5 years ago

Hello! I have a big problem. After decoding SDCCH8, I write this command to decode TCHF: grgsm_decode -a 74 -c 12345.cfile -t 7 -s 1000000 -m TCHF -e 1 -k '13E98A3979588727' --multi-rate = 209508238962 -o /home/abv/Desktop/speech.au.gsm

After running this command, a file is created with the name " speech.au.gsm", the size of which is 0 bytes, and the decoding process does not end.

That's what wireshark writes: GSM A-I/F DTAP - Assignment Command Protocol Discriminator: Radio Resources Management messages (6) DTAP Radio Resources Management Message Type: Assignment Command (0x2e) Channel Description 2 - Description of the First Channel, after time 0000 1... = TCH/F + FACCH/F and SACCH/F: 1 .... .111 = Timeslot: 7

  1. .... = Training Sequence: 1 ...0 .... = Hopping Channel: No ..10 .... = Spare: 0x02 Single channel ARFCN: 74 Power Command Channel Mode - Mode of the First Channel(Channel Set 1) MultiRate configuration Element ID: 0x03 Length: 6
  2. .... = Multirate speech version: Adaptive Multirate speech version 1 (1) ...0 .... = NSCB: Noise Suppression Control Bit: Noise Suppression can be used (default) (0) .... 0... = ICMI: Initial Codec Mode Indicator: The initial codec mode is defined by the implicit rule provided in 3GPP TS 05.09 (0) .... ..00 = Start Mode: 0 1... .... = 12,2 kbit/s codec rate: is part of the subset .0.. .... = 10,2 kbit/s codec rate: is not part of the subset ..0. .... = 7,95 kbit/s codec rate: is not part of the subset ...1 .... = 7,40 kbit/s codec rate: is part of the subset .... 0... = 6,70 kbit/s codec rate: is not part of the subset .... .1.. = 5,90 kbit/s codec rate: is part of the subset .... ..0. = 5,15 kbit/s codec rate: is not part of the subset .... ...1 = 4,75 kbit/s codec rate: is part of the subset ..00 1000 = AMR Threshold: 4.0 dB (8) 0010 .... = AMR Hysteresis: 1.0 dB (2) .... 0011 10.. .... = AMR Threshold: 7.0 dB (14) ..00 10.. = AMR Hysteresis: 1.0 dB (2) .... ..01 0110 .... = AMR Threshold: 11.0 dB (22) .... 0010 = AMR Hysteresis: 1.0 dB (2)

Please, tell me the method of decoding TCH / F with Multiratе

I send you the recorded session in the format .pcapng pseudovoice.zip wireshark

arifkyi commented 5 years ago

Hello Desazhuk, allow me to run your command file in my own Ubuntu simulation, do you attach as well the cfile file? the 12345.cfile ?

desazhuk commented 5 years ago

@arifkyi Hello! I will be glad to any help Link to the command file "12345":https://drive.google.com/open?id=1VMv4h7X4S4QlyYvJVCVUhDq3sKMU9pVu

arifkyi commented 5 years ago

Hello @desazhuk ,

i looked already your cfile, and pseudo pcap as well. i tried to decode and yield same result like you, these are my hypothesis :

  1. from system information Type 1 (in BCCH level) it said in 'Channel Descriptions' it seem this is Hoping channel, you need to channelize it first, or maybe you already done it?

GSM CCCH - System Information Type 1 L2 Pseudo Length 0101 01.. = L2 Pseudo Length value: 21 .... 0110 = Protocol discriminator: Radio Resources Management messages (0x6) .... 0110 = Protocol discriminator: Radio Resources Management messages (0x6) 0000 .... = Skip Indicator: No indication of selected PLMN (0) Message Type: System Information Type 1 Cell Channel Description 00.. 000. = Format Identifier: bit map 0 (0x00) List of ARFCNs = 94 74 64 59 RACH Control Parameters SI 1 Rest Octets

you may need to run the script grgsm_channelize in advance, you can see the details in here

  1. make sure you stop the capture once after you disconnect all the calls, because i don't see any 'Release' argument , even i do not see the 'Connect Acknowlege' as well in call control level ( i saw this in your pseudovoice)

br, rifky

desazhuk commented 5 years ago

@arifkyi Good Afternoon! Thank you for helping me. It is possible that the previous time the problem was as follows: when the call was made, my phone was on ARFCN 94, but then it switched to ARFCN 99. This is confirmed by the fact that when the call was completed, the phone showed that it was on ARFCN 99. I recorded a two new calls and captured them. TMSI: 96FE2271; Kc: C56B350F1907FA28 Link to the new command file "1": https://drive.google.com/open?id=19LyozutqcQh6THPvkgrtw9EGiNxvc--3 Link to the new command file "2":https://drive.google.com/open?id=18xH0nVI2P6tc_lOe8qk8o7d-y45FDFcP

velichkov commented 5 years ago

Hi @desazhuk,

grgsm_decode -a 74 -c 12345.cfile -t 7 -s 1000000 -m TCHF -e 1 -k '13E98A3979588727' --multi-rate = 209508238962 -o /home/abv/Desktop/speech.au.gsm

After running this command, a file is created with the name " speech.au.gsm", the size of which is 0 bytes,

Currently the AMR MultiRate encoding is not supported for TCHF channels only for TCHH and that's why you get an empty voice file.

and the decoding process does not end.

This is a known issue in gnuradio, see https://github.com/ptrkrysik/gr-gsm/issues/450 and https://github.com/ptrkrysik/gr-gsm/issues/422#issuecomment-407479813

That's what wireshark writes: GSM A-I/F DTAP - Assignment Command Protocol Discriminator: Radio Resources Management messages (6) DTAP Radio Resources Management Message Type: Assignment Command (0x2e) Channel Description 2 - Description of the First Channel, after time 0000 1... = TCH/F + FACCH/F and SACCH/F: 1 .... .111 = Timeslot: 7

  1. .... = Training Sequence: 1 ...0 .... = Hopping Channel: No ..10 .... = Spare: 0x02 Single channel ARFCN: 74 Power Command Channel Mode - Mode of the First Channel(Channel Set 1) MultiRate configuration Element ID: 0x03 Length: 6
  2. .... = Multirate speech version: Adaptive Multirate speech version 1 (1) ...0 .... = NSCB: Noise Suppression Control Bit: Noise Suppression can be used (default) (0) .... 0... = ICMI: Initial Codec Mode Indicator: The initial codec mode is defined by the implicit rule provided in 3GPP TS 05.09 (0) .... ..00 = Start Mode: 0 1... .... = 12,2 kbit/s codec rate: is part of the subset .0.. .... = 10,2 kbit/s codec rate: is not part of the subset ..0. .... = 7,95 kbit/s codec rate: is not part of the subset ...1 .... = 7,40 kbit/s codec rate: is part of the subset .... 0... = 6,70 kbit/s codec rate: is not part of the subset .... .1.. = 5,90 kbit/s codec rate: is part of the subset .... ..0. = 5,15 kbit/s codec rate: is not part of the subset .... ...1 = 4,75 kbit/s codec rate: is part of the subset ..00 1000 = AMR Threshold: 4.0 dB (8) 0010 .... = AMR Hysteresis: 1.0 dB (2) .... 0011 10.. .... = AMR Threshold: 7.0 dB (14) ..00 10.. = AMR Hysteresis: 1.0 dB (2) .... ..01 0110 .... = AMR Threshold: 11.0 dB (22) .... 0010 = AMR Hysteresis: 1.0 dB (2)

Please, tell me the method of decoding TCH / F with Multiratе

If you are C/C++ programmer you could try to migrate the TCHF decoder block (lib/decoding/tch_f_decoder_impl.cc) to libosmocore similar to the TCHH decoder block (lib/decoding/tch_h_decoder_impl.cc) as it currently uses a code from the OpenBTS project (lib/decoding/openbts/) that does not support MultiRate and generally is not well supported.

@arifkyi Good Afternoon! Thank you for helping me. It is possible that the previous time the problem was as follows: when the call was made, my phone was on ARFCN 94, but then it switched to ARFCN 99. This is confirmed by the fact that when the call was completed, the phone showed that it was on ARFCN 99.

I doubt that as 12345.cfile was captured on ARFCN 74 and in the Assignment Command the ARFCN is also 74 as could be seen on your screenshot so the call at least started on ARFCN and you should be able to get the first few call control messages and hopefully some voice.

I recorded a two new calls and captured them. TMSI: 96FE2271; Kc: C56B350F1907FA28 Link to the new command file "1": https://drive.google.com/open?id=19LyozutqcQh6THPvkgrtw9EGiNxvc--3 Link to the new command file "2":https://drive.google.com/open?id=18xH0nVI2P6tc_lOe8qk8o7d-y45FDFcP

These two files are unusable as in both cases you were assigned a TCHF channel on a different ARFCN 82 then the one you were capturing on (99) and because you were capturing with sample rate 1e6 these files do not contain ARFCN 82.

GSM A-I/F DTAP - Assignment Command
    Protocol Discriminator: Radio Resources Management messages (6)
    DTAP Radio Resources Management Message Type: Assignment Command (0x2e)
    Channel Description 2 - Description of the First Channel, after time
        0000 1... = TCH/F + FACCH/F and SACCH/F: 1
        .... .100 = Timeslot: 4
        010. .... = Training Sequence: 2
        ...0 .... = Hopping Channel: No
        ..00 .... = Spare: 0x00
        Single channel ARFCN: 82

@arifkyi,

1. from system information Type 1 (in BCCH level) it said in 'Channel Descriptions'  it seem this is Hoping channel,  you need to channelize it first, or maybe you already done it?

I'm not quite sure what exactly specifies the Channel Descriptions parameter in the System Information Type 1 message but for sure he don't get assigned a hopping channel as could be seen in the Assignment Command message.

1. make sure you stop the capture once after you disconnect all the calls, because i don't see any 'Release' argument , even i do not see the 'Connect Acknowlege' as well in call control level ( i saw this in your pseudovoice)

There is no Connect Acknowledge in the pseudovoice.pcapng file.

In my opinion it is more important to capture the begging of the call because of the Assignment Command and possibility to get reassigned on a different ARFCN then the end of the call.