98 replies to this topic

[joakim]

I can report that my WinPE 3.0 is still running after 80 hours. That's with patched wininit.exe and wpeutil.dll. I am not going to run more test on this as it takes just too much time..

[neeko]

Ok, could you post those two files, so i'll be able to fix it

If it works, thanks a lot everyone !

Edit : WoW ! i'm an advanced user now ^^

[joakim]

If I remember correctly (considering it was more than 3 days ago and done in a hurry), it was 1 ascii string per file; "shutdown".

[neeko]

I'm sorry but i don't know how to patch it by myself :s

[joakim]

OK, so I will post a more detalied description when I am back home and certain about what was actually done to the files.

[neeko]

That would be great

[Icecube]

tickcntw of Olof Lagerkvist uses QueryPerformanceCounter and QueryPerformanceFrequency to calculate the system uptime:
http://www.ltr-data.se/opencode.html/

MSDN page about QueryPerformanceCounter:
http://msdn.microsof...4(v=vs.85).aspx

I don't have Windows 7 files at hand, so I can't check if those APIs are used or not.

[MedEvil]

So far the main problem is, that we do not have any verification that there even is a 72hour limit in Win7PE_SE and already trying to fix it.

Does anyone have an idea, how to set the uptime to something like 71hours?

[neeko]

The limitation exists, because it triggered several reboots on PXE PCs at work.

But, no idea about how it works.

[MedEvil]

Strange that you're now sure, neeko. A few days ago, you've said, that you were just told, that the PE had restarted after a few days and didn't even know the uptime.

I had full XP and Win7 restart on me, after less than 24 hours. That doesn't mean, that there is a limit, that doesn't allow a Windows to run longer than 24 hours. OS do crash sometimes.

I wouldn't go as far as to ask, that as proof at least 2-3 PE have to restart after the same uptime. It would be good enough for me, if the reset was verified to happen, exactly after 72 hours uptime.

[neeko]

It happened 2 or 3 times in a raw. I wasn't sure about the uptime, but whatever the duration, it's too short.

Microsoft itself tell that WinPE has a duration limitation, so ...

[Wonko the Sane]

I wouldn't go as far as to ask, that as proof at least 2-3 PE have to restart after the same uptime. It would be good enough for me, if the reset was verified to happen, exactly after 72 hours uptime.

Boy, do I hate this deja-vu feeling...
http://reboot.pro/7646/


Wonko

[MedEvil]

Boy, do I hate this deja-vu feeling...

Not as much as me!
Can you confirm from a own test that (PE of your choice) does reboot after 24 / 72 / XX hours? No?
Do you have at least a problem with the supposedly limited uptime? No?
What business do you have, annoying people in this thread? Go play somewhere else!

[MedEvil]

Microsoft itself tell that WinPE has a duration limitation, so ...

Yes and M$ also tells that PE1 have a 24hour limit, still doesn't mean that NaughtyPE will reboot after 24 hours, despite being a PE1.

So far we only have hearsay that such a limit exists. Joakim did not get a reboot and i couldn't force an early reboot.

[joakim]

I still have not tried running a clean WinPE 3.0 for a long time, but assume that MS' statement about the 72 hour limit is correct.

As said earlier I tried with patched wininit.exe and wpeutil.dll. Meaning I renamed the ascii strings (all of them). 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;



Patcher;
http://www.mediafire...2hour_patch.zip

That's for x86, but you can easily do it yourself. Just remember to update the checksum in the pe header after renaming the strings..

[Wonko the Sane]

Can you confirm from a own test that (PE of your choice) does reboot after 24 / 72 / XX hours? No?

Yes.
A "standard" PE 1.x will reboot after 24 h if not "fixed".

Do you have at least a problem with the supposedly limited uptime? No?

No.

What business do you have, annoying people in this thread?

No, my part time job is annoying people on *any* thread . (still better than the job about re-issuing the same otiose questions you could have verified yourself allright, BTW)

@joakim
Nice work !


Wonko

[sbaeder]

No, my part time job is annoying people on *any* thread .

While you are better at it that I am I consider it a part of my "job" as well

@joakim
Nice work !


Wonko

I guess this is OK - to clap for someone who is creating "warez" - i.e. on purpose circumventing the intent of the creator of the software by means of a binary modification of their code...But I would have expected better from you

On the other hand, KNOWLEDGE about how a particular thing is implemented isn't a bad thing..."Guns don't kill people, people kill people"...


Scott

[Wonko the Sane]

I guess this is OK - to clap for someone who is creating "warez" - i.e. on purpose circumventing the intent of the creator of the software by means of a binary modification of their code...But I would have expected better from you

Well, NO.

WAREZ is unauthorized redistribution of copyrighted material.

This is "hacking", which can be perfectly legal, BTW.

