Unitrunker: P25 raw signal MUST be filtered

[Nessus]

BCD996P2 might NOT be new hardware. I cannot locate a new Part 15 Certification for this product after searching here: https://www.fcc.gov/fccid I did find the equivalent to an FCC Part 15 filing for canada, and here is where it gets interesting: The manufacturer's model number for BCD996XT and BCD996P2 is IDENTICAL.

Consider this: The BCD996XT 1.07.03 Firmware has a license key decoder so if the hardware is unchanged, Uniden could have simply released a major firmware revision such as "2.0" (current release level is still 1.x) and charged a fee for a new SW License key. (For example Uniden issued 3.x License Keys for BCD996T, where the fee to go from 2.x to 3.x was zero dollars)

Then why release a new model if the hardware is unchanged? Unfortunately, there is only one answer that makes sense, and I have just verified it to be the case. The algorithm used to encrypt the new firmware is different. The BCD996XT Boot ROM includes a firmware decryptor that is loaded in RAM at BOOT time. This decryptor processes the incoming binary into clear text and then loads it into FLASH ROM. If you want to change this algorithm in the BOOT ROM it IS possible to do so. However, you would have to release the new firmware that includes the new algorithm using the original firmware encryption algorithm. If that had been broken, then the attacker would be able to access the new firmware decryption algorithm and defeat it. The only solution is to ship "New" hardware with a boot ROM that contains the new firmware decryption algorithm, and with the new firmware already encrypted using the new encryption algorithm.

I was hoping to compare the BCD996P2 firmware with the BCD996XT firmware to see if the demod was different.

Well...not today.

I attach some photos from BCD996XT. If anyone would like to attach similar ones for BCD996P2 this would be of great assistance. I will post photos of the BCD9996XT ECO-system later.

Attention RR.com Community: If you own a BCD996P2 please PM me if you would like to try an interesting (and completely safe) experiment.

 

[Nessus]

One of the attachments intended for the post I made to this thread yesterday was missed. This is from TIA-102.BAAA-A-2003.

WARNING: The solution in the underlined statement is now known to be sub-optimal for CQPSK (as it was called in 2003) demodulation. Today CQPSK Demodulation is called "H-DQPSK Demodulation" and the Frequency Demodulator in Figure 9-3 has been replaced with a proper Phase Demodulator that communicates BOTH phase and amplitude information accurately.

See “Figure 8 Demodulator for H-DQPSK” on page 14 of TIA-102.BBAB (posted yesterday) for more detail.

 

[KA1RBI]

This is from TIA-102.BAAA-A-2003.

Yeah, the "CQPSK" that's described in TIA-102.BAAA-A is *not* LSM. I have been as guilty as anyone in using terms like "LSM/CQPSK". I'm not even sure there has ever been an actual vendor implementation of TIA-102.BAAA-style CQPSK.

Parts of LSM are described in us pat 5,541,953, although the secret sauces have been suppressed in that document, of course. Long ago I did some work on that, for further info see

http://forums.radioreference.com/vo...k-p25-decoder-test-release-4.html#post2389678
LSM Gallery - Page 2

Today CQPSK Demodulation is called "H-DQPSK Demodulation"

The way I think of it is, "LSM" is a proprietary trademark, so they needed to launder the acronym so it could be accepted by the standards committees. (H-DQPSK == "Harmonized DQPSK")

Max

 

[Mike_G_D]

Nessus, here's another old discussion thread that might be of interest to you; lots of discussion about simulcast distortion and the use or not of an equalizer to deal with it and relevant demodulation methods: http://forums.radioreference.com/ge...898-p25-simulcast-multipath-interference.html.

-Mike

 

[Nessus]

Wow Max, you have been busy. I did not realize so much progress had been made in GNU Radio since I last looked at it. I spent all my time in DSD up until now. I looks like I will need to move up to the big leagues and get myself an I-Q Demod setup!

Actually I think I my already have one. In 2014 I bought one similar to eBay item 331510419948 and I was able to make a complete trunking digital scanner from it: https://sites.google.com/site/policescannerhowto/, using my own version of DSD, although my laptop did not have enough CPU power to consistently decode the digital radio, probably due to my BMHG Symbol recovery algorithm basically being a DSP in Software. Perhaps a version base on IQ would be less hungry. Cool experiment though.

The exact one I bought is the one pictured here: http://superkuh.com/gnuradio/rtlsdr_r820t_mini_2.jpg but they don't seem to sell those anymore.

Is that TV tuner sufficient to run GNU Radio Max?

Thanks for the link to B. Hiben's patent. I must say that in the course of researching P25, many paths lead to Hiben, Wilson, or Cudak. I would have liked to have worked there during those years it would have been fun, except for living in Chicago, much prefer West Coast thank-you very much.

Hi Mike,

Thanks for that link, had not seen that thread at all!

Hi All,

Regarding my request for BCD996P comparison photos yesterday, here is a repository created by the worlds foremost Uniden Archaeologist that contains the BCD996XT eco-system photos I promised. Index of /files/photo/996xt JD's photos are better than mine, and this way, I don't have to find a drop-box somewhere.

 

[MattSR]

