You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Working timebomb with nulled expiration date at SharedData on 6.2.7880 #5
This build, while initially looks similar to #2 , it actually differs from it by still posessing a working timebomb (according to @JannGold) as documented in #4 . Further investigation is required and will take place after I finish smoking while this build installs again.
One guessing of me is kernel internally still holds an expiration date while it's nulled on SharedData, which I have a solution for (albeit not perfect, but better than nothing).
Will any Win8 builds log me off when there is no activation, but the timebomb is disabled?
Logging off when unactivated is removed at Vista SP1 in retail builds, which well predates Windows 8 development. 7880 didn't log me off, and later builds which photos posted at README.md doesn't either while having timebomb actually removed.
7880 just crashed with 0x109 BSOD as well. So the issue is indeed similar.
0x109 is caused by PatchGuard, basically a mechanism to prevent unauthorized patches to kernel. It's actually the other side of the medal in case of #2, with the first side being the timebomb killing itself, hence why #2 is closed as wontfix. This build though differs by still having a working timebomb according to you saying that it still BSODs after two hours.
When I did get the 2 hour BSOD. it was using something else, sorry for the confusion. I can try it with this driver. I will keep it on for two hours to check.
When I did get the 2 hour BSOD. it was using something else, sorry for the confusion.
If it was 0x98 END_OF_NT_EVALUTION_PERIOD, it is by timebomb.
I can try it with this driver. I will keep it on for two hours to check.
Driver has no effect so you can try with just base system running at current date, after 2 to 2.5 hours it should bugcheck 0x98 if it has a working timebomb.
The way I got 0x98 was trying the "replacing spp files" method. It did not work. The timebomb appears to work in this build. I have not checked with the kernel driver.
I reinstalled with correct date and then set the date to current, and unlike #4 (comment) it still has an expiration date. Now I wonder if installing at current date breaks it entirely...
I have a feeling that just reinstalling at current date effectively breaks the timebomb without need to do anything else. Because when I forgot the set the date back, it didn't have any expiration date set, but when I installed at a date before expiration and then set the date to current, it kept being there.
I also reinstalled at current date to make sure, and it is indeed gone. This time I also checked the internal structures from debugger and they were also zero, proving that timebomb is gone and refuting my guessing at the top.
Activity
JannGold commentedon Oct 5, 2025
Will any Win8 builds log me off when there is no activation, but the timebomb is disabled?
NevermindExpress commentedon Oct 5, 2025
Logging off when unactivated is removed at Vista SP1 in retail builds, which well predates Windows 8 development. 7880 didn't log me off, and later builds which photos posted at README.md doesn't either while having timebomb actually removed.
JannGold commentedon Oct 5, 2025
7880 just crashed with 0x109 BSOD as well. So the issue is indeed similar.
NevermindExpress commentedon Oct 5, 2025
0x109 is caused by PatchGuard, basically a mechanism to prevent unauthorized patches to kernel. It's actually the other side of the medal in case of #2, with the first side being the timebomb killing itself, hence why #2 is closed as wontfix. This build though differs by still having a working timebomb according to you saying that it still BSODs after two hours.
JannGold commentedon Oct 5, 2025
When I did get the 2 hour BSOD. it was using something else, sorry for the confusion. I can try it with this driver. I will keep it on for two hours to check.
NevermindExpress commentedon Oct 5, 2025
If it was 0x98 END_OF_NT_EVALUTION_PERIOD, it is by timebomb.
Driver has no effect so you can try with just base system running at current date, after 2 to 2.5 hours it should bugcheck 0x98 if it has a working timebomb.
JannGold commentedon Oct 5, 2025
The way I got 0x98 was trying the "replacing spp files" method. It did not work. The timebomb appears to work in this build. I have not checked with the kernel driver.
NevermindExpress commentedon Oct 5, 2025
I reinstalled with correct date and then set the date to current, and unlike #4 (comment) it still has an expiration date. Now I wonder if installing at current date breaks it entirely...
JannGold commentedon Oct 5, 2025
NevermindExpress commentedon Oct 5, 2025
I have a feeling that just reinstalling at current date effectively breaks the timebomb without need to do anything else. Because when I forgot the set the date back, it didn't have any expiration date set, but when I installed at a date before expiration and then set the date to current, it kept being there.
JannGold commentedon Oct 5, 2025
I can try right now. Let me wait for this to install and I will go from here. I will just make sure to disable automatic restart.
NevermindExpress commentedon Oct 6, 2025
I also reinstalled at current date to make sure, and it is indeed gone. This time I also checked the internal structures from debugger and they were also zero, proving that timebomb is gone and refuting my guessing at the top.
JannGold commentedon Oct 6, 2025
I left it for 6 hours like that and it is still going.
NevermindExpress commentedon Oct 6, 2025
Great then. I'm closing this as solved. I also updated readme last night.