Which ECB ciphertext stealing scheme is this?
This may sound crazy and absurd, but it seems that this scheme is simply broken:


on encryption, the last block is somehow padded (the exact method is not really relevant, but perhaps the trailing bytes of penultimate plaintext block are copied) and encrypted, then finally ciphertext is trimmed to match plaintext size;
on decryption, the same buffer is reused for each block, so the last ciphertext block is naturally padded with the trailing bytes of penultimate ciphertext block, then decrypted, and finally plaintext is trimmed to match ciphertext size.


Obviously, such an “encryption” irreversibly corrupts the last block, resulting in garbage being output on decryption. However, application software appears to ignore bad data silently, discarding the last record, absence of which is not evident to user, unless he specifically looks for it.

Well, I am not totally sure about this, as I only analyzed (OllyDbg to the rescue!) the decryption stage and header parsing, while object records are parsed on later stages of a quite-high-level processing, but it looks improbable to me that those high-level routines could perform a custom non-trivial restoration of the last block, — the more so that the last record appears to be missing, unless plaintext is guessed by hand (guessing is possible due to the highly predictable nature of plaintext, especially in the last block). However, if I am terribly mistaken, and such a scheme with properties specified in question is theoretically feasible, it would be interesting to know about it.