Excel VBA：120天后代码失效方案咨询（除日期对比外）

Hey there! Since your client understands no solution is 100% unbreakable, let’s dive into practical, harder-to-circumvent approaches to lock VBA code after 120 days:

• Encrypted expiry date in a hidden sheet
  Create a sheet and set its visibility to xlSheetVeryHidden (this can’t be unhidden via the Excel UI—only through VBA or the VBA editor). Store an encrypted version of the expiry date here (use a simple custom encryption like XOR with a secret key, or a basic hash). On each run, decrypt the value and compare it to the current date. Even if someone finds the hidden sheet, they’ll need to crack your encryption logic to modify the date.
  Example snippet to set the sheet visibility:

  ThisWorkbook.Sheets("HiddenExpiry").Visible = xlSheetVeryHidden
  

• Store expiry in custom document properties
  Excel files let you add hidden custom properties that aren’t visible in the standard document info panel. Write an encrypted expiry timestamp to a custom property on first run, then validate it every time the macro starts. This is harder to spot than a cell value, though someone with VBA knowledge can still access it.
  Example to set a custom property:

  ThisWorkbook.CustomDocumentProperties.Add _
      Name:="EncryptedExpiry", LinkToContent:=False, _
      Type:=msoPropertyTypeString, Value:=EncryptDate(DateAdd("d", 120, Date))
  

• Hardware fingerprint + expiry binding
  Tie the expiry date to unique hardware identifiers of the user’s computer (like hard drive serial number, motherboard ID, or MAC address). Combine this info with the expiry date, encrypt it, and store it (either in the workbook’s hidden areas or the Windows registry). On each run, re-generate the hardware fingerprint, compare it to the stored one, then check the expiry. This prevents the workbook from being copied to another machine and used beyond the 120 days.
  Note: Some hardware IDs might be unavailable or change (e.g., if the user replaces a network card), so use a combination of 2-3 stable identifiers.

• Online validation (if network access is allowed)
  If the user’s environment permits internet access, have the VBA code ping a simple web endpoint (like a basic script or cloud function) on startup. The endpoint can check if the workbook’s unique ID (you can generate one and store it in the file) is still within the 120-day window. This lets you remotely extend expiry dates if needed, but it fails if the user is offline.
  Example HTTP request snippet:

  Dim http As Object
  Set http = CreateObject("MSXML2.XMLHTTP")
  http.Open "GET", "https://your-server.com/check-expiry?workbookId=ABC123", False
  http.Send
  If http.ResponseText = "expired" Then End
  

• Encrypted code segments
  Split your core VBA functionality into critical and non-critical parts. Encrypt the critical code (e.g., using Base64 encoding plus a secret key) and store it as a string in the workbook. On each run, only decrypt and execute this code if the expiry hasn’t passed. Once expired, skip decryption and exit the macro. This adds an extra layer—even if someone bypasses the date check, they still need to decrypt the core code to use it.

• Windows Registry storage
  On first run, write an encrypted expiry date and a unique identifier for the workbook to the user’s Windows Registry (under HKEY_CURRENT_USER to avoid admin rights). Every time the macro starts, read this registry entry, validate the expiry, and ensure the workbook ID matches. This makes it harder to transfer the workbook to another PC, as the registry entry won’t exist there.
  Example to write to registry:

  CreateObject("WScript.Shell").RegWrite _
      "HKCU\Software\YourApp\Expiry", EncryptDate(DateAdd("d", 120, Date)), "REG_SZ"
  

Remember, combining two or more methods (e.g., registry storage + hardware fingerprint) will significantly increase the effort needed to bypass the expiry lock. No method is perfect, but these approaches are way more robust than a simple date comparison in a visible cell.

内容的提问来源于stack exchange，提问作者Ken Kolb