The complex logic in smswrap/ota-smswrap-sjs1.c for getting the secured message
into just the right format to be accepted by the card has been copied from
Osmocom Python program shadysim.py - that Python code appears to be the only
existing reference for using the RFM feature of Sysmocom SIM cards.  However,
in the process of studying that code and extracting the logic from it, I found
what appeared to be a bug in their code and logic, and sure enough, further
investigation has confirmed it to be a bug indeed, a bug that is tolerated by
sysmoUSIM-SJS1 cards, but not the newer sysmoISIM-SJA2 - hence the test_rfm
function of that Python tool does not work on the new cards.

When the application message payload is encrypted with any variant of DES
(including the two-key 3DES used on Sysmocom SIMs), the length of the ciphertext
has to be a multiple of 8 bytes - hence if the plaintext length is not a
multiple of 8 bytes, the plaintext needs to be padded.  But what should happen
if the plaintext length going into the cipher just happens to be a perfect
multiple of 8 bytes?  The correct answer (ought to be obvious) is to apply no
padding at all, i.e., zero bytes of padding.  However, the Python code in
shadysim.py adds 8 bytes of padding, and sets the number of padding bytes in the
header to 8.  The resulting encrypted message should be considered malformed per
standard specs, but sysmoUSIM-SJS1 cards are liberal in what they accept in this
instance, thus the bug went unnoticed.  The newer sysmoISIM-SJA2 cards do not
accept such malformed messages with invalid padding, and it just so happens that
the message generated by the test_rfm function has 40 bytes of plaintext going
into the cipher, perfectly divisible by 8 - hence their test_rfm function fails
on the new cards.

Our ota-smswrap-sjs1 program accepts an optional third argument after the two
key arguments, selecting the padding mode.  The default mode is correct padding;
if the extra padding mode argument is set to 1, our tool replicates the bogus
behaviour of the reference Python code.  This bug-compatible mode has been
implemented to make sure that we can generate the exact same packet starting
with data/shadysim-rfm-test (verifying that we have copied the logic correctly),
but it should not be used further beyond these debugging tests.