| Previous | Next |
| SL_REMAPPING_SP_PUB_CRYPTO_NOT_BLOCK_ALIGNED | SL_REMAPPING_SP_PUB_CRYPTO_INVALID_SIGNATURE |
SL_REMAPPING_SP_PUB_CRYPTO_INVALID_SIGNATURELENGTH
What this Software Protection result isolates
0xC004D20D maps to SL_REMAPPING_SP_PUB_CRYPTO_INVALID_SIGNATURELENGTH. This result belongs to cryptographic processing inside the security processor and narrows the operation to the provider, algorithm, key, hash, signature and block-processing stage used to authenticate protected licensing data. In concrete terms, the signature byte count does not match the selected key and signature encoding.
This distinction matters because length validation fails before cryptographic signature comparison. A later “not licensed” state should not replace the first exact HRESULT in logs.
What to capture before recovery
- signature format, length and verification key
- provider and algorithm identifiers
- key type and key-material length
- cipher mode, block size and padding mode
- hash state and digest length
Where it sits in the licensing pipeline
Algorithm selection, key lookup, block formatting and signature verification are independent boundaries; a failure in one does not prove corruption at the others. To verify this, record algorithm, key size, signature format and supplied length without exposing private material.
Cryptographic material should be logged by identifier, length, hash or thumbprint rather than by exporting secret keys or plaintext protected data.
Related codes with different remedies
| Result | Different condition |
|---|---|
SL_REMAPPING_SP_PUB_CRYPTO_INVALID_SIGNATURE | Compared with this result, signature verification completed and the signature does not authenticate the supplied hash with the selected key. |
SL_REMAPPING_SP_PUB_CRYPTO_NOT_BLOCK_ALIGNED | Compared with this result, input length is not a whole multiple of the cipher block size for a mode that requires aligned data. |
SL_REMAPPING_SP_PUB_CRYPTO_INVALID_BLOCK | Compared with it, an RSA operation produced or received a block that fails the structural checks for the selected operation. |
A practical way to isolate the cause
- Start with the earliest event carrying it; later status queries may only report the resulting unlicensed or notification state.
- Use read-only inspection first: record algorithm, key size, signature format and supplied length without exposing private material.
Actions that usually destroy useful evidence
- Do not disable signature or padding validation to make the operation continue.
- Do not publish keys, decrypted license blobs or complete protected payloads in a support ticket.
Safe recovery direction
Obtain the complete signature in the encoding expected by the verification operation.
Representative case: A DER-encoded signature is passed to an API expecting a fixed-width raw representation.
Technical references
- CNG cryptographic primitive functions — reference for evidence collection and post-repair verification.
- BCryptHashData — technical contract for the subsystem producing it.
- BCryptVerifySignature — official platform context used to interpret it.
- Signing data with CNG — supported state, API or recovery information relevant to this HRESULT.
Looking for a different code? Search another status or error code.