Airprobe-like bursts

[robert....@gmail.com]

Hi, is there a way to get the bursts of a certain timeslot as can be done using airprobe (C1 and C0 bursts)?
ex:
C1 1015026 1567500:100000010001110101010000000010100000000111111101010000001010000100010111010100000000101000010000010101010100000010
P1 1015026 1567500: 100000010001110101010000000010100000000111111101010000001010000100010111010100000000101000010000010101010100000010
S1 1015026 1567500: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
C0 1015027 1567533:101010111111111101000000101010101111111111110100000000100010111111111111010101000000001010101011011101010000001000
P0 1015027 1567533: 101010111111111101000000101010101111111111110100000000100010111111111111010101000000001010101011011101010000001000
S0 1015027 1567533: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
C0 1015028 1567566:000000011111010101010000100000010001010111010101000010100001010001111101010001000010000000000101110101010100000010
P0 1015028 1567566: 000000011111010101010000100000010001010111010101000010100001010001111101010001000010000000000101110101010100000010
S0 1015028 1567566: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
C0 1015029 1567599:000100001010101010111101110101010000000010101110111111010100010000001010101011011101010001000010001011101111010101
P0 1015029 1567599: 000100001010101010111101110101010000000010101110111111010100010000001010101011011101010001000010001011101111010101
S0 1015029 1567599: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
1015029 5: 03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b

[Piotr Krysik]

W dniu 08.07.2015 o 11:54, robert....@gmail.com pisze:

Hi,

Similar task is currently done by two blocks:
burst_sink and message_printer.

It is possible to implement such output by implementing new block that
would accept bursts and messages or by modification of existing blocks.
If you want you can do it with my guidance.

I wasn't author of this change in gsm-receiver and I haven't ever used
such output. What is exact meaning of beginning of each line like:

C1 1015026 1567500: ...

?

--
Best Regards,
Piotr Krysik

[robert....@gmail.com]

Hi, 

the block burst_sink gives a .bin output file which cannot be read as a text file, also the blocks Message_printer and Bursts_printer  give bursts that are larger than the ones obtained in airprobe (gsm_receive.py).

Regarding the first two numbers at the beginning of each line, the first number if the frame number and the second number is the modified frame number which is required by the A5/1 algorithm. These are used to obtain your KC key in order to decrypt your SMS. 

[Piotr Krysik]

W dniu 08.07.2015 o 13:48, robert....@gmail.com pisze:

It was my mistake - it supposed to be bursts_printer not burst_sink.
These blocks print bursts and messages. What you need is to print bursts
in different format than bursts_printer does it now + take bursts before
and after decrytpion. The bursts_printer is the best block to start with.

Best Regards,
Piotr Krysik

[Piotr Krysik]

W dniu 08.07.2015 o 13:48, robert....@gmail.com pisze:
>

> Regarding the first two numbers at the beginning of each line, the
> first number if the frame number and the second number is the modified
> frame number which is required by the A5/1 algorithm. These are used
> to obtain your KC key in order to decrypt your SMS.

Ok, so you need only encrypted bursts (lines starting with C...). Then
what is required is only slightly modified bursts_printer.

[robert....@gmail.com]

The Bursts_printer block seems to give a fixed series of bits (26 bits) at the middle of each burst, it is the same for all the bursts. How should it be modified ?

[roman khassraf]

The Bursts_printer block seems to give a fixed series of bits (26 bits) at the middle of each burst, it is the same for all the bursts. How should it be modified ?

Yes, because the burst printer prints the whole burst, but airprobe prints only the payload of 114 bits.
Take a look on GSM's "normal burst" (google it, choose pics, you will find it right away), where the scheme is described. The 26 bits in the middle are the training sequence, you can omit them for your purpose. Also the tail bits and stealing bits are not needed for your task.

[roman khassraf]

We could also add an option to let the burst printer output only the payload, isn't a big deal.
Think it is useful for others, so if there are no objections, open an issue for enhancement.
I can do it on weekend, or if you are interested, you can add this feature as well.

[robert....@gmail.com]

It would be great ! I will see what I can do, I'm still learning how to create new blocks in gnuradio.

[Piotr Krysik]

W dniu 08.07.2015 o 15:23, roman khassraf pisze:

I think it it would be good to add to gr-gsm's airprobe app capability
to have output format compatible with old airporbe. Some input
parameters of the app might also be taken from old airprobe.

[Piotr Krysik]

W dniu 08.07.2015 o 16:26, robert....@gmail.com pisze:

> It would be great ! I will see what I can do, I'm still learning how to
> create new blocks in gnuradio.
>

I think that Roman's proposition to add some parameter to burst printer
switching it to airprobe like mode is good - so might be no need for new
block.

However if you want to add this or any block to gr-gsm you can use:

gr_modtool add block_name

in gr-gsm directory. It will do a lot of work for you adding in proper
files to grc, include and lib. Then you edit these files - especially
c++ code in lib directory, grc xml file to make it possible to use your
block in gnuradio companion and the header from include direcory if you
want to add input parameters or add new methods accessible from Python.

gr_modtool adds block outside of gr-gsm directory structure (decoders,
demappers, receiver, etc.). Making it part of this structure require
some hand editing of cmake files - but I can do this once your block
enter the mainline.

[roman khassraf]

I think it's not so easy to get all airprobe output printed in the burst printer, because the printer is not aware which burst is the first burst of a message ( this concerns the C1 / C0 tag in airprobe). Same for keystream and the xor'ed payload. However I think these information are not necessary, because when attempting the key recovery, one has to target specific messages, hence the user has to identify those messages before the attempt, which also implies the identification of the start burst number of the message. And for the keystream, airprobe prints the keystream and the xor'ed data only after a key is provided. So for the key recovery, this information is not available. We could add this feature to the decryption block, but imho it's usefulness is limited.

So, I would propose adding two new options to the burst printer:

prepend modified framenumber: as for framenumber, if checked, we also prepend the modified fnr
print payload only: if checked, we print only the payload instead all bits of the burst

[robert....@gmail.com]

Yes, some information are not necessary. Only the modified frame number and the payload are needed for decryption. 

[Piotr Krysik]

Hi,

It would be best to keep format compatible with old airprobe so it would
be possible to use it with software that processed data in this format.

My proposition is to start with something that carries all needed data
and can be implemented easily/quickly. So Roman, you can start straight
away with the solution that you proposed, without adding these C0, C1...
tags. They can be added later.

After that we can use demapper blocks to add number of a burst in the
message - because the demapper should know it best. We can use tags that
are associated with a message for it. They are carried by first element
of the pair that creates PDU message (only second part carrying binary
data is currently used).

Regarding printing of keystream and decrypted bursts along encrypted
bursts - I think it would be worth implementing this only if this is
really required by some other (useful) program.

Best Regards,
Piotr

W dniu 12.07.2015 o 09:03, roman khassraf pisze:

>
> I think it's not so easy to get all airprobe output printed in the burst
> printer, because the printer is not aware which burst is the first burst
> of a message ( this concerns the C1 / C0 tag in airprobe). Same for
> keystream and the xor'ed payload. However I think these information are
> not necessary, because when attempting the key recovery, one has to
> target specific messages, hence the user has to identify those messages
> before the attempt, which also implies the identification of the start
> burst number of the message. And for the keystream, airprobe prints the
> keystream and the xor'ed data only after a key is provided. So for the
> key recovery, this information is not available. We could add this
> feature to the decryption block, but imho it's usefulness is limited.
>
> So, I would propose adding two new options to the burst printer:
>
> prepend modified framenumber: as for framenumber, if checked, we also
> prepend the modified fnr
> print payload only: if checked, we print only the payload instead all
> bits of the burst
>
>
>
>
> On Wednesday, 8 July 2015 19:08:57 UTC+2, Piotr Krysik wrote:
>
> W dniu 08.07.2015 o 16:26, robert....@gmail.com

> <mailto:robert....@gmail.com> pisze:

[roman khassraf]

Ok, then I will open an enhancement issue for extending the burst printer.

[stanle...@gmail.com]

Hi, I noticed that there are many bursts obtained at the output of the Bursts_printer block that are the same ( not important data ). I suggest adding a feature to disable displaying these bursts such as airprobe where they are not shown.

[roman khassraf]

On Monday, 20 July 2015 15:37:28 UTC+2, stanle...@gmail.com wrote:

Hi, I noticed that there are many bursts obtained at the output of the Bursts_printer block that are the same ( not important data ). I suggest adding a feature to disable displaying these bursts such as airprobe where they are not shown.

Yes, thats a good idea, I think.
 Add an enhancement in issue tracker

[roman khassraf]

On Monday, 20 July 2015 21:21:22 UTC+2, roman khassraf wrote:

Hi, I noticed that there are many bursts obtained at the output of the Bursts_printer block that are the same ( not important data ). I suggest adding a feature to disable displaying these bursts such as airprobe where they are not shown.

Yes, thats a good idea, I think.
 Add an enhancement in issue tracker

I created the issue #95 addressing this enhancement.
If anyone is interested implementing this feature, drop me a message, otherwise I can do it the next days.
The implementation is pretty straight forward....

[roman khassraf]

On Monday, 20 July 2015 15:37:28 UTC+2, stanle...@gmail.com wrote:

Hi, I noticed that there are many bursts obtained at the output of the Bursts_printer block that are the same ( not important data ). I suggest adding a feature to disable displaying these bursts such as airprobe where they are not shown.

Hi Stanley, 

that feature is implemented now.