Using DSD-FME to Decode Encrypted DMR Samples

[Razorback55]

18 USC 2510-2520, the ECPA.

Read your document a little better, the Wiretap Act has nothing to do with testing encrypted samples whose key is known on software like DSD-FME.

And the Wiretap Act doesn't stop you from saying that you think a 56-bit key is breakable or not.

 

[WV8VFD]

To sum up using AI for coding. It has been my experience that AI is good at regurgitating code that it has located from other sources (including Git). AI is useless for creating new code or creating code chunks that require original thought.

I have seen tons of posts all over the net asking for a way to ask AI to generate code to do something. In almost every case AI generates valid code chunks but they are not tied together in a coherent or functional package. This is not to say AI is useless but it does focus on the fact AI is not a coder its more like a dictionary. HMM a 'large language model' does descibe its output very well.

AI is as good as the context and prompts you feed it. If you just put in a prompt that says "I want a software that does "X" you may or may not get something out of it that is functional and does "X"

If you feed it concise prompts, with proper information, are able to test and debug it, and able to tell/show it WHAT the software is doing wrong, not just telling it "it doesn't work" and expecting it to fix the problem, you will be amazed at what it can do.

It also matters WHICH model you use to generate the code. I have had the best luck with Anthropic's models personally, but I have tried others and they have fallen flat on their face when Opus has shined through - this is just personal opinion though.

I am by far a coder or software engineer, but I have a couple of programs I have written with AI that it still amazes me I was able to get it accomplished.

 

[gary123]

Keeping in mind that the original intent of this thread was to provide encrypted voice files with known keys so people could learn how to use DSD-FME.

This is the critical point in this thread. Providing capture samples is the objective here. Although everyone concentrates on ADP/DES and AES there are a ton of other encryption formats in use. DMR is loaded with unique encryption formats. Samples of any and all of them are always of interest. Many of the third market DMR radios have oddball BP modes. Capturing these is a challenge.

For a sample to be of use what is needed is the type of radio used, the encryption method selected in the software (BP,EP,AP etc) and finally the key the user was using. If its an unknown key then mentioning that would be helpful. Finally a unencrypted capture from the same system is needed as a reference. Preferable the same user but if not then another user will work.

For a capture to be useful as much data as possible is wanted. The MFID, ALGID and KID(if one is present) are important and the MI is critical. Only advanced algos use a MI, anything using BP will not have a MI. Another important thing is to capture the first set of VC frames. Sometimes FME is slow to migrate to the voice channel and thus misses that first frame set. FYI this is what causes that annoying garble for a half second. The solution is to sit on the voice channel and wait for the encrypted user to use it while logging. This way those critical frames are captured. A capture does not need to be 2 hours long what is needed is only the first couple of seconds. Pausing the logging between transmissions and restarting when there is no signal is the best way to capture multiple keyups in one capture. Those interested will be filtering the data by timestamp so can separate out the various keyups.

 

[DaveNF2G]

Read your document a little better, the Wiretap Act has nothing to do with testing encrypted samples whose key is known on software like DSD-FME.

And the Wiretap Act doesn't stop you from saying that you think a 56-bit key is breakable or not.

It is unlawful to decrypt any signal whose content is not intended for you. There are no exemptions for "experimentation", software development, or curiosity.

 

[mikewazowski]

If you want to learn how to decode encrypted samples with DSD-FME (knowing the encryption key), there are a whole range of encrypted samples here:

It is unlawful to decrypt any signal whose content is not intended for you. There are no exemptions for "experimentation", software development, or curiosity.

In this case, the content was intended for us and the keys to decode that content were provided.

 

[Razorback55]

It is unlawful to decrypt any signal whose content is not intended for you. There are no exemptions for "experimentation", software development, or curiosity.

One guy made test samples where he says test 123, test 123 and he released those samples for everyone; providing the encryption key. So these samples are for everyone, you, the neighbor, the cat, everyone!

So you can decode them since it's for everyone!

I didn't know that some people are unable to understand a piece of legislation written in normal English.

 

[DaveNF2G]

One guy made test samples where he says test 123, test 123 and he released those samples for everyone; providing the encryption key. So these samples are for everyone, you, the neighbor, the cat, everyone!

So you can decode them since it's for everyone!

I didn't know that some people are unable to understand a piece of legislation written in normal English.

I understand the legislation perfectly. In fact, I have some earned and documented expertise in such things, despite the arrogance of the RR know-it-alls. What I did not know until just now was the source of the transmissions being discussed.

 

[cheap_ottawa_scanner]

Can anyone provide a Hytera BP example? I have read that their BP algo is different / proprietary in comparison to Motorola and I would like to look at it a bit so I can correctly label the networks around me. sorry if that is too close to the original point of the thread