Hi Nessus,

All agencies in my country, with the exception of one or two, are still using DES-OFB. This information is easy to gather, as it is transmitted in the clear, in the header packets and in the encryption sync information in each LDU2 packet.

The AlgID field is set to 0x80 for unencrypted, 0x81 for DES-OFB, or 0x84 for AES-256. I have only seen 0x84 in use a few times, and thankfully it is becoming more and more popular.

All of this information is transmitted in the clear, and it's very easy to decode. After much analysis, it has become clear that DES-OFB is the most common algorithm used for P25 encryption, contrary to the FIPS recommendations and the fact that DES is totally outdated. This isn't just the case in Australia, but also in the US and Canada as well.

You claim that I do not understand these facts, however I have been working with Max and others on the OP25 project since 2008, and all this is verifiable and proven..

Cheers,
Matt

 

[MattSR]

Good news Matt! I presume that you are referring to Rijndael, the current standard for coded communications in P25. I expect that will result in a Nobel prize for some brilliant researcher shortly. Do you happen to know what algorithm is replacing FIPS-197? The journals are remarkably silent on this topic. Also, I am not familiar with the paper that you allege, but are unwilling to share. Is it perhaps a “square root of negative 1” type of paper? Ha!

That's a very long way of saying that I am incorrect because P25 standards suggest using AES. The paper actually relates to weaknesses in P25 itself (specifically the xMBE codec), not the ciphers themselves.

As for your comments on the credibility of the paper, well.. as I said, it's accepted and published and academically vetted. Please keep your sarcasm to yourself thanks

I saw a paper on DES-OFB related to P25 back in Sept 2011. This paper was completely uninteresting owing to the fact that FIPS46-3 was withdrawn by NIST on May 19, 2005, more than SIX YEARS PRIOR. Not making this up yo: [http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf]. So unless your county’s public safety dept. is still using DES-OFB Matt, and trust me they aren’t for the very reasons you cited, my assertion stands.

As discussed above, they ARE using DES-OFB. There's a lot of it still out there.

Besides, would you even know how determine whether that was the case by recovering the voice frames and analyzing them yourself? Apparently not, or you wouldn’t be beaking off like that. In case you ever decide to establish facts first, and type second, the answer is in Section 5.4 on page 14 of TIA-102 BAAA-A 2003 and also on pages 31 and 41 of TIA-102 AAAD-A (ANNEX A and ANNEX C respectively). Let me know what you discover off-the-air in your locale, I am curious to see if you are right (or not.)

There you go again attacking me by making incorrect assumptions about my knowledge. As stated above, you don't need to "analyze voice frames" as P25 transmits its encryption metadata in the clear. It's very easy to determine the Algorithm ID in use by looking at the AlgID value in the HDU and LDU2 frames. As you mention above, you are well versed with DSD, so this should already be known to you as DSD prints this information to the screen.

One more thing Matt. COPACOBANA is out of production. So is FORMICA, its "low cost" successor. I happen to know this because in 2013 I wrote bitcoin mining software that runs on FORMICA, including designing XILINX FPGA targeted intellectual property to implement two rounds of SHA-256 fully pipelined in a single core and at a respectable clock speed to boot. I was able to earn BTC for several months by leasing time on a FORMICA and running my code before BTC difficulty went through the roof. I also wrote a plugin for the controller in Python (specifically, I adapted the MPBM to work with FORMICA API V 1.91 by porting the FORMICA API libraries to Python and writing a FORMICA driver for MPBM in Python). I also developed and sold distributed processing software that runs on the RIVYERA SPARTAN6-LX150 Machine Family. I can easily prove the FORMICA claim, just PM me with your verifiable identity Matt, and I will deliver. Also, not planning on just handing over my intellectual property to the first person who asks, sorry dude.

While all that might be true, the fact that COPACOBANA is out of production doesn't really bear much relevance to this discussion. Good work on the bitcoin implementation, I don't need to see it as I know it has been done in FPGAs and more recently ASICs as well.

 

[Nessus]

Hi Matt,

OK. I accept your facts. Sorry about the sarcasm. Surprised to hear $81 is in use. Good work on OP25. I might try to port BMHG algorithm to it once I learn more about it. Is your traffic C4FM or H-DQPSK? What is the NAC?

You are correct, the MI is always in the clear. Your numbers are correct. My point was that even with the flaws in P25 identified in the paper you would be no further ahead with $84.

Thanks for sharing the info.

Nessus

P.S. Have you inspected the unit IDs and channel numbers (which are also always in the clear) ?

Quiz: Do the same unit IDs use both $81 AND $84? (I predict no).
Quiz: Do you hear $81 and $84 on the same P25 channel number? (Also, predict no).

 

[Nessus]

P.S. Have you inspected the unit IDs and channel numbers (which are also always in the clear) ?

Quiz: Do the same unit IDs use both $81 AND $84? (I predict no).
Quiz: Do you hear $81 and $84 on the same P25 channel number? (Also, predict no).

Hi Matt,

Did you get a chance to compare the unit IDs and Channel numbers for DES-OFB ($81) vs. $84 transmissions? Are the predictions above correct?

Curious.

N.