TryCatchFinally.net Some SQL, some .NET, and whatever else

31Aug/120

Network not working after removing Symantec Endpoint Protection

About a year ago, I made the switch from Symantec Endpoint Protection 12 to Microsoft Forefront on a small network I manage, and the transition was mostly smooth. I noticed a few weeks ago, though, that one of my servers still had SEP installed, though it wasn't running. I uninstalled SEP, thinking it would go smoothly, and on reboot, I lost connectivity to the server. No ping, no remote desktop - nothing.

On rolling over to the server and checking the desktop, the network connectivity was completely dead - I couldn't ping the gateway or browse the internet at all. Using Device Manager to uninstall the network card and rebooting didn't do any good, not did attempting to update drivers. However, in device manager, I could see a "Teefer2" entry for every one of my network connections, and it was set to disabled - this is the Symantec Network Threat Protection driver, and it monitors your network activity. Thinking this could be the problem, I attempted to right-click -> Uninstall each of these, but nothing happened - they didn't uninstall.

Trying to update the drivers on the network card (which said a file was missing) always give me the same error message: "The system cannot find the file specified." It would almost work, up until the very end of the driver wizard, and then that error.

I found an article about running a Symantec tool called "Cleanwipe" that's supposed to remove traces of failed Symantec Endpoint installations. You need an open support ticket to get it from Symantec directly, but if you know the filename, you can Google it and get it from others (note: I don't vouch for the results - you're on your own).

Running that tool didn't solve my problem, though it did delete a number of components that were left. Next, I went through and manually deleted the remnants, following these instructions:

http://www.symantec.com/business/support/index?page=content&id=TECH91038&locale=en_US

That removed everything except the Teefer2 entries in my networking list. After about a dozen random fix attempts from all over the internet and reboots in between, I stumbled on an Experts Exchange question where somebody had posted a solution:

http://www.experts-exchange.com/Hardware/Networking_Hardware/Q_23508822.html

For those without access, the fix is simple - delete a single registry value. It's located under HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlNetwork and is called "Config". Don't delete the Network key, and don't just clear this value, delete the value entirely. Once you do, you'll be allowed to delete your network cards and the Teefer2 entries from device manager - remove all the Teerfer2 entries and any network connections that were associated with them, and then reboot. Windows will detect your network cards and let you install drivers, except this time it will work.

About 7 hours of troubleshooting and a dozen reboots, and the fix was to delete a single registry value. The Cleanwipe and the manual removal of SEP might have been required as well, but hopefully this saves you some time.

7Aug/120

Decrypting RSA with Java

In a recent Java project (a *small* departure from my normal VB.NET development), I was attempting to use RSA to decrypt a value stored in one of our databases, but was running into some trouble. When I used Java's native RSA Cipher (available in Java 1.5+), I could decrypt the value without any issues, but when I switched to Bouncycastle, I would get gibberish. Since I was doing the decryption from inside an Oracle database, the only version of Java available was 1.4.2, which doesn't have a default RSA provider, leaving Bouncycastle as the only option.

The decryption didn't fail or throw an exception - it always succeeded - but the resulting decrypted byte array was completely different between the two providers. In Java's native RSA, it was 32 bytes (as it should be), but in Bouncycastle, it was 128 bytes (the same length as the input, interestingly).

In the end, it turned out that Java’s default RSA implementation is "RSA/None/PKCS1Padding", whereas BC’s is “RSA/None/NoPadding”. Changing BC’s version of the Cipher.getInstance line in my code to explicitly specify the new padding resolved my issue:

Here's the original code (Line 10 is the one to switch out):

Cipher RSADecrypter;

// Here's the flag for choosing which provider to use
Boolean UseBouncyCastle = Boolean.TRUE;

// Choose between Java and BouncyCastle
if (UseBouncyCastle == Boolean.TRUE)
{
    Security.addProvider(new BouncyCastleProvider());
    RSADecrypter = Cipher.getInstance("RSA", "BC");
} else
{
    RSADecrypter = Cipher.getInstance("RSA");
}

// Initialize the Cipher using our the first key in the keystore
// This step works fine for both providers
RSADecrypter.init(Cipher.DECRYPT_MODE, keystore.getKey("1", PrivateKeyPassword.toCharArray()));

// Decrypt first 128 bytes of the array - here's the problem
// Java RSA gives 32 byte result, BouncyCastle gives 128 bytes of randomness
aegEncryptionKey = RSADecrypter.doFinal(binaryDataEncrypted,0,128);

More related reading:

How to check the java version
Bouncycastle's default crypto
Java's default crypto