There are specific provisions by the Law in most countries that allow - in certain cases - this kind of patching.

This might be a valid example:
http://reboot.pro/7646/page__st__9

Please also note how the 72 hour limit is NOT part of the EULA:
http://www.msfn.org/...up/page__st__36
http://www.msfn.org/...up/page__st__38

And can hardly be defined a "technical limitation".

Since the purpose of the PE and of WAIK is EXPRESSly that

for purposes of diagnosing and recovering Windows operating system software. For the avoidance of doubt, you may not use the Windows Pre-Installation Environment for any other purpose, including without limitation as a general operating system, as a thin client or as a remote desktop client.

The 72 hours limit is an ARTIFICIAL (NOT technical) limit that may prevent in some cases the use of the tool for the ONLY scope for which it is licensed, and as such is IMHO well covered by provisions aimed to leave some "freedom" to users.

A related thread you may have missed:
http://reboot.pro/9627/

Now an interesting point is whether the actual WAIK_License.rtf is "covered by itself" and thus by attaching it on MSFN I actually posted "WAREZ"


Wonko

[sbaeder]

Well, NO.

WAREZ is unauthorized redistribution of copyrighted material.

This is "hacking", which can be perfectly legal, BTW.

As always, I stand corrected in a tighter definition of the terms...To me (in a broad, loose sense), WAREZ means copyright infringment, and not just redistribution...and it refers to the SW (noun), not the verb/action of redistribution...But point taken.

There are specific provisions by the Law in most countries that allow - in certain cases - this kind of patching.

This might be a valid example:
http://reboot.pro/7646/page__st__9

Yes - it MIGHT be legal, and even if not explicitly part of the EULA, it is still against what I would call the "spirit" of the agreement...i.e. MS wants to limit how long any given PE can remain "up"...

And can hardly be defined a "technical limitation".

Since the purpose of the PE and of WAIK is EXPRESSly that

The 72 hours limit is an ARTIFICIAL (NOT technical) limit that may prevent in some cases the use of the tool for the ONLY scope for which it is licensed, and as such is IMHO well covered by provisions aimed to leave some "freedom" to users.

You say PO-TAY-TOE and I say PO-TAH-TOE...technical IMHO doesn't mean that it has to be that way due to the laws of Physics/Nature, but that it was something conscious or unconscious put in by the author to help make sure that his wishes are followed...A Pre-Environment is not a full OS...and a limitation like this it is reasonable to expect that this was intended behavior, and not just an accident on the part of M$

But (again as always)...I love the banter and sharing different points of view on a complex issue that has many, many shades of gray...

Over and out (on this one...)
Scott

[Wonko the Sane]

You say PO-TAY-TOE and I say PO-TAH-TOE...

Spoiler

Wonko

[MedEvil]

Just for the record, if the guys at M$ wouldn't create Windows in such a way, that one has to decide, if he want's a full OS or an OS that can run on any hardware, without filling itself up with garbage. Noone would care the least for this striped down Windows, they call PE.

[joakim]

Calling it warez is ridiculous. Why did not anybody claim TheTruth to distrubute warez then. His shell implementation effectively achieved the same (ie remove limit). However, I do understand the greyzone locationof it all..

Now to the more interesting part;
As the shutdown procedure did not forcibly kill any process, I believe that we can programmatically create a solution using the winapi. I have to be honest enough to say it will not be a first priority for me right now, and not second either... So possible solutions I can think of right now;
- Adjust the timer
- intercept the shutdown api
- modify the namedpipe

[neeko]

If i can say something ... afterall, it's my post.

At work, our use of WinPE is exactly how Microsoft imagined it : boot from network by PXE. But in some cases, we need not to reboot a computer several days long. And that stupid limitation prevents it.

I think i can modify it, according to the fact that :
- Microsoft didn't really forbid it
- It's not used in a different way

I don't know if you understand everything i say, nevermind

joakim : can you explain what you're talking about with "checksum in the pe header" ? I know what a checksum is, of course, but not the pe header.

Thanks

[joakim]

The checksum in the pe header is a checksum calculated on the "image" inside the exe. The checksum is located in the header of an exe/dll (more specifically called the pe header). PE in this context stands Portable Executable and is not related to PE as in WinPE (Preboot Environment). Boot related executables are checksum evaluated during boot, thus it needs to be correct in the pe header (which the patcher solves of course). I may add that you can in fact also boot with bad checksum in the boot files, but then you must modify code in both bootmgr and winload.exe.

Maybe you should adjust the title of the thread and switch 24 with 72..

[Wonko the Sane]

Maybe you should adjust the title of the thread and switch 24 with 72..

.... or make evident that it is expressed in boot-land reboot.pro time, Latin time (though that would make 48 days ).
Maybe "fast latin time"?


Wonko