Decrypt files moved to USB drive and back

Solution 1:

It appears Microsoft is using previously unused fields in FAT32 directory entries and possibly also hidden directory entries and tricks with long and short filenames to store EFS metadata on FAT32:

Encrypted files have the “.PFILE” extension and their 8.3 directory entries store additional metadata. In the current implementation, this metadata fits 6 bits: two bits are used as flags and four bits are used to store the padding size.

The additional metadata is stored in the NTByte field, which is located at the offset of 12 bytes within the 8.3 directory entry. Previously, this field was only used to store two flags marking the short base name or extension as lowercase (bits #3 and #4 respectively).

Now, remaining bits are used too. Bit #0 is set when the file is encrypted (it’s also set for a directory when its newly created files should be encrypted by default), bit #1 is set when the file starts with a large EFS header (otherwise, it’s a standard EFS header). Other bits (bits #2, #5, #6, and #7) are used to store the padding size (which is at most 15 bytes in size, so 4 bits are enough) – its bit #0 (LSB) goes to bit #2 of the NTByte field, bit #1 to bit #5, bit #2 to bit #6, bit #3 to bit #7.

(Source, see also the referenced US patent US10726147B2)

By moving the files away and then putting them back you have destroyed the special metadata, because Linux doesn’t know about it.

I’m sorry to say this, but your files are almost certainly beyond recovery. Still, you could try guessing the hidden metadata, there’s only 64 possible values after all. Doing this would require a raw disk hex editor or a custom filesystem driver though.