Leftover padding in decrypted files

[L-Leite]

UnCSO2 is leaving extra bytes in the end of the decrypted files due to padding.

Decrypted file example maplist.txt:

The red rectangles highlight the padding left into the files.

Counter-Strike Source's maplist.txt:

The game decrypts the files properly (it uses OpenSSL), so I'm guessing it's Crypto++'s fault or some missing option when decrypting the files.

Porting UnCSO2 to use LibreSSL will probably fix this since it's a closer method of decrypting to the game.

[GEEKiDoS]

I did't get padding bytes using System.Security.Cryptography of .NET Framework with those code

var rijndaelManaged = new RijndaelManaged();

rijndaelManaged.Mode = CipherMode.CBC;

rijndaelManaged.IV = s_EmptyIv16;
rijndaelManaged.Key = GeneratePkgListKey(flag, fileName);

var decryptor = rijndaelManaged.CreateDecryptor();

var outBuffer = decryptor.TransformFinalBlock(inBuffer, 0, inBuffer.Length);

I guess you just misconfigured crypto options.

[GEEKiDoS]

Or your could remove the extra padding by hand:

uint32_t GetRealBufferSize(uint8_t* pOutBuffer, size_t iBufferSize)
{
	uint8_t currentByte = 0;
	int paddingLength = 0;
	for (int i = iBufferSize - 16; i < iBufferSize; i++)
	{
		if (pOutBuffer[i] != currentByte)
		{
			currentByte = pOutBuffer[i];
			paddingLength = 1;
		}
		else
		{
			paddingLength++;
		}
	}

	return iBufferSize - paddingLength;
}

if ( !DecryptEncFile( targetFile, pBuffer, iBufferSize ) ) { /* ... */ }
iBufferSize = GetRealBufferSize(pBuffer, iBufferSize);

That's working.

[L-Leite]

Wouldn't that not work if the padding bytes are different? What if a file for ends with ////////////////?

[GEEKiDoS]

Wouldn't that not work if the padding bytes are different? What if a file for ends with ////////////////?

The game is using PKCS7 padding mode, after some searching I find that all the padding byte will be the length of padding data, That function is not needed anymore.

iBufferSize -= pOutBuffer[iBufferSize - 1] ;

The padding modes I searched on internet: (DD is random data, after that is padding bytes, 05 is size of padding bytes)

ANSI X.923
 | DD DD DD DD DD DD DD DD | DD DD DD 00 00 00 00 05 | 

ISO 10126
 | DD DD DD DD DD DD DD DD | DD DD DD 95 81 28 A7 05 |

PKCS7
 | DD DD DD DD DD DD DD DD | DD DD DD 05 05 05 05 05 |

But the Zero mode is padding with 0 and ISO/IEC 7816-4 is using the 0x80 as mark of start, then padding with 0:

ISO/IEC 7816-4
 | DD DD DD DD DD DD DD DD | DD DD DD 80 00 00 00 00 |

Zero padding
 | DD DD DD DD DD DD DD DD | DD DD DD 00 00 00 00 00 |

[L-Leite]

Should be fixed in Release v2.0.4