I've noticed that in order to 'illegally' crack certain applications, it is necessary to patch the host file to stop communication with the activation servers.

I've found that with several applications there are entries that don't match the rest. These entries seem to patch the certificate revocation lists (CRL) for Verisign which i find to be quite suspicious.

The entry in question is: crl.versign.net

Obviously the CRLs don't have anything to do with the application cracking process (so far as i can tell). Is there a malicious reason to do this?

  • As a side note, I just checked the application, and yes, it appears that the original DLL is signed by verisign while the cracked DLL is indeed flagged as invalid. I have tested patching the hosts file without the CRL line and I haven't encountered any issues however.
    – NULLZ
    Commented Apr 29, 2013 at 0:00
  • Verisign is a top tier provider , financial institutions use certificates to prevent forged websites, so does the rest of the web really . Your machine now no longer has a effective measure of figuring out if you are entering your banking or credit card details into the website that you think you are visiting or a website which is designed to look like it and phish for your data. Commented Feb 9, 2015 at 17:59
  • I think cracked software is the least of the issues for that particular computer Commented Feb 9, 2015 at 18:00

2 Answers 2


Some operating systems, including Windows, want to enforce verifications of signatures of DLL. The verification entails validating the signature against the signer's public key, which is found in the signer's certificate, which itself needs to be validated. Certificate validation includes revocation status check.

In practice, a Windows OS validating a certificate will download CRL to ascertain that the certificate is not revoked. However, if the same OS cannot download the CRL, then it will just assume that the certificate is probably unrevoked. According to the normal X.509 model, when revocation status cannot be obtained, the certificate should be rejected. However, this means here that the application does not start, and the consumer will be unhappy (that is, significantly unhappier than what is already entailed by using Windows); and it would mean that the machine cannot work without a working Internet connection, which would imply some interesting chicken-and-egg issues.

So adding an entry which prevents connections to Verisign's CRL download server can have a malicious reason: this allows the attacker to sign his nefarious code with a revoked certificate (e.g. a certificate whose private key has been stolen by the attacker some time ago), while still maintaining a working Internet connection for the said machine.

  • Does that mean any stolen/known malicious certificates that are revoked are revoked by the original CA only?
    – NULLZ
    Commented Apr 28, 2013 at 13:33
  • Well, yes, mostly. Revocation in X.509 is done either by the CA itself, or by a CRL issuer which is designated by the CA (the CRL issuer name is specified in the target certificate) and which also has a validated certificate (this is called indirect CRL issuing and it is rather rare because deployed implementations have only poor support for it). Commented Apr 28, 2013 at 13:42
  • Alright, are there ever any instances where another CA would also provide the CRL of a different CA then? Once you machine downloads a CRL, does it care where it came from?
    – NULLZ
    Commented Apr 28, 2013 at 14:27
  • A CRL is signed precisely so that the way it was obtained is irrelevant. Like certificates, they can be delivered with avian carriers if need be; it does not matter. CA 1 signing a CRL for CA 2 may occur only if CA 1 agrees with it; CA 1 "agrees" by including in the certificates issued by CA 1 a specific extension which designates CA 2 has an allowed issuer for CRL covering the certificate (but, in practice, CA rarely do that). Commented Apr 28, 2013 at 14:41
  • Awesome, thanks! One last question. Do things like 'windows update' update CRLs? I remember the stuxnet incident where verisign blacklisted the certs, but apparently Microsoft did as well? How does that work exactly? Are they just ensuring that the verisign blacklist gets pushed through via win-updates?
    – NULLZ
    Commented Apr 28, 2013 at 23:57


note spelling

Pointing out that the person who made that hosts file list fat-fingered Verisign. The host actually listed doesn't seem to exist and wouldn't be referenced by Adobe.

I'd drop that line out of the hosts file, or correct it, but it appears to be a typo. I'm planning on deleting that line because other apps or websites could need to access crl.verisign.net.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .