Feature: Remote Implant Migration & Cross-Server Handover

[skoveit]

PR #2175 introduced the reconfig command, but it was limited to cases where the Host remained the same. This is because Sliver requires specific internal state and security data to trust incoming beacons.

this PR resolves this limitation by allowing the import/export of tables:

• implant_configs, implant_builds, implant_c2
• resource_ids (encoders included), certificates, key_values

Export specific implants via --name or all of them at once using --all.

Key Changes:

• Updated the database schema to allow non-unique entries in key_values.key.

we could enforce uniqueness by appending a unique postfix (e.g. an ID) to the keys and utilizing Regex for lookups if preferred.

• Refactored helpers to support writing/searching from multiple keys.

---

Note: this currently only works with HTTP/S beacons.

demo.mp4

[moloch--]

I'll have to think this one through, we want very strong security guarantees about implant key material so I'm apprehensive about adding features like this since they add more avenues of mishandling that key material.

[skoveit]

@moloch-- I believe this level of flexibility is essential for complex operations and infrastructure resilience.

That said, I'm fully open to refactoring the implementation to meet Sliver's standards. To mitigate the risk of mishandling key material, I can add password-protected (AES) exports so the keys are never in plaintext.

Would you prefer a specific encryption wrapper for the exported data, or do you have a different architectural preference for maintaining trust during handover?

[moloch--]

Ahh just give me a couple days to think it thru, I understand this could be a useful feature too!

[moloch--]

So I'm leaning towards we don't need a dedicated feature for this, it's cleaner and more future proof to just copy the entire sliver.db sqlite database, which should work today.

[skoveit]

that is a clever way to move it without leaking the private keys, thank you! If we're strictly optimizing for security guarantees, maybe we should even discourage manual DB migrations because "they add more avenues of mishandling that key material".
But I'll respect the design decision and keep this forked for those who need a granular, safer encrypted handover without the risks of an 'all-or-nothing' DB swap. Cheers!