How to remove 72h limitation ?
#76
Posted 23 June 2011 - 08:09 AM
I'm really sorry joakim, it's me, but i don't understand what i have to do exactly. Your explainations are not clear to me
#77
Posted 23 June 2011 - 08:25 AM
Inside the PE (Portable Executable) there is a checksum (it is part of the PE format specification).I thought i couldn't edit my old posts ... well, it's done.
I'm really sorry joakim, it's me, but i don't understand what i have to do exactly. Your explainations are not clear to me
This checksum is calculated on the contents of the actual .exe and "added" to it.
When you change even one bit value inside the .exe, the checksum will obviously change and won't match the "embedded" one, written there at "compile time".
There are tools that re-calculate the checksum after the modification(s) you made to the .exe and re-write the correct checksum to the .exe.
Here is some documentation:
http://www.codeproje...PEChecksum.aspx
and an example PE checksum modifier:
http://www.ryanvm.ne...opic.php?t=5381
Wonko
#78
Posted 23 June 2011 - 08:38 AM
#79
Posted 23 June 2011 - 08:38 AM
#80
Posted 23 June 2011 - 11:00 AM
good workaround to 72 (24) hours to remove the shutdown
An other option for shutdown with the Integrated shutdown option in peshell swapper who works in this case.By doing this the system cannot shutdown/reboot in a normal way because some api is deactivated as well as a relating rpc server not available. Only way of shutting down the system with these patched files, are to kill the shell process (or winlogon.exe). My test vm ran for 112 hours until I shut it down;
To return to Peshell, kill all explorer.exe process.
And an other (win7) option to return to peshell. Click the Start button. Press and hold the Ctrl and Shift keys, and right-click on an empty area in the Start menu. You’ll see a Popup menu containing the option "Exit Explorer".
Can you make a x64 version also of 72hour_patch.exe
In order to integrate it into a WB script or batch, is it possible to make a command line version, with for example:
72hour_patch.exe [path to wininit.exe] [nomsg]
72hour_patch.exe [path to wpeutil.exe] [nomsg]
Or can you share or PM your au3 source.
#81
Posted 23 June 2011 - 11:35 AM
#82
Posted 23 June 2011 - 11:36 AM
ThanksCommandline version can easily be done by adding 3-4 lines of code. I'll post the complete au3 source when home. It's just a very simple patcher.
#83
Posted 23 June 2011 - 12:27 PM
Here with taskkill but also with "pskill.exe explorer.exe" or "NirCmd.exe KillProcess explorer.exe" or others
Require_FileQ,taskkill.exe Add_Shortcut,StartMenu,..,#$pSystemRoot#$p\system32\taskkill.exe,"Exit Explorer",#$pSystemRoot#$p\system32,"/f /im explorer.exe",#$pSystemRoot#$p\System32\shell32.dll#$c112
#84
Posted 23 June 2011 - 12:42 PM
Can you explain why you would need to kill explorer?
#85
Posted 23 June 2011 - 01:17 PM
I checked all shutdown option in Win7PE SE and only the built-in shutdown option in pe shell swapper works well with the two patched files (IMHO better than kill winlogon).
and in this project, if you kill the process explorer.exe, you automatically returns to peshell.
#86
Posted 23 June 2011 - 03:59 PM
#87
Posted 24 June 2011 - 10:20 PM
#88
Posted 24 June 2011 - 10:39 PM
Thank you for the source (with the file parameter already on the command line), and the x86 version seems to work in x64 tooHere it is attached. I am sure you can improve it..
I just added an additional parameter [-log] to do the patch in silent mode (no information msgbox), to dialogue with WB (result of patch) and for not stop building.
Here script + au3
72hours.7z 352.29KB 101 downloads
Not me. Good question .Did anybody even try with a clean (unpatched) system (to verify the existence of the limit)?
#89
Posted 29 June 2011 - 08:16 AM
may i suggest a simple stupid thing : suspend the suspected process (using pstools or psexplorer) thus giving it 0% of processing...
could this be of any use against this countdown-of-death ;-) ?
#90
Posted 03 July 2011 - 11:41 AM
I don't think it makes any difference because system shutdown is probably not initiated by (or through) the shutdown.exe. System shutdown from WinPE is initiated using winapi and the named pipe (that the wininit.exe patch fixed). Did you test/verify the stuff?Hi,
may i suggest a simple stupid thing : suspend the suspected process (using pstools or psexplorer) thus giving it 0% of processing...
could this be of any use against this countdown-of-death ;-) ?
#91
Posted 03 July 2011 - 05:21 PM
#92
Posted 03 July 2011 - 06:55 PM
joakim, do you know, if your patch 'fixes' the sending or the recieving end of the pipe?
It's the server end pipe that is modified and messes up the shutdown. I still don't know exactly how the "client" initiates the shutdown, or even where the "client" originates from.. All I know is that the communication between client and server is broken (because client cannot find server) and thus prevents the system shutdown. So I guess the receiving part is the answer.
#93
Posted 03 July 2011 - 09:33 PM
#94
Posted 04 July 2011 - 06:55 AM
I don't think it makes any difference because system shutdown is probably not initiated by (or through) the shutdown.exe. System shutdown from WinPE is initiated using winapi and the named pipe (that the wininit.exe patch fixed). Did you test/verify the stuff?
No, i did not verify it. By the way, i did not mentioned "shutdown.exe" as the halting process ; that one has to be found by trial and error, freezing one or the other. There were times where i successfuly used this procedure for other purposes, so the method seems to myself still valid.
Basicaly, there is always an api involved and my little intervention pointed only to freeze the api-calling process.
Cheers
#95
Posted 21 July 2011 - 02:31 AM
Got a request from OP about this post.
You can stop that limit cleanly without patching by using Sysinternals Process Explorer to suspend the winlogon.exe and winint.exe processes.
Now, exiting your shell won't reboot the machine, so you have to use something like PE Shell Swapper. or a command-line one I made called PEShutdown.
@Taupezen
Not a stupid thing, it's the right one.
@joakim
Good thinking.
Best regards,
http://pierre-mounir.freehostia.com/
#96
Posted 21 July 2011 - 06:00 AM
Regarding process explorer and during the work on the patch, I found yet another way. In process explorer you can also kill the handles to the named pipes in question. Downside (as far as I know) is that process explorer cannot be easily automated. The command line handle.exe was also not successful on my test.
Btw, I still have a feeling that 2 other ways may be an even more clean approach (not requiring manual intervention);
1. Using the api mentioned earler in this thread.
2. Interrogate system uptime, as present in the idle timer.
But if not, at least we have working solutions.
Edit: Suppose I could make an au3 using NtSuspendProcess, and thus easily automate it and prevent patching.
Edit2. Nevermind, PsSuspend.exe might be the solution.
#97
Posted 21 July 2011 - 08:30 AM
Can anyone do a test > 72 hours. If this is enough.
With the current patch of Joakim (the previous way to stop does not work) and a right solution to shutdown is in fact PE Shell Swapper (still relevant today ) or peshutdown.
where can I download the latest version of the command-line PEShutdown ? I have a version but I do not know if it is up to date.
edit:
With the 2 process suspended, wpeutil.exe shutdown, shutdownPE or psshutdown.exe does not work, as for the patch.
The command-line PEShutdown seems the right solution .
#98
Posted 21 July 2011 - 01:19 PM
We can enable or disable the limit of 72 hours at startup or(and) with shortcuts inside Win7PE
72hours.7z 119.75KB 77 downloads
72hours.jpg 163.47KB 65 downloads
Not tested the limit of 72 hours, let me know
#99
Posted 13 August 2012 - 10:51 PM
Takes just 1 parameter which is expected to be the name of the target process including its extension. Suspending notepad would require a commandline like this;
NtSuspendProcess.exe notepad.exe
(can upload it in download section too)
Edit: uploaded. http://reboot.pro/fi...suspendprocess/
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users