Ysoserial.net incorrectly skips setting the decryption key for legacy framework versions using TripleDES or AES validation algorithm, failing to generate a proper ViewState without --isencrypted.

If the target's framework version is .NET <= 4.0 and validation algorithm is either TripleDES or AES, ViewState must be encrypted using a legacy algorithm. See this snippet from System.Web.Configuration.MachineKeySection for GetEncodedData() method:

internal static byte[] GetEncodedData(byte[] buf, byte[] modifier, int start, ref int length)
{
        // ...
	if (MachineKeySection.s_config.Validation == MachineKeyValidation.TripleDES || MachineKeySection.s_config.Validation == MachineKeyValidation.AES)
	{
		array2 = MachineKeySection.EncryptOrDecryptData(true, array2, modifier, start, length, true);
		length = array2.Length;
	}
	return array2;
}

As can be seen, the method explicitly checks for TripleDES or AES validation algorithms to encrypt the payload. However, because ysoserial.net does not set the decryption key with --islegacy argument not accompanied by --isencrypted, it will generate ViewState encrypted with AutoGenerate,IsolateApps key failing against the target using a static key.

The target can still be exploited using --islegacy --isencrypted, placing ysoserial.net output into __VIEWSTATE request parameter, and adding an empty __VIEWSTATEENCRYPTED parameter to signify encryption.

After fixing the issue, the target should also be exploitable by using --islegacy without --isencrypted and placing ysoserial.net output into __VIEWSTATE parameter and removing __VIEWSTATEENCRYPTED parameter (ASP.NET assumes __VIEWSTATE is encrypted for the above algorithms.)

To fix this I suggest setting decryption key in all cases and letting .NET Framework do the choice of using it, since the above method seems to check for specific validation algorithms already.

This should resolve #122, #150 and #166.