Emergency Revert and Re-Enroll doesn't work with Icarus unenrollment and likely more exploits.

[Eboi47]

Describe the bug
When using the emergency revert and Re-Enroll option in mush, chrome OS only reboots rather than changing anything.

To Reproduce
Steps to reproduce the behavior:

1. Go to mush via CTRL+ALT+T
2. Press the '8' key for emergency Revert and Re-Enroll
3. Press enter
4. System will reboot without change.

Expected behavior
Murkmod should delete itself and Re-Enroll the Chromebook.

Screenshots
I forgot to screenshot the terminal and chrome OS broke because it automatically updated, preventing dev mode. I do remember that it said most processes failed.

System (please complete the following information):

• Board [dedede]
• Version [v124]
• Installation method used [devmode installer]

Additional context
Due to this being a common issue among unenrollment exploits, I believe the issue stems from how newer exploits function. Many of them destroy all of the data on a certain file which is used in enrollment.

[rainestorme]

I haven't been following any new exploits since SH1mmer mostly broke, so I have no idea how these ones work internally and therefore can't do much myself. I welcome other contributions, but I won't be fixing this myself.

[Eboi47]

Most of the new exploits unenroll by destroying all data on /dev/mmcblk1p1, which likely contains the data used to enroll the Chromebook. I assume SH1MMER uses a different method to unenroll, which is what Murkmod and Fakemurk were built for. Fixing this would simply require backing up different data for re-enrolling.

[rainestorme]

I welcome PRs 🤷

[xXMariahScaryXx]

this is hilariously skidded (from eboi, not raine). will explain later

[HarryJarry1]

I haven't been following any new exploits since SH1mmer mostly broke, so I have no idea how these ones work internally and therefore can't do much myself. I welcome other contributions, but I won't be fixing this myself.

There should be no difference. Icarus removes fwmp via using a shim to trust certificates externally signed (the actual exploit), and a server is used, acting like the m.google.com server (where enrollment packets are sent). This allows the Chromebook to believe the server said to unenroll, and will remove fwmp and other dev mode blocking procedures.

that being said, this should not impact murkmod working. It is likely due to a newer update that this issue occurs on, and people are just using the newer unenrollment exploits as sh1mmer has been fixed for years

[xXMariahScaryXx]

Most of the new exploits unenroll by destroying all data on /dev/mmcblk1p1, which likely contains the data used to enroll the Chromebook. I assume SH1MMER uses a different method to unenroll, which is what Murkmod and Fakemurk were built for. Fixing this would simply require backing up different data for re-enrolling.

lmao if it were that easy, kv6 (and eventually kv7) unenrollment would be possible (even while keyrolled, baddieapple is a thing but it's not public yet) by just booting a shim and doing mkfs.ext4 /dev/mmcblk0p1
enrollment is checked by 2 things, serial number and device secret, both of which are in read-only VPD. device secret is identical for all chromebooks in an organization, while serial number obviously varies. no unenrollment exploits mess with any of these (except i guess you could edit them if you do pencil method, but flashing gbb flags is easier).

back to the original issue now.

and chromeOS broke because it automatically updated

you can prevent updates by just deleting the root and kern not in use by chromeOS.

system will reboot with no change

it's possible that something may be actually broken with the script, but it doesn't matter what unenrollment exploit was used because all it does is switch kernel priority back to the kernel that isn't murkmodded, block devmode, and reset gbb flags.

[HarryJarry1]

Most of the new exploits unenroll by destroying all data on /dev/mmcblk1p1, which likely contains the data used to enroll the Chromebook. I assume SH1MMER uses a different method to unenroll, which is what Murkmod and Fakemurk were built for. Fixing this would simply require backing up different data for re-enrolling.

lmao if it were that easy, kv6 (and eventually kv7) unenrollment would be possible (even while keyrolled, baddieapple is a thing but it's not public yet) by just booting a shim and doing mkfs.ext4 /dev/mmcblk0p1 enrollment is checked by 2 things, serial number and device secret, both of which are in read-only VPD. device secret is identical for all chromebooks in an organization, while serial number obviously varies. no unenrollment exploits mess with any of these (except i guess you could edit them if you do pencil method, but flashing gbb flags is easier).

back to the original issue now.

and chromeOS broke because it automatically updated
you can prevent updates by just deleting the root and kern not in use by chromeOS.

system will reboot with no change
it's possible that something may be actually broken with the script, but it doesn't matter what unenrollment exploit was used because all it does is switch kernel priority back to the kernel that isn't murkmodded, block devmode, and reset gbb flags.

enrollment is found by rlz_code, serial number, and stable device secret

[xXMariahScaryXx]

right i forgot about rlz code, thanks for pointing that out