In my previous post I talked about the FEC used by the SMOG-P and ATL-1. In there, I reverse-engineered the long frames transmitted by SMOG-P and found that they use the AO-40 FEC protocol.
After publishing that post I started reverse-engineering the short frames. Meanwhile, Peter Horvath pointed me to a Github repository containing an implementation of the FEC used for short frames and long frames. I hadn’t seen that repository before (it’s not easy to search for SMOG-P or ATL-1 in Google, as many unrelated results come up). Indeed this repository contains the source of a FEC decoder for the short frames, so there is no need to reverse-engineer it.
Timur Kristóf, the author of that repository, says that the team plans to release the source for the decoder, but that they are currently very busy with the early operations of the satellites. This is very good news.
I have studied the code in the Github repository and included a decoder for the short FEC frames in gr-satellites.
The short FEC frames are a straightforward modification of the AO-40 FEC protocol. As I suspected, they carry a single Reed-Solomon (160, 128) codeword. The way this is done is by using a 52×51 matrix interleaver instead of 65×80. The length of the distributed syncword is thus 52 bits instead of 65.
However, there is something a little bit strange. Whereas in the standard AO-40 FEC the output of the matrix deinterleaver is sent to the Viterbi decoder after removing the 65 bit syncword, in these short frames the first 80 bits (including the 52 syncword bits) are dropped before sending the frame to the Viterbi decoder. This gives a frame of 2572 symbols to be sent into the Viterbi decoder, which outputs 1283 bits. The last 3 of these bits are dropped to obtain a 160 byte Reed-Solomon codeword.
The list of short frames decoded from the recording I made yesterday can be seen in this gist.
Besides FEC decoding of the short frames, there is still more work to do in order to have a complete decoder. By now I know nothing about the “very short frames” (Timur says that they are used from synchronization). Additionally the format of the data packets is not known. Hopefully this will be made clear when the team releases the source code.
Regarding the AES128 encryption functions that I mentioned in my previous post, Peter stated that the encryption is only used for authentication. I have analyzed the smogpgnd_x86_64 more carefully and I am confident that this is true. The AES128_block_decrypt function is only called from the AES128_builtin_test function, which in turn is not called from anywhere. Additionally, the packets I have decoded don’t seem to be encrypted (the data would appear much more random). Therefore, the downlink doesn’t seem to use any encryption.
The function AES128_block_encrypt function is called from uplink_encoder (which, again, isn’t called from anywhere), so it seems that the uplink uses some form of encryption (perhaps only for authentication). This is perfectly reasonable and follows the ITU regulations, since the uplink is a control signal.
Interestingly, there is also the chk_downlink_pckt_signature. It isn’t called anywhere and just returns -1, so it is not implemented in the binaries released by the team. However this hints that the packets sent by the satellite have some form of authentication. Indeed, in the packets I’ve decoded the last 10 bytes seem quite random. These bytes (or just part of them) might be an HMAC or similar kind of signature.
This form of authentication without data encryption is also allowed by the ITU Radio Regulations, for all forms of communications. It is an interesting concept and it is seldom used in Amateur communications. The most similar thing that I have seen in Amateur radio is the elliptic curve signature in DML. AAUSAT-4 software was also prepared to use a HMAC, but I’ve never checked if the downlink transmissions were signed with the HMAC or it was only for the uplink. Congratulations to the satellite team for bringing in these interesting security features while following the ITU regulations.