DMR interliving and deinterliving

[DiggerPopPC]

Thanks for your helping in my problem. The main idea of my question is algorithm how to take open data. I have packets (last week I find part of algorithm which described Genguser). I used okdmr and undertood algorithm to take service data from LC header. But where is describing type of crypto algorithm at this moment I dont know.
I would like to understand the data transformation from the moment of recording from the air or network to the moment of receiving open data. I have an example with a known key for ARC4 and I work with it. Unfortunately, I have a number of packets with voice for 3 superframes. I thought that one set would be enough to understand the full algorithm.
I understand that the projects have the algorithm itself, but unfortunately there is not enough understanding of how to feed data to them and go step by step with the data. Now I am working with OKDMR. Feeding distant voice packets to the input one by one. Maybe someone understands how to get a ready-to-decrypt superframe from 6 voice packets? And how to submit it for decryption? Judging by the information, a gamma is generated from the key, and the superframe is XORed with it bitwise. This is in theory. But so far in practice I have not received this(((
And many thanks to all participants for your help.

 

[DiggerPopPC]

And I can take DMR RAW packages from pcap-file in binary level and make bin file with only DMR data without lan data.

 

[lwvmobile]

Bursts starts at 25th byte. and ends at 59th byte which makes 34 bytes. (I dont know the reason, maybe beacuse even/odd numbering).
in final you take out the last byte which should be always zero, i highlight that byte with brackets below.
for alignment page view reasons i put below only bytes. so first line is mixed (original) multi site packet content, second line is unmixed into regular DMR bursts. Pattern in that is viewable. Just shifted bytes. if i'm looking correctly on that it should be scheme 2-1-4-3-6-5, etc...

Oh, okay, I see now. Yeah, I've noticed a similar trend lately as well, that Hytera likes to work with 16-bit codewords as opposed to having bits and byte arrays. Not sure the reason for that. I guess they also like to swap the byte order when loading arrays as 16-bit codewords. Maybe its something to do with Chinese and UTF16BE (I think its big endian, or maybe its little endian).

if dynamic converting is required by author, then i guess it will require more implementations. I have just two ideas how it can be done for dynamic, but i cannot speak for smarek and lwvmobile, first one can be by making dsd-fme possible to decoding these multi-site network communication into decoder natively, or by somehow optionable listening on network port for that network traffic which will(?) be passed from ok-dmr after decoding into dsd-fme tool.

Well, it might be possible to open a TCP or UDP port to listen for IP frames, but I would need to know how the application that delivers that is configured. Technically speaking, with M17-FME, I already do a similar task of listening for UDP frames and decoding them, and the TCP is already baked into DSD-FME for audio input, could be reconfigured for IP frames if delivered over TCP.

Another option would just be to prototype a simple C program to listen to a port and do the conversion on the fly and convert it to a .bin format for replay, or to read an input file with the payload dump and do the conversion that way.

All that being said however, it would require time and effort to write, test, etc, and the desire to accomplish this along with the idea of how many people might actually benefit from doing all of this.

All this is to say, going back to the most basic question, if there are IP frames, where is the RF application? Would be much easier to forego the IP frames and get to the over the air component since all the pieces are already in place for that.

 

[DiggerPopPC]

Oh, okay, I see now. Yeah, I've noticed a similar trend lately as well, that Hytera likes to work with 16-bit codewords as opposed to having bits and byte arrays. Not sure the reason for that. I guess they also like to swap the byte order when loading arrays as 16-bit codewords. Maybe its something to do with Chinese and UTF16BE (I think its big endian, or maybe its little endian).



Well, it might be possible to open a TCP or UDP port to listen for IP frames, but I would need to know how the application that delivers that is configured. Technically speaking, with M17-FME, I already do a similar task of listening for UDP frames and decoding them, and the TCP is already baked into DSD-FME for audio input, could be reconfigured for IP frames if delivered over TCP.

Another option would just be to prototype a simple C program to listen to a port and do the conversion on the fly and convert it to a .bin format for replay, or to read an input file with the payload dump and do the conversion that way.

All that being said however, it would require time and effort to write, test, etc, and the desire to accomplish this along with the idea of how many people might actually benefit from doing all of this.

All this is to say, going back to the most basic question, if there are IP frames, where is the RF application? Would be much easier to forego the IP frames and get to the over the air component since all the pieces are already in place for that.

Thank you very much for your answers.
But jne more question. I can cut DMR Raw packets, as I did in the example. How can I feed them to the input of the program?
To be honest, I'm a little confused. As I understand, your program decodes data from the receiver. The data itself has a different form at the binary level. Could you tell me how to convert this data to feed it to the input of your program? Working with binary data is not a big problem for me. It is important for me to understand the algorithm of actions. How and where to rearrange the bits and what to do next.

 

[DiggerPopPC]

Thank you to everyone who answered my questions. You have greatly helped me in understanding my issue. Also, thank you for the projects you suggested I look into. I hope that soon I will be able to explain what and how things need to be done myself. For now, I continue to figure things out. I'm very happy that such wonderful people exist who are willing to share their experience.

boatbod, Genguser, lwvmobile​