Do the sedutil-cli revert commands also reset the given SID?
up vote
1
down vote
favorite
In sedutil-cli a
sedutil-cli --PSIDrevert <password> <device>
"Reset the device to it’s factory defaults using the SID password. If the locking SP is active this command ERASES ALL DATA, requires the SID password" By which I assume it returns all the SIDs to the MSID (manufacturer default, queryable from interface), and creates a new DEK if the locking system was in use. That's the easy one.
My question is do the other revert commands return the given pasword to the MSID? For example:
sedutil-cli --reverttper <password> <device>
Says it 'Reset(s) the device to it’s factory defaults using the SID password. If the locking SP is active this command ERASES ALL DATA, requires the SID password' Does this revert the LockingSP and AdminSP SIDs back to MSID as well, or do they keep their present values. Similarly does:
sedutil-cli --revertLockingSP <password> <device>
just deactivate the locking system (and cryptographically wipe any locked data), or does it wipe the SID/password for the locking SP as well? These would make the jargon make more sense (reverting a system to it's starting state) but that doesn't make it true. Being able to return to a wiped unlocked state with one or two steps given the password would greatly simplify re-provisioning.
linux opal
asked Nov 27 at 0:55
davolfman
61
add a comment |
up vote
1
down vote
favorite
In sedutil-cli a
sedutil-cli --PSIDrevert <password> <device>
"Reset the device to it’s factory defaults using the SID password. If the locking SP is active this command ERASES ALL DATA, requires the SID password" By which I assume it returns all the SIDs to the MSID (manufacturer default, queryable from interface), and creates a new DEK if the locking system was in use. That's the easy one.
My question is do the other revert commands return the given pasword to the MSID? For example:
sedutil-cli --reverttper <password> <device>
Says it 'Reset(s) the device to it’s factory defaults using the SID password. If the locking SP is active this command ERASES ALL DATA, requires the SID password' Does this revert the LockingSP and AdminSP SIDs back to MSID as well, or do they keep their present values. Similarly does:
sedutil-cli --revertLockingSP <password> <device>
just deactivate the locking system (and cryptographically wipe any locked data), or does it wipe the SID/password for the locking SP as well? These would make the jargon make more sense (reverting a system to it's starting state) but that doesn't make it true. Being able to return to a wiped unlocked state with one or two steps given the password would greatly simplify re-provisioning.
linux opal
asked Nov 27 at 0:55
davolfman
61
Additionally github.com/Drive-Trust-Alliance/sedutil/wiki/Remove-OPAL gives a procedure for removing opal by doing a no-erase revert of the locking SP followed by a reverttper. and says "When this is finished the drive will be in a non-opal managed state." That seems to be evidence in favor of this being true. I'm still trying to procure a spare drive to test with.
– davolfman
Nov 27 at 17:42
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
In sedutil-cli a
sedutil-cli --PSIDrevert <password> <device>
"Reset the device to it’s factory defaults using the SID password. If the locking SP is active this command ERASES ALL DATA, requires the SID password" By which I assume it returns all the SIDs to the MSID (manufacturer default, queryable from interface), and creates a new DEK if the locking system was in use. That's the easy one.
My question is do the other revert commands return the given pasword to the MSID? For example:
sedutil-cli --reverttper <password> <device>
Says it 'Reset(s) the device to it’s factory defaults using the SID password. If the locking SP is active this command ERASES ALL DATA, requires the SID password' Does this revert the LockingSP and AdminSP SIDs back to MSID as well, or do they keep their present values. Similarly does:
sedutil-cli --revertLockingSP <password> <device>
just deactivate the locking system (and cryptographically wipe any locked data), or does it wipe the SID/password for the locking SP as well? These would make the jargon make more sense (reverting a system to it's starting state) but that doesn't make it true. Being able to return to a wiped unlocked state with one or two steps given the password would greatly simplify re-provisioning.
linux opal
asked Nov 27 at 0:55
davolfman
61
In sedutil-cli a
sedutil-cli --PSIDrevert <password> <device>
"Reset the device to it’s factory defaults using the SID password. If the locking SP is active this command ERASES ALL DATA, requires the SID password" By which I assume it returns all the SIDs to the MSID (manufacturer default, queryable from interface), and creates a new DEK if the locking system was in use. That's the easy one.
My question is do the other revert commands return the given pasword to the MSID? For example:
sedutil-cli --reverttper <password> <device>
Says it 'Reset(s) the device to it’s factory defaults using the SID password. If the locking SP is active this command ERASES ALL DATA, requires the SID password' Does this revert the LockingSP and AdminSP SIDs back to MSID as well, or do they keep their present values. Similarly does:
sedutil-cli --revertLockingSP <password> <device>
just deactivate the locking system (and cryptographically wipe any locked data), or does it wipe the SID/password for the locking SP as well? These would make the jargon make more sense (reverting a system to it's starting state) but that doesn't make it true. Being able to return to a wiped unlocked state with one or two steps given the password would greatly simplify re-provisioning.
linux opal
linux opal
asked Nov 27 at 0:55
davolfman
61
asked Nov 27 at 0:55
davolfman
61
asked Nov 27 at 0:55
davolfman
61
asked Nov 27 at 0:55
davolfman
61
asked Nov 27 at 0:55
davolfman
61
61
Additionally github.com/Drive-Trust-Alliance/sedutil/wiki/Remove-OPAL gives a procedure for removing opal by doing a no-erase revert of the locking SP followed by a reverttper. and says "When this is finished the drive will be in a non-opal managed state." That seems to be evidence in favor of this being true. I'm still trying to procure a spare drive to test with.
– davolfman
Nov 27 at 17:42
add a comment |
Additionally github.com/Drive-Trust-Alliance/sedutil/wiki/Remove-OPAL gives a procedure for removing opal by doing a no-erase revert of the locking SP followed by a reverttper. and says "When this is finished the drive will be in a non-opal managed state." That seems to be evidence in favor of this being true. I'm still trying to procure a spare drive to test with.
– davolfman
Nov 27 at 17:42
Additionally github.com/Drive-Trust-Alliance/sedutil/wiki/Remove-OPAL gives a procedure for removing opal by doing a no-erase revert of the locking SP followed by a reverttper. and says "When this is finished the drive will be in a non-opal managed state." That seems to be evidence in favor of this being true. I'm still trying to procure a spare drive to test with.
– davolfman
Nov 27 at 17:42
Additionally github.com/Drive-Trust-Alliance/sedutil/wiki/Remove-OPAL gives a procedure for removing opal by doing a no-erase revert of the locking SP followed by a reverttper. and says "When this is finished the drive will be in a non-opal managed state." That seems to be evidence in favor of this being true. I'm still trying to procure a spare drive to test with.
– davolfman
Nov 27 at 17:42
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
By experimentation if I use an installer as a live system and run:
sedutil-cli --revertnoerase oldpassword /dev/sda
sedutil-cli --reverttper oldpassword /dev/sda
It puts the drive into a state where I can run
sedutil-cli --initialsetup newpassword /dev/sda
Since initialsetup wasn't given the old password, the only way this would work is if the SIDs had been reset to the MSID that it could pull from the interface.
However, when running:
sedutil-cli --revertnoerase newpassword /dev/sda
sedutil-cli --activateLockingSP oldpassword /dev/sda
sedutil-cli --activateLockingSP newpassword /dev/sda
Only the second activation works. So --revertnoerase keeps the LockingSP SID and just deactivates it, only working if you know the existing password instead of setting a new one.
So, on a system where the AdminSP SID is known, but the drive is too deeply embedded to get easy physical access, the drive can be reverted using the password.
answered Nov 28 at 18:14
davolfman
61
New contributor
davolfman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
By experimentation if I use an installer as a live system and run:
sedutil-cli --revertnoerase oldpassword /dev/sda
sedutil-cli --reverttper oldpassword /dev/sda
It puts the drive into a state where I can run
sedutil-cli --initialsetup newpassword /dev/sda
Since initialsetup wasn't given the old password, the only way this would work is if the SIDs had been reset to the MSID that it could pull from the interface.
However, when running:
sedutil-cli --revertnoerase newpassword /dev/sda
sedutil-cli --activateLockingSP oldpassword /dev/sda
sedutil-cli --activateLockingSP newpassword /dev/sda
Only the second activation works. So --revertnoerase keeps the LockingSP SID and just deactivates it, only working if you know the existing password instead of setting a new one.
So, on a system where the AdminSP SID is known, but the drive is too deeply embedded to get easy physical access, the drive can be reverted using the password.
answered Nov 28 at 18:14
davolfman
61
New contributor
davolfman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
up vote
0
down vote
By experimentation if I use an installer as a live system and run:
sedutil-cli --revertnoerase oldpassword /dev/sda
sedutil-cli --reverttper oldpassword /dev/sda
It puts the drive into a state where I can run
sedutil-cli --initialsetup newpassword /dev/sda
Since initialsetup wasn't given the old password, the only way this would work is if the SIDs had been reset to the MSID that it could pull from the interface.
However, when running:
sedutil-cli --revertnoerase newpassword /dev/sda
sedutil-cli --activateLockingSP oldpassword /dev/sda
sedutil-cli --activateLockingSP newpassword /dev/sda
Only the second activation works. So --revertnoerase keeps the LockingSP SID and just deactivates it, only working if you know the existing password instead of setting a new one.
So, on a system where the AdminSP SID is known, but the drive is too deeply embedded to get easy physical access, the drive can be reverted using the password.
answered Nov 28 at 18:14
davolfman
61
New contributor
davolfman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
up vote
0
down vote
up vote
0
down vote
By experimentation if I use an installer as a live system and run:
sedutil-cli --revertnoerase oldpassword /dev/sda
sedutil-cli --reverttper oldpassword /dev/sda
It puts the drive into a state where I can run
sedutil-cli --initialsetup newpassword /dev/sda
Since initialsetup wasn't given the old password, the only way this would work is if the SIDs had been reset to the MSID that it could pull from the interface.
However, when running:
sedutil-cli --revertnoerase newpassword /dev/sda
sedutil-cli --activateLockingSP oldpassword /dev/sda
sedutil-cli --activateLockingSP newpassword /dev/sda
Only the second activation works. So --revertnoerase keeps the LockingSP SID and just deactivates it, only working if you know the existing password instead of setting a new one.
So, on a system where the AdminSP SID is known, but the drive is too deeply embedded to get easy physical access, the drive can be reverted using the password.
answered Nov 28 at 18:14
davolfman
61
New contributor
davolfman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
By experimentation if I use an installer as a live system and run:
sedutil-cli --revertnoerase oldpassword /dev/sda
sedutil-cli --reverttper oldpassword /dev/sda
It puts the drive into a state where I can run
sedutil-cli --initialsetup newpassword /dev/sda
Since initialsetup wasn't given the old password, the only way this would work is if the SIDs had been reset to the MSID that it could pull from the interface.
However, when running:
sedutil-cli --revertnoerase newpassword /dev/sda
sedutil-cli --activateLockingSP oldpassword /dev/sda
sedutil-cli --activateLockingSP newpassword /dev/sda
Only the second activation works. So --revertnoerase keeps the LockingSP SID and just deactivates it, only working if you know the existing password instead of setting a new one.
So, on a system where the AdminSP SID is known, but the drive is too deeply embedded to get easy physical access, the drive can be reverted using the password.
answered Nov 28 at 18:14
davolfman
61
New contributor
davolfman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered Nov 28 at 18:14
davolfman
61
New contributor
davolfman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered Nov 28 at 18:14
davolfman
61
answered Nov 28 at 18:14
davolfman
61
61
New contributor
davolfman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
davolfman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
davolfman is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1378602%2fdo-the-sedutil-cli-revert-commands-also-reset-the-given-sid%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Additionally github.com/Drive-Trust-Alliance/sedutil/wiki/Remove-OPAL gives a procedure for removing opal by doing a no-erase revert of the locking SP followed by a reverttper. and says "When this is finished the drive will be in a non-opal managed state." That seems to be evidence in favor of this being true. I'm still trying to procure a spare drive to test with.
– davolfman
Nov 27 at 17:42