Error: grgsm_decode decodes both encrypted and un-encrypted message, without Kc provided

[Manh Nguyen]

I am learning decode cfile according to Crazy Danish Hacker's videos (GSM Sniffing: Voice Decryption 101 - Software Defined Radio Series #11 https://www.youtube.com/watch?v=krJJKjYdwgc&index=9&list=PLRovDyowOn5F_TFotx0n8A79ToZYD2lOv), and my grgsm does not work as the same as in the video.

In his video, grgsm_decode decodes vf_call6_a725_d174_g5_Kc1EF00BAB3BAC7002.cfile (https://github.com/ptrkrysik/test_data/blob/master/vf_call6_a725_d174_g5_Kc1EF00BAB3BAC7002.cfile) as following:

grgsm_decode -c vf_call6_a725_d174_g5_Kc1EF00BAB3BAC7002.cfile -a 725 -s $((100000000/174)) -m SDCCH8 -t 1

and gets the following result: 

As in the picture, you can see 4 packages, and last package is Ciphering Mode Command. It means that all the encrypted packages afterwards are discarded by grgsm_decode.

But when i do the same, my grgsm_decode all packages  including encrypted ones:

That's weird. The problem is more severe when i decode with the Kc:

grgsm_decode -c vf_call6_a725_d174_g5_Kc1EF00BAB3BAC7002.cfile -a 725 -s $((100000000/174)) -m SDCCH8 -t 1 -k 0x1E,0xF0,0x0B,0xAB,0x3B,0xAC,0x70,0x02

The number of packages is 24, meaning that 12 packages are decoded without Kc and 12 left ones are decoded with Kc.

I installed the master branch version of grgsm on Ubuntu 16.04 with PyBombs. Please help me to correct the problems.

Sincerely,

Manh

[Manh Nguyen]

I figure out that the parity_check has been removed from control_channels_decoder_impl::decode: https://github.com/ptrkrysik/gr-gsm/commit/b516e6dcdb758d0b8ba513dbfe812d6e1ed4a0e5#diff-77849ea7595b388114118e8bb0095423

Should it be a bug?

[Vasil Velichkov]

Hi Manh,

On Thursday, March 22, 2018 at 2:58:37 PM UTC+2, Manh Nguyen wrote:

I figure out that the parity_check has been removed from control_channels_decoder_impl::decode: https://github.com/ptrkrysik/gr-gsm/commit/b516e6dcdb758d0b8ba513dbfe812d6e1ed4a0e5#diff-77849ea7595b388114118e8bb0095423

Should it be a bug?

Yes it looks like a bug, thanks for reporting it.

I was able to reproduce it using the current master (c097ce7) but I don't think it was introduced in b516e6d because the last tag v0.41.2 (4bb3acd) contains b516e6d and it is working with it so the regression is after v0.41.2.

It also works with c0621c6 but after this commit I have problems running it at all, it just fails with
    ImportError: /usr/local/lib64/libgrgsm-0.41.3.so.0.0.0: undefined symbol: gsm660_bitorder

and I'm still trying to figure out why.

[Vasil Velichkov]

Hi Manh,

On Thursday, March 22, 2018 at 8:15:17 PM UTC+2, Vasil Velichkov wrote:

I was able to reproduce it using the current master (c097ce7) but I don't think it was introduced in b516e6d because the last tag v0.41.2 (4bb3acd) contains b516e6d and it is working with it so the regression is after v0.41.2.

Unfortunately I'm no longer able to reproduce the decrypt problem no matter which version I try, it seems there is some random behavior.

Could you share your pcap files?

Note that there is a bug in recent Wireshark versions https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14105 so to correctly decode SACCH/SDCCH you need to use version 2.2.6 or older

[Vasil Velichkov]

Hi again

On Monday, March 26, 2018 at 9:22:47 PM UTC+3, Vasil Velichkov wrote:

it seems there is some random behavior.

One possible source of randomness is the frequency offset correction loop

From https://groups.google.com/d/msg/gr-gsm/gve4CcJubgw/3l_xZAr9AAAJ

> It can happen if you use frequency offset correction loop in gr-gsm.
> Messages that control correction are currently asynchronous so timing of
> correction isn't currently deterministic. You can disable frequency
> correction loop if you have device that doesn't require it. For
> grgsm_decode you do this by not giving carrier frequency parameter.

Could you try the following command

  grgsm_decode -c ./vf_call6_a725_d174_g5_Kc1EF00BAB3BAC7002.cfile  -s $((100000000/174)) -m SDCCH8 -t 1 -k 0x1E,0xF0,0x0B,0xAB,0x3B,0xAC,0x70,0x02 -v --ppm -10 | grep "13 05 1e 02 ea 81 5c 08 11 83 94 03 98 93 92 49 81"

The expected result is

> 862363 1331349:  03 42 45 13 05 1e 02 ea 81 5c 08 11 83 94 03 98 93 92 49 81 2b 2b 2b

[Vasil Velichkov]

Hi Manh,

On Thursday, March 22, 2018 at 12:06:14 PM UTC+2, Manh Nguyen wrote:

But when i do the same, my grgsm_decode all packages  including encrypted ones:

That's weird. The problem is more severe when i decode with the Kc:

grgsm_decode -c vf_call6_a725_d174_g5_Kc1EF00BAB3BAC7002.cfile -a 725 -s $((100000000/174)) -m SDCCH8 -t 1 -k 0x1E,0xF0,0x0B,0xAB,0x3B,0xAC,0x70,0x02

The number of packages is 24, meaning that 12 packages are decoded without Kc and 12 left ones are decoded with Kc.

I just pushed a fix to my fork and opened a pull request 387. Could you test it?

[Manh Nguyen]

I reinstalled grgsm using version 4bb3acd and was able to reproduce the problem. I followed "manual compilation and installation" guide:

   + Installing dependencies with apt-get

   + Downloading grgsm v0.41.2 https://github.com/ptrkrysik/gr-gsm/tree/v0.41.2 and using cmake, make, make install, ldconfig

   + Gnuradio-companion version: 3.7.9

   + Ubuntu version: Ubuntu 16.04.4 LTS

   + Wireshark version: 2.2.6

Command I used: grgsm_decode -c vf_call6_a725_d174_g5_Kc1EF00BAB3BAC7002.cfile -a 725 -s $((100000000/174)) -m SDCCH8 -t 1

And I included the pcap file in case you want to analyze it.

Cfile link: https://drive.google.com/open?id=1g_cT-zKo3Q5AQIBscPfuAsElqehlczms

And with your commit 11bf44ac8e94052173b892fc3e5814ec2eb9e337, I installed it and everything works well. Thank you so much.

Vào 01:15:17 UTC+7 Thứ Sáu, ngày 23 tháng 3 năm 2018, Vasil Velichkov đã viết:

[Piotr Krysik]

W dniu 27.03.2018 o 02:11, Vasil Velichkov pisze:

> <https://github.com/ptrkrysik/gr-gsm/pull/387/commits/11bf44ac8e94052173b892fc3e5814ec2eb9e337>

> and opened a pull request 387.

> <https://github.com/ptrkrysik/gr-gsm/pull/387>Could you test it?
>
Hi guys,

I'm just starting to dig through the whole backlog of unread e-mails and
gr-gsm's issues.

Yes, not checking the return value was a bug. Many thanks Vasil for
fixing it.

--
Best Regards,
Piotr Krysik