Timestamp and parameter issues in most Longhorn builds

Discuss Windows Vista/Server 2008 to Windows 10.
Post Reply
Lucas Brooks
Posts: 773
Joined: Sat Oct 20, 2018 11:37 am
Contact:

Timestamp and parameter issues in most Longhorn builds

Post by Lucas Brooks »

Disclaimer: Everything in this post are based on my personal experiences, observations and opinions. This does not target anyone, there is no intention to disrespect anyone's efforts and this is merely for informational purposes. Everything I am going to talk about only applies to Longhorn builds 40xx (M4 - M7).

What are the issues?
Almost all releases rebuilt recently uses wrong parameters which as a result ruins those valuable timestamps. All timestamps are set to the modification time of the latest file from that release. Some other CDIMAGE parameters are wrong (not really an issue but makes it look unprofessional).

Why is it an issue?
Since almost all pre-reset Longhorn builds came from network shares, they should be a folder dump of the compiler output. This means they were never released as ISO files or burned discs like official releases given out to beta testers and developers. What does this mean? This means the timestamps in those releases should not be touched to be the same. Timestamps of files should be very close to when the executables were compiled and since compiling a full Windows release takes many hours, there is absolutely no way for timestamps to be exactly the same.

So some people will say that Windows was never released by Microsoft without uniform timestamps and because they don't have uniform timestamps, they are worse than having uniform timestamps which is close to what a proper Microsoft release looks like. That is probably the reason for those releases to be rebuilt with uniform timestamps. Let me give you 2 examples if you think that way:
  1. Windows XP Home Edition and Windows XP Professional Combo
    Check this thread for information. I was surprised that an ISO with inconsistent timestamps and no AutoCRC was from an actual MSDN disc and it is an official release. If an official release distributed on a burned disc have inconsistent timestamps, why can't something from network shares have inconsistent timestamps?

    Image
  2. Microsoft Neptune build 5111.1
    There is a debate whether or not this release was distributed on burned discs and there is no evidence what so ever. Our administrator mrpijey rebuilt an ISO of the original WaxWarez leak some years ago with uniform timestamps and it got pointed out that is not case and it got fixed quickly. Until now, we still don't know how the leaked build was distributed but for sure some copies were distributed through burned discs and most likely some through network shares. What does this mean? If the leaked build was distributed through physical discs and it doesn't have uniform timestamps just like that XP disc, there is no reason for any Longhorn builds to be rebuilt with uniform timestamps. If the leaked build was distributed through network shares, it is more than obvious that the timestamps in those Longhorn builds should not be the same.
Why are timestamps important?
What is most important is that timestamps are a part of that release even though it rarely affects functionality. This is a preservation site and we don't want to lose any piece of information or metadata. By having all the timestamps set to the same, all information and metadata are permanently lost.

Timestamps are also important since they provides information about when a binary was compiled and when it was last modified. From this, it is very helpful if forensic analysis is to be done to a particular release.

Since some files such as documents and images from previous builds were reused as a result of them not being updated often, it is also possible to determine what those files are, which build it came from and how long it remained unchanged for through timestamps.

What makes the best release?
The best release in my opinion is the release that is either original or the closest to original. I do understand that there is no gray area between original and unoriginal and anything that was modified in any manner would be considered as unoriginal. So if I want something to be the closest to original, it will have to be "more" original than the other copy and I don't see anything wrong with having phases like "more original" or "better" since they are still classified as unoriginal, they are just one step closer to being original (and it will never be original).

So what makes a "more original" or "better" or "closest to original (still unoriginal)" release? Anything to be honest, as long as there are proof that it is better in some aspects. Timestamps, CDIMAGE parameters, UUIDREF and AutoCRC most of the times does not affect any functionalities but they are still parts of that release and they should be treated as such. If it is obvious that the timestamps or CDIMAGE parameter in a release are wrong and it is still possible to restore them to their "most original" or "most likely original" state, it does little or no harm if proper evidences are provided and a full change log is written. It in fact let us to preserve more information about that particular release and let future generations have a more complete build.

Why to care about timestamps and metadata so much?
I am not obsessed with timestamps as most of you would think. Since timestamps and other metadata does not belong to the binaries of a release, they are basically useless to the vast majority (I mean 99%) of people here who just want to try the release and get it working. If they are useless to most people, it is very easy for people to neglect them while rebuding ISOs or uploading folder dumps. Because they are easily neglected, they have a higher chance of being wrong and as a result of a higher chance of being wrong, they affects the most number of releases. I wanted to repair as many releases as possible and most of them only have bad timestamps so that is the reason for many people thinking that I am obsessed with timestamps. If there are anything wrong with the binaries, I will attempt to fix that as well and I treat binaries and metadata the same and they are equally important to me.

How to restore those timestamps?
The most important thing about restoring those timestamps is that you must have a copy of the original leak. Since original leaks are much much harder to get these days, it is also harder to restore the timestamps.

Example: Longhorn build 4093

So what does restored timestamps look like? Below is an image that tells the difference between the copy of Longhorn build 4093 on the FTP and the copy with restored timestamps.

Image

The timestamps are taken from the original leak released in 2006 and of course the timestamps from the original leak are no where near original since itself was rebuilt many times before it was leaked to the public. Since the only damage to the timestamps are from packing, transferring and unpacking, it is possible to restore those timestamps. First thing to do is to compare the timestamps to the timestamps inside install.wim and work out the difference. The timestamps inside install.wim are original so we can just add or subtract offsets to those timestamps outside of install.wim to reverse the damage done by packing and unpacking. Now it is the time to check for any damages done by daylight saving and fortunately no timestamps are damaged by daylight saving.

After all timestamps are fixed, it is the time to verify them. I will always set my timezone to UTC and the first thing to do is to compare those timestamps outside of install.wim to those inside install.wim to see if they match. If they do, we can go to the next step.

Image

Now, since there are lots of PE (portable executable) files, it is possible to work out when the file was linked or created by looking at the TimeDateStamp field in the COFF header. It could be done using a hex editor or a tool but doesn't really matter. Lets use winsetup.dll as an example:

Image

and it matches perfectly except for a few seconds of difference (it takes some time to write the file to disk). This way is not very accurate since files can get modified after they are compiled but the timestamps matches our fixed timestamps so it further proves that the timestamps are now original even though it is not a very reliable way.

What should be the CDIMAGE parameters for Longhorn?
We have 2 type of pre-reset Longhorn builds here, official releases distributed by Microsoft and builds distributed through network shares.

Official builds
These builds are intended to be released to beta testers and developers so they uses normal parameters but there are something else added and something worth noting.

- They started to embed UUIDREFs to the disc images
- They started to use Joliet Unicode filenames
- They started to use lowercase filenames
- They do use the -t parameter as with most official releases
- They do embed AutoCRCs (but with the undocumented -xx parameter as always)
- They started to use UTC-7 (E4) as timezone

Builds from network shares
These builds shouldn't be in ISO format but they are for convenience so they should not follow anything used for official releases.

- They should use Joliet Unicode filenames
- They should use mixed-cased filenames for pre-M7 builds
- They should not use the -t parameter unless all timestamps from the original leak are the same
- They should have the compilation date as the ISO creation date unless they use the -t parameter in rare cases
- They should have AutoCRCs with the -xx parameter (so it is easy to verify the integrity of those ISOs)
- They should not use any of those -o parameters (since the original build 4001 doesn't use it)
- They should use UTC (00) as timezone (since they were from network shares)

yourepicfailure
User avatar
Donator
Posts: 1317
Joined: Mon Jul 23, 2012 9:40 pm
Location: Lufthansa DC-10

Re: Timestamp and parameter issues in most Longhorn builds

Post by yourepicfailure »

ComputerHunter wrote:they should be a folder dump of the compiler output.
This is not 100% correct in the terms of the WIM Longhorn builds. The compiler does not output a nice configured wim, nor does it make something erhm wimmable right off the bat.
The closest thing to the compiler output would be the files contained within each wim's i386 folder. However, even this has undergone packing and preparation for installation that "mature" it from the raw output. But you are right in the sense that many builds were not distributed in a simple disc image.
However, it is therefore expected that there may have been timestamp modification done by Microsoft. Which makes the task of judging the most original more difficult due to the opening of more possibilities. What case to turn to?

Hopefully you've read my PM as well which does highlight the possibility of matching timestamps because of the way MSBuild works.

Otherwise, good content. May this help in the preservation, maintenance and restoration of these builds.
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"
Image
You will never tear me from the grasp of the Pentium M!

gus33000
User avatar
Posts: 537
Joined: Tue Nov 11, 2014 11:24 am
Location: Bordeaux, sometimes in Paris, France, maybe also in R.W
Contact:

Re: Timestamp and parameter issues in most Longhorn builds

Post by gus33000 »

Fair reply policy: The order of my replies / quotes have no meaning and shouldn't be interpreted with one either
ComputerHunter wrote: Disclaimer: Everything in this post are based on my personal experiences, observations and opinions. This does not target anyone, there is no intention to disrespect anyone's efforts and this is merely for informational purposes. Everything I am going to talk about only applies to Longhorn builds 40xx (M4 - M7).
I appreciate the fact you took the time to write this post, but I do not like the fact you made it so it is more of a set of dictated rules we must follow and not some form of suggestions asking for public debate whenever or not they are right, wrong or if they need adjustments. Besides having more sources for the claims shown at the bottom would also help confirm whenever or not things turn out to be true or not.

I also do not understand why your post only applies to 40xx builds only, is there a reason for that? source? reference? A preservation website needs justification for every step you describe.
ComputerHunter wrote: What are the issues?
Almost all releases rebuilt recently uses wrong parameters which as a result ruins those valuable timestamps. All timestamps are set to the modification time of the latest file from that release. Some other CDIMAGE parameters are wrong (not really an issue but makes it look unprofessional).
Showing an example of such wrong parameters would help so people wouldn't do the same "mistakes" (subjective) and not just -t for example. A proof for the fact they're set to the "modification time of the latest file from that release" would also be appreciated as well as the file in question as well with the original file you base such assessment.
ComputerHunter wrote: Why is it an issue?
Since almost all pre-reset Longhorn builds came from network shares, they should be a folder dump of the compiler output. This means they were never released as ISO files or burned discs like official releases given out to beta testers and developers. What does this mean? This means the timestamps in those releases should not be touched to be the same. Timestamps of files should be very close to when the executables were compiled and since compiling a full Windows release takes many hours, there is absolutely no way for timestamps to be exactly the same.
A list of longhorn builds that leaked that are for sure from network shares would be appreciated so we know what shouldn't be changed. This also raises the question of whenever or not you can have 2 different leaks, one from SMB v1 and one from a physical disk, there is as far as I know no way for you to claim a release was 100% based upon a folder dump than a real disk. Again it being an issue would be subject to public debate.

I find it extremely unlikely a file can have exactly the compilation timestamp in the PE header on the target filesystem considering Microsoft's build.exe compiler not only outputs all binaries in a binary output folder and not directly to the setup media and Longhorn IBS setups had to be manually made from box standard i386 medium that we all know and loved over the years which again, could have completely different timestamps all-together.
ComputerHunter wrote: So some people will say that Windows was never released by Microsoft without uniform timestamps and because they don't have uniform timestamps, they are worse than having uniform timestamps which is close to what a proper Microsoft release looks like. That is probably the reason for those releases to be rebuilt with uniform timestamps. Let me give you 2 examples if you think that way:
  1. Windows XP Home Edition and Windows XP Professional Combo
    Check this thread for information. I was surprised that an ISO with inconsistent timestamps and no AutoCRC was from an actual MSDN disc and it is an official release. If an official release distributed on a burned disc have inconsistent timestamps, why can't something from network shares have inconsistent timestamps?

    image removed
You take the example here of a disk which doesn't have auto CRC and was clearly not a standard media Microsoft cd building script would output, but the act of someone manually having to do it. I do not understand how this could be relevant in the context of discs output from Microsoft build process as a result. Moreover you say they do not have AutoCRC, then why do you suggest us to use AutoCRC, there's a missing explanation here or a mistake I think, at least it's very confusing and you have a conflicting statement for AutoCRC already.
ComputerHunter wrote: [*]Microsoft Neptune build 5111.1
There is a debate whether or not this release was distributed on burned discs and there is no evidence what so ever. Our administrator mrpijey rebuilt an ISO of the original WaxWarez leak some years ago with uniform timestamps and it got pointed out that is not case and it got fixed quickly. Until now, we still don't know how the leaked build was distributed but for sure some copies were distributed through burned discs and most likely some through network shares. What does this mean? If the leaked build was distributed through physical discs and it doesn't have uniform timestamps just like that XP disc, there is no reason for any Longhorn builds to be rebuilt with uniform timestamps. If the leaked build was distributed through network shares, it is more than obvious that the timestamps in those Longhorn builds should not be the same.[/list]
Again, Neptune isn't a clean build from Microsoft CD building script in their source tree, it is a set of different files applied on top of Windows 2000 RC2, bad example. And this topic was already discussed in one of your other threads. irrelevant to the matter for me.

Unless we have more concrete examples; to me there's 0 example from you confirming your theory already.
ComputerHunter wrote: Why are timestamps important?
What is most important is that timestamps are a part of that release even though it rarely affects functionality. This is a preservation site and we don't want to lose any piece of information or metadata. By having all the timestamps set to the same, all information and metadata are permanently lost.

Timestamps are also important since they provides information about when a binary was compiled and when it was last modified. From this, it is very helpful if forensic analysis is to be done to a particular release.

Since some files such as documents and images from previous builds were reused as a result of them not being updated often, it is also possible to determine what those files are, which build it came from and how long it remained unchanged for through timestamps.
Again, what you say here is that a file never gets its timestamp modified from MS and you claim this as a fact. There's multiple ways Microsoft can themselves update a timestamp, one of them can also be a simple file transfer over SMB. I do agree timestamps do help, but if you want to go that way why not preserving as well:

- Original leak date from the day it got copied at MS (how would you know?)
- Leaker identify information including national id number
- The network path of such folder that got copied

.. I mean you can't always preserve everything on earth, preserving binaries is already 99% of it done, timestamps are a nice extra, and a commodity, not a requirement for preservation. not to mention that in many cases you cannot preserve timestamps for example:

- Digital games where the download server won't return you the timestamps
- Encrypted digital games from Microsoft etc...

Also keep in mind the timestamps you may see may just be when the file arrived, an hour or two later on the share, it can't be bound to the compile date, especially when disks at the time weren't all SSDs (didn't exist) and took a while to get created on disk. Again unlikely things.
ComputerHunter wrote: What makes the best release?
The best release in my opinion is the release that is either original or the closest to original. I do understand that there is no gray area between original and unoriginal and anything that was modified in any manner would be considered as unoriginal. So if I want something to be the closest to original, it will have to be "more" original than the other copy and I don't see anything wrong with having phases like "more original" or "better" since they are still classified as unoriginal, they are just one step closer to being original (and it will never be original).
You say you understand that there is no gray area between original and unoriginal. But yet you seem to say you don't? Again a clear contradiction, and right in the same paragraph, then why do you say so at the beginning? I see no value in saying something when you disagree with it right in the next sentence.

I personally disagree, there's original and not original, and you can't have better, that doesn't exist, it's like saying you can have a middle ground between yellow and green, hard to believe or imagine.
ComputerHunter wrote: So what makes a "more original" or "better" or "closest to original (still unoriginal)" release? Anything to be honest, as long as there are proof that it is better in some aspects. Timestamps, CDIMAGE parameters, UUIDREF and AutoCRC most of the times does not affect any functionalities but they are still parts of that release and they should be treated as such. If it is obvious that the timestamps or CDIMAGE parameter in a release are wrong and it is still possible to restore them to their "most original" or "most likely original" state, it does little or no harm if proper evidences are provided and a full change log is written. It in fact let us to preserve more information about that particular release and let future generations have a more complete build.
I agree with you here. except of course with the better part, but I only agree with the proofs you advance of an original image. Although I need to re-say this i think:

Keep in mind Microsoft was not set on what disc format to use during Longhorn development, as a result it is very well possible for you to end up with various parameters combinations for many things (See 4074 with UUIDREF and UDF). You can't really claim that all builds must be the same based on a single ISO you managed to get and look at.
ComputerHunter wrote: Why to care about timestamps and metadata so much?
I am not obsessed with timestamps as most of you would think.
This 1,647 words, 9,542 characters post seems to indicate otherwise as with all the other posts. This post also doesn't fit on my 4K UHD display, I have a scroll bar, and I'm using 100% DPI. There's also nothing wrong with being obsessed with something when it brings value to other things (like your issue)
ComputerHunter wrote: Since timestamps and other metadata does not belong to the binaries of a release, they are basically useless to the vast majority (I mean 99%) of people here who just want to try the release and get it working. If they are useless to most people, it is very easy for people to neglect them while rebuilding ISOs or uploading folder dumps. Because they are easily neglected, they have a higher chance of being wrong and as a result of a higher chance of being wrong, they affects the most number of releases. I wanted to repair as many releases as possible and most of them only have bad timestamps so that is the reason for many people thinking that I am obsessed with timestamps. If there are anything wrong with the binaries, I will attempt to fix that as well and I treat binaries and metadata the same and they are equally important to me.
This is very subjective and I respect you according attention to details about these. But you also cannot claim only you cares about them, again proof? poll? I would be surprised if you weren't strictly the only one (see 2015 maybe, though people back then weren't pushing it that far)
ComputerHunter wrote: How to restore those timestamps?
The most important thing about restoring those timestamps is that you must have a copy of the original leak. Since original leaks are much much harder to get these days, it is also harder to restore the timestamps.

Example: Longhorn build 4093

So what does restored timestamps look like? Below is an image that tells the difference between the copy of Longhorn build 4093 on the FTP and the copy with restored timestamps.

image removed

The timestamps are taken from the original leak released in 2006 and of course the timestamps from the original leak are no where near original since itself was rebuilt many times before it was leaked to the public. Since the only damage to the timestamps are from packing, transferring and unpacking, it is possible to restore those timestamps. First thing to do is to compare the timestamps to the timestamps inside install.wim and work out the difference. The timestamps inside install.wim are original so we can just add or subtract offsets to those timestamps outside of install.wim to reverse the damage done by packing and unpacking. Now it is the time to check for any damages done by daylight saving and fortunately no timestamps are damaged by daylight saving.

After all timestamps are fixed, it is the time to verify them. I will always set my timezone to UTC and the first thing to do is to compare those timestamps outside of install.wim to those inside install.wim to see if they match. If they do, we can go to the next step.

image removed
There is no direct correlation between file timestamps in a wim (which is a container of an installed system) and the disc media itself. Please provide evidence if there's one, but I don't see any. I do not think you can base with 100% certitude timestamp changes over files copied to a container. In fact just look at recent windows builds, you will see setup files in boot.wim Windows Setup index do not match the setup disc. This decision seems invalid to me.
ComputerHunter wrote: Now, since there are lots of PE (portable executable) files, it is possible to work out when the file was linked or created by looking at the TimeDate Stamp field in the COFF header. It could be done using a hex editor or a tool but doesn't really matter. Lets use winsetup.dll as an example:

image removed

and it matches perfectly except for a few seconds of difference (it takes some time to write the file to disk). This way is not very accurate since files can get modified after they are compiled but the timestamps matches our fixed timestamps so it further proves that the timestamps are now original even though it is not a very reliable way.
Again I'm sorry, but I have the same argument and talk as above. It is extremely unlikely considering the era hardware and considering many different factors that the files must have the same timestamps as the PE header. Moreover how would you know if this doesn't have an offset built in or a timezone applied? There's no way to tell.
ComputerHunter wrote: What should be the CDIMAGE parameters for Longhorn?
We have 2 type of pre-reset Longhorn builds here, official releases distributed by Microsoft and builds distributed through network shares.

Official builds
These builds are intended to be released to beta testers and developers so they uses normal parameters but there are something else added and something worth noting.

- They started to embed UUIDREFs to the disc images
- They started to use Joliet Unicode filenames
- They started to use lowercase filenames
- They do use the -t parameter as with most official releases
- They do embed AutoCRCs (but with the undocumented -xx parameter as always)
- They started to use UTC-7 (E4) as timezone

Builds from network shares
These builds shouldn't be in ISO format but they are for convenience so they should not follow anything used for official releases.

- They should use Joliet Unicode filenames
- They should use mixed-cased filenames for pre-M7 builds
- They should not use the -t parameter unless all timestamps from the original leak are the same
- They should have the compilation date as the ISO creation date unless they use the -t parameter in rare cases
- They should have AutoCRCs with the -xx parameter (so it is easy to verify the integrity of those ISOs)
- They should not use any of those -o parameters (since the original build 4001 doesn't use it)
- They should use UTC (00) as timezone (since they were from network shares)
It would have been appreciated to have command samples for all of these as it would help. But I have a few issues with these decisions, which I explained in detail above, but now I'll bring the rest

One issue with your choices alone will sadly be (for you) 4074. The leaked WinHec 2004 4074 release ISO is deemed original because of the presence of the UUIDREF metadata specifically added by Microsoft to vouch for the authenticity of their ISO as well as their provenance. This ISO file (and the amd64 one) use UDF. This clashes with what you're saying here in a big way, and only confirms what i and other said about Microsoft experimenting with different cd format.

You also try to make an ISO out of what you certainly admit to be folder dumps from their SMB v1 share, but... that's not original either. If anything that should be preserved and the closest to original (even if that doesn't exist is a folder dump by itself. AutoCRC? Ok fair but does it really matter? Did MS always use AutoCRC? Why would you use AutoCRC, do we really know for sure if an iso was made from any build it was made with AutoCRC? You cannot in my opinion generalize decisions based on other different pieces of software, as there's really no way to tell what should have been done, and you'll most likely cause more damage than if you did not bother.

People may not care about timestamps according to you, and maybe that is true, I have not made a poll so I can't claim that with accuracy, but I can assure you people actually do care when people like you and I try to modify a release (hence why I stopped and I did the bare minimum) as you will inflict damage no matter what, and you have no way to vouch for originality in any case. I'm ready to agree with you, but the issues i pointed out would have the merit of being explained, and proven otherwise or confirmed for us to agree.

MrPinball64
Posts: 11
Joined: Wed Jul 18, 2018 1:38 am
Location: United States
Contact:

Re: Timestamp and parameter issues in most Longhorn builds

Post by MrPinball64 »

Amazing reply, Gus. 93 amazing lines, 18,320 characters, 3,195 words. I could take this thread and publish a book, probably.
Jokes aside, good response

Lucas Brooks
Posts: 773
Joined: Sat Oct 20, 2018 11:37 am
Contact:

Re: Timestamp and parameter issues in most Longhorn builds

Post by Lucas Brooks »

I am sorry if this doesn't make any sense. I wrote it while having a headache yesterday midnight . No bad intentions and not trying to be rude.
gus33000 wrote:I also do not understand why your post only applies to 40xx builds only, is there a reason for that? source? reference? A preservation website needs justification for every step you describe.
Because this is for WIM based pre-reset Longhorn builds. If you look at the official build 5112, it doesn't even use Joliet Unicode filenames. Some of the things might apply to other Longhorn builds but not everything will.
gus33000 wrote:Showing an example of such wrong parameters would help so people wouldn't do the same "mistakes" (subjective) and not just -t for example. A proof for the fact they're set to the "modification time of the latest file from that release" would also be appreciated as well as the file in question as well with the original file you base such assessment.
Is it not set to the modification of the latest file (install.wim) in almost all of your repacks? Build 4020 is an example. I dislike the fact that all of the timestamps are set to be the same as the latest file because some files were created earlier and why would you ruin their timestamps? Say I get a copy of Neptune build 5111 and set all timestamps to NT5INF.CAT's timestamp and upload that to the FTP replacing the copy with inconsistent timestamp, will you let me do it?
gus33000 wrote:A list of longhorn builds that leaked that are for sure from network shares would be appreciated so we know what shouldn't be changed. This also raises the question of whenever or not you can have 2 different leaks, one from SMB v1 and one from a physical disk, there is as far as I know no way for you to claim a release was 100% based upon a folder dump than a real disk. Again it being an issue would be subject to public debate.
It doesn't really matter where it came from. If it came from a network share and the exact same build was distributed on physical discs, it should be considered as 2 separate releases separated by "(alt)". There is absolutely no evidence which build came from network shares and which came from physical disc since that wasn't documented but according the leakers, most of them were from network shares. Some releases have batch files on the root directory that reference files in the "..\" and "..\sdk" directory and there is no way for that to happen if they were released on physical discs.
gus33000 wrote:I find it extremely unlikely a file can have exactly the compilation timestamp in the PE header on the target filesystem considering Microsoft's build.exe compiler not only outputs all binaries in a binary output folder and not directly to the setup media and Longhorn IBS setups had to be manually made from box standard i386 medium that we all know and loved over the years which again, could have completely different timestamps all-together.
Timestamps in the COFF header are just corroborating evidence. It won't be exactly the same and I totally agree with you but they generally won't be hours and day apart as seen in your repacked ISOs.
gus33000 wrote:You take the example here of a disk which doesn't have auto CRC and was clearly not a standard media Microsoft cd building script would output, but the act of someone manually having to do it. I do not understand how this could be relevant in the context of discs output from Microsoft build process as a result. Moreover you say they do not have AutoCRC, then why do you suggest us to use AutoCRC, there's a missing explanation here or a mistake I think, at least it's very confusing and you have a conflicting statement for AutoCRC already.
There is no AutoCRC and the timestamps are inconsistent. There should be an AutoCRC added to those rebuilt ISOs because AutoCRC could be used to verify the integrity of ISOs and they were from folder dumps so doesn't really matter. What all I am telling through this particular disc is that there are official discs without the -t parameter and most Longhorn builds are meant to be distributed through network shares or other means so it is very unlikely for Microsoft to touch the timestamps for something not released on discs. If you want to argue that those came from actual discs, my example will prove that it is possible for official releases to have inconsistent timestamps. I never intended to use this as an argument for AutoCRC so don't get me wrong.
gus33000 wrote:Again, Neptune isn't a clean build from Microsoft CD building script in their source tree, it is a set of different files applied on top of Windows 2000 RC2, bad example. And this topic was already discussed in one of your other threads. irrelevant to the matter for me.

Unless we have more concrete examples; to me there's 0 example from you confirming your theory already.
Let me re-word this... You think Neptune 5111 was from network shares, right? If so, why don't you rebuild an ISO with all timestamps set to NT5INF.CAT's timestamp like what you have done to all those Longhorn builds? If you are telling me that the timestamps from Neptune build 5111 are original proven by files inside DRIVER.CAB, I can tell you that timestamps from those Longhorn builds could be verified by files inside install.wim.
gus33000 wrote:Again, what you say here is that a file never gets its timestamp modified from MS and you claim this as a fact. There's multiple ways Microsoft can themselves update a timestamp, one of them can also be a simple file transfer over SMB. I do agree timestamps do help, but if you want to go that way why not preserving as well:

- Original leak date from the day it got copied at MS (how would you know?)
- Leaker identify information including national id number
- The network path of such folder that got copied

.. I mean you can't always preserve everything on earth, preserving binaries is already 99% of it done, timestamps are a nice extra, and a commodity, not a requirement for preservation. not to mention that in many cases you cannot preserve timestamps for example:

- Digital games where the download server won't return you the timestamps
- Encrypted digital games from Microsoft etc...

Also keep in mind the timestamps you may see may just be when the file arrived, an hour or two later on the share, it can't be bound to the compile date, especially when disks at the time weren't all SSDs (didn't exist) and took a while to get created on disk. Again unlikely things.
What all you are saying is the cases where timestamps can't be preserved, in that case, an RAR without timestamps will do. What I am talking about is timestamps that are most likely original and there are proofs that they are original.

If those timestamps are from the time those files arrived, they are still worth preserving since they still tell a story. I don't think that is the case from those builds I have looked at so far. Timestamps != compile date to be honest, the only reflect roughly when it was compiled or last modified which we don't really want to throw away.
gus33000 wrote:You say you understand that there is no gray area between original and unoriginal. But yet you seem to say you don't? Again a clear contradiction, and right in the same paragraph, then why do you say so at the beginning? I see no value in saying something when you disagree with it right in the next sentence.

I personally disagree, there's original and not original, and you can't have better, that doesn't exist, it's like saying you can have a middle ground between yellow and green, hard to believe or imagine.
So by your logic, no releases should ever be replaced. Rebuilding an ISO made by UltraISO will not make it any closer to original therefore better. Repacking a release with LFN and -j1 will not make it original therefore serves no purpose.

Lets use some numbers instead of colors... Say nothing is 0, original is 1 and all numbers including decimals below 1 are considered as unoriginal (so 0.9999999... is unoriginal). The originality or completeness of an unoriginal release is lets say x. x will never reach one but we want x to be close to 1, don't we? How does it get closer? By having more stuff fixed and making it look more authentic. We can make it approach 1 but it won't ever be 1 and there is no gap between 1 and numbers below 1 since numbers we are talking about are continuous. Original is something to approach but as long as it is not original, it is considered unoriginal. I don't get how "more original" or "better" would sit in the gray area since they are still unoriginal. It can get closer to what it was intended to be but as long as it never reaches that non-existent hash of the original release, it is not original. I think of "more original" or "better" as some aspects from the original release added to the unoriginal release to make it reflect the original release more while staying unoriginal. If you think that nothing could be made "more original" or "better" since those phrases shouldn't exist, then we should stop repacking releases and put those original leaks up.
gus33000 wrote:Keep in mind Microsoft was not set on what disc format to use during Longhorn development, as a result it is very well possible for you to end up with various parameters combinations for many things (See 4074 with UUIDREF and UDF). You can't really claim that all builds must be the same based on a single ISO you managed to get and look at.
I have my doubts about 4074 since it came from BetasIRC or WiNBETA and uses CDIMAGE 2.52 which was compiled after that release.
gus33000 wrote:There is no direct correlation between file timestamps in a wim (which is a container of an installed system) and the disc media itself. Please provide evidence if there's one, but I don't see any. I do not think you can base with 100% certitude timestamp changes over files copied to a container. In fact just look at recent windows builds, you will see setup files in boot.wim Windows Setup index do not match the setup disc. This decision seems invalid to me.
Imagine there is a file with the same name and hash are present both inside and outside a WIM file and their timestamps are the same. If that is the case, would you say that timestamp is not original? Timestamps outside of WIM files can change easily but timestamps inside the WIM won't. Remember our chat regarding that Neptune build? If the timestamp of a file is same as the timestamp of the same file inside an archive, would you say it is not original?

I get your point that they might not be the same due to many reasons but if the timestamps matches exactly, it is a solid proof that the timestamps outside is now original. To clear up some confusion, I nave make those timestamps up, I only add or subtract offsets to undo all the damage done by packing and daylight saving.
gus33000 wrote:Again I'm sorry, but I have the same argument and talk as above. It is extremely unlikely considering the era hardware and considering many different factors that the files must have the same timestamps as the PE header. Moreover how would you know if this doesn't have an offset built in or a timezone applied? There's no way to tell.
I have said this before, it is fine for them not to be the same but if they do match, it is a corroborating evidence for time timestamps being original. The timestamp inside COFF header should be the number of seconds passed after 1970 and it should be in UTC for everything with timezone applied. If you are building Longhorn in DOS or Windows 3.x, it might not be the case since they use local time.
gus33000 wrote:It would have been appreciated to have command samples for all of these as it would help. But I have a few issues with these decisions, which I explained in detail above, but now I'll bring the rest
Command samples? Don't you already know all the documented commands? You have a script for building ISOs so I don't think it is going to be a problem.
gus33000 wrote:One issue with your choices alone will sadly be (for you) 4074. The leaked WinHec 2004 4074 release ISO is deemed original because of the presence of the UUIDREF metadata specifically added by Microsoft to vouch for the authenticity of their ISO as well as their provenance. This ISO file (and the amd64 one) use UDF. This clashes with what you're saying here in a big way, and only confirms what i and other said about Microsoft experimenting with different cd format.
I do disagree with you on that since it was built by CDIMAGE 2.52 compiled months after 4074 was compiled. Also, I can embed an UUIDREF, you can embed an UUIDREF and everybody can so I don't know why having UUIDREF proves it original. It could simply be UUIDREF extracted from the original ISOs added to some crappy rebuilt ISOs.
gus33000 wrote:You also try to make an ISO out of what you certainly admit to be folder dumps from their SMB v1 share, but... that's not original either. If anything that should be preserved and the closest to original (even if that doesn't exist is a folder dump by itself. AutoCRC? Ok fair but does it really matter? Did MS always use AutoCRC? Why would you use AutoCRC, do we really know for sure if an iso was made from any build it was made with AutoCRC? You cannot in my opinion generalize decisions based on other different pieces of software, as there's really no way to tell what should have been done, and you'll most likely cause more damage than if you did not bother.
AutoCRC is only used for checking the integrity of a rebuilt ISO for something from folder dumps. I have no problem with all files dumped into an archive but we need ISO to make it easier to install. You know they are from network shares and I am more than happy to know the reasons why you have used AutoCRC.
gus33000 wrote:People may not care about timestamps according to you, and maybe that is true, I have not made a poll so I can't claim that with accuracy, but I can assure you people actually do care when people like you and I try to modify a release (hence why I stopped and I did the bare minimum) as you will inflict damage no matter what, and you have no way to vouch for originality in any case. I'm ready to agree with you, but the issues i pointed out would have the merit of being explained, and proven otherwise or confirmed for us to agree.
May I ask a question before I provide you with an answer? Why have you changed all the timestamps so the are exactly the same? Doesn't that inflict damage? It is like using uniform timestamps for Neptune 5111 and since you are saying that I change my stance all the time, why have you changed your stance here? Again, sorry if this sounds rude and no bad intentions here.

Now, I will provide my response regarding your question. I think the bare minimum is to change nothing except for correcting aspects that are clearly unoriginal yet still repairable. I do provide evidence every time I fix something but they are simply ignored. I base everything off the original leak which sometimes are gone for good (I do have some original leaks of Longhorn builds saved to my hard drive back in the old days). If you fix something, throw away the original leak without putting a documentation of changes, it inflicts more damage than rebuilding the original leak, provide evidence for changes and write a full documentation including everything changed since it was leaked.

If you want to talk about damage done, changing all timestamps to be the same does more damage than adding and subtracting offsets.

gus33000
User avatar
Posts: 537
Joined: Tue Nov 11, 2014 11:24 am
Location: Bordeaux, sometimes in Paris, France, maybe also in R.W
Contact:

Re: Timestamp and parameter issues in most Longhorn builds

Post by gus33000 »

ComputerHunter wrote: Because this is for WIM based pre-reset Longhorn builds. If you look at the official build 5112, it doesn't even use Joliet Unicode filenames. Some of the things might apply to other Longhorn builds but not everything will.
What about 4002? Or that server build? You need to be very precise especially when you write such a long post which consists only about nitpicks of small details.
ComputerHunter wrote:
gus33000 wrote:Showing an example of such wrong parameters would help so people wouldn't do the same "mistakes" (subjective) and not just -t for example. A proof for the fact they're set to the "modification time of the latest file from that release" would also be appreciated as well as the file in question as well with the original file you base such assessment.
Is it not set to the modification of the latest file (install.wim) in almost all of your repacks? Build 4020 is an example.
You haven't replied to my question, so I do not have a proof of where you got that:

1) I changed the timestamps for everything
2) I used the last modified date for everything
ComputerHunter wrote: I dislike the fact that all of the timestamps are set to be the same as the latest file because some files were created earlier and why would you ruin their timestamps?
You used the right word here, you dislike it and that is not a mindset to have when we are thinking about preservation, feeling and likings are one thing but you need to stay neutral. Again, it is in your only opinion that the timestamps are ruined.
You also evade the point I have made in my reply above. You are trying to recreate ISOs which you have:

- No proof ever existed
- No proof what so ever if they ever existed they used these timestamps?

so what about stopping making everything an ISO and just letting it be a rar? But of course no one wants a rar, you included. You keep contradicting your intentions from start to finish.
An ISO is meant to be uniform when it's the result of Microsoft build process, and not a manual intervention.
ComputerHunter wrote: Say I get a copy of Neptune build 5111 and set all timestamps to NT5INF.CAT's timestamp and upload that to the FTP replacing the copy with inconsistent timestamp, will you let me do it?
It's weird how you took once again, an irrelevant example. As I have said in my reply above, which you 50% discarded, Neptune was a set of patched files manually put in on top of Windows 2000 RC2, and is not the result of Microsoft build process as is.
Your justification is therefore not justified and I'm waiting for a new example. You are also saying it was an ISO originally, again, waiting for proof of that.

I am also saddened that you did not provide any example of the other wrong parameters we should not use. We need such a list so we know what you are talking about, and it is important for preservation purposes.
We also lack a full list of releases you judge incorrect, so we once again do not know what you are talking about.
ComputerHunter wrote:
gus33000 wrote:A list of longhorn builds that leaked that are for sure from network shares would be appreciated so we know what shouldn't be changed. This also raises the question of whenever or not you can have 2 different leaks, one from SMB v1 and one from a physical disk, there is as far as I know no way for you to claim a release was 100% based upon a folder dump than a real disk. Again it being an issue would be subject to public debate.
It doesn't really matter where it came from. If it came from a network share and the exact same build was distributed on physical discs, it should be considered as 2 separate releases separated by "(alt)". There is absolutely no evidence which build came from network shares and which came from physical disc since that wasn't documented but according the leakers, most of them were from network shares. Some releases have batch files on the root directory that reference files in the "..\" and "..\sdk" directory and there is no way for that to happen if they were released on physical discs.
You are saying it doesn't matter where it came from, yet, that did matter enough for you when you say that they surely were distributed on physical disks and thus you feel the need to create an ISO. So does it matter or doesn't it matter? You are once again contradicting yourself.
If there is no evidence that they came from network shares, then why do you think the timestamps that aren't uniform are legit to begin with? Proof? explanation? these would be appreciated. If they are from network shares, you can't possibly go full on making an ISO, but by removing half of the rules applying to pressed discs.

It's like if you wanted to make a pizza without the bottom, it wouldn't work, and it's half backed.

According to you do we also need to convert floppy disc images to ISO files then? Because your logic would hint at that (because it apparently doesn't matter where it came from, it must be an ISO).
ComputerHunter wrote:
gus33000 wrote:I find it extremely unlikely a file can have exactly the compilation timestamp in the PE header on the target filesystem considering Microsoft's build.exe compiler not only outputs all binaries in a binary output folder and not directly to the setup media and Longhorn IBS setups had to be manually made from box standard i386 medium that we all know and loved over the years which again, could have completely different timestamps all-together.
Timestamps in the COFF header are just corroborating evidence. It won't be exactly the same and I totally agree with you but they generally won't be hours and day apart as seen in your repacked ISOs.
You do realize all new builds are one day off, do you?
ComputerHunter wrote:
gus33000 wrote:You take the example here of a disk which doesn't have auto CRC and was clearly not a standard media Microsoft cd building script would output, but the act of someone manually having to do it. I do not understand how this could be relevant in the context of discs output from Microsoft build process as a result. Moreover you say they do not have AutoCRC, then why do you suggest us to use AutoCRC, there's a missing explanation here or a mistake I think, at least it's very confusing and you have a conflicting statement for AutoCRC already.
There is no AutoCRC and the timestamps are inconsistent. There should be an AutoCRC added to those rebuilt ISOs because AutoCRC could be used to verify the integrity of ISOs and they were from folder dumps so doesn't really matter. What all I am telling through this particular disc is that there are official discs without the -t parameter and most Longhorn builds are meant to be distributed through network shares or other means so it is very unlikely for Microsoft to touch the timestamps for something not released on discs. If you want to argue that those came from actual discs, my example will prove that it is possible for official releases to have inconsistent timestamps. I never intended to use this as an argument for AutoCRC so don't get me wrong.
Once again, you evade the context of my reply.
You are taking the example of a disc manually done by an employee and not from Microsoft build script. Your argument is invalidated right from the start because we are talking about you saying physical discs surely existed, because you want to make them an ISO and as if it was out of Microsoft hands.
Have you ever seen winbuilds in your life? I would think no, and it is quite apparent, timestamps always differ between built ISOs and winbuilds.

May I ask why do you keep wanting to make ISO files like if they were out of MS themselves but also exclude half of what original ISOs from Microsoft build script have? Because once again, I do not see any legit example from you.
ComputerHunter wrote:
gus33000 wrote:Again, Neptune isn't a clean build from Microsoft CD building script in their source tree, it is a set of different files applied on top of Windows 2000 RC2, bad example. And this topic was already discussed in one of your other threads. irrelevant to the matter for me.

Unless we have more concrete examples; to me there's 0 example from you confirming your theory already.
Let me re-word this... You think Neptune 5111 was from network shares, right? If so, why don't you rebuild an ISO with all timestamps set to NT5INF.CAT's timestamp like what you have done to all those Longhorn builds? If you are telling me that the timestamps from Neptune build 5111 are original proven by files inside DRIVER.CAB, I can tell you that timestamps from those Longhorn builds could be verified by files inside install.wim.
Again, you are not taking the example of a disc that came out of Microsoft own build script, but was the result of manual modifications of a Windows 2000 RC2 disc. Your argument is still invalid. Please provide a good example and then we will discuss that case.
ComputerHunter wrote:
gus33000 wrote:Again, what you say here is that a file never gets its timestamp modified from MS and you claim this as a fact. There's multiple ways Microsoft can themselves update a timestamp, one of them can also be a simple file transfer over SMB. I do agree timestamps do help, but if you want to go that way why not preserving as well:

- Original leak date from the day it got copied at MS (how would you know?)
- Leaker identify information including national id number
- The network path of such folder that got copied

.. I mean you can't always preserve everything on earth, preserving binaries is already 99% of it done, timestamps are a nice extra, and a commodity, not a requirement for preservation. not to mention that in many cases you cannot preserve timestamps for example:

- Digital games where the download server won't return you the timestamps
- Encrypted digital games from Microsoft etc...

Also keep in mind the timestamps you may see may just be when the file arrived, an hour or two later on the share, it can't be bound to the compile date, especially when disks at the time weren't all SSDs (didn't exist) and took a while to get created on disk. Again unlikely things.
What all you are saying is the cases where timestamps can't be preserved, in that case, an RAR without timestamps will do. What I am talking about is timestamps that are most likely original and there are proofs that they are original.
You are willing to create an ISO, not a rar archive, and as a matter of fact we have 0 release out of Microsoft own build scripts not using the same timestamps for all files. Again, feel free to provide valid examples.
And you are still saying that the timestamps are original, we still see no proof.
ComputerHunter wrote: If those timestamps are from the time those files arrived, they are still worth preserving since they still tell a story. I don't think that is the case from those builds I have looked at so far. Timestamps != compile date to be honest, the only reflect roughly when it was compiled or last modified which we don't really want to throw away.
Then why do you suggest to get rid of RAR timestamps? They don't tell a story in that case as well? Again, what you want is preserving timestamps and making a high quality ISO out of it like if Microsoft made it. I'm sorry to tell you this but both of these are incompatible with each other unless proven otherwise.
ComputerHunter wrote:
gus33000 wrote:You say you understand that there is no gray area between original and unoriginal. But yet you seem to say you don't? Again a clear contradiction, and right in the same paragraph, then why do you say so at the beginning? I see no value in saying something when you disagree with it right in the next sentence.

I personally disagree, there's original and not original, and you can't have better, that doesn't exist, it's like saying you can have a middle ground between yellow and green, hard to believe or imagine.
So by your logic, no releases should ever be replaced. Rebuilding an ISO made by UltraISO will not make it any closer to original therefore better. Repacking a release with LFN and -j1 will not make it original therefore serves no purpose.

Lets use some numbers instead of colors... Say nothing is 0, original is 1 and all numbers including decimals below 1 are considered as unoriginal (so 0.9999999... is unoriginal). The originality or completeness of an unoriginal release is lets say x. x will never reach one but we want x to be close to 1, don't we? How does it get closer? By having more stuff fixed and making it look more authentic. We can make it approach 1 but it won't ever be 1 and there is no gap between 1 and numbers below 1 since numbers we are talking about are continuous. Original is something to approach but as long as it is not original, it is considered unoriginal. I don't get how "more original" or "better" would sit in the gray area since they are still unoriginal. It can get closer to what it was intended to be but as long as it never reaches that non-existent hash of the original release, it is not original. I think of "more original" or "better" as some aspects from the original release added to the unoriginal release to make it reflect the original release more while staying unoriginal. If you think that nothing could be made "more original" or "better" since those phrases shouldn't exist, then we should stop repacking releases and put those original leaks up.
Where did I say no release shouldn't be replaced? I'm merely pointing out issues in the thoughts you express here.
Again, looking authentic is not only subjective, but you also apply a lot of exceptions into your thoughts, which again, we have no proof that ISOsfrom Microsoft from their build process happened to not use uniform timestamps. So I'll be willing to listen to your explanation and accept it only if the basis of your analysis is founded, which right now, it is not.
ComputerHunter wrote:
gus33000 wrote:Keep in mind Microsoft was not set on what disc format to use during Longhorn development, as a result it is very well possible for you to end up with various parameters combinations for many things (See 4074 with UUIDREF and UDF). You can't really claim that all builds must be the same based on a single ISO you managed to get and look at.
I have my doubts about 4074 since it came from BetasIRC or WiNBETA and uses CDIMAGE 2.52 which was compiled after that release.
So how do you explain UUIDREF? Because by the looks of it it must not be an issue in your thoughts at all, and you will not be open to discussion over the fact your choices may very well be wrong, and if they are, this will ruin the preservation of files.
You are ready to ruin a perfectly fine release just because you have doubts?
ComputerHunter wrote:
gus33000 wrote:There is no direct correlation between file timestamps in a wim (which is a container of an installed system) and the disc media itself. Please provide evidence if there's one, but I don't see any. I do not think you can base with 100% certitude timestamp changes over files copied to a container. In fact just look at recent windows builds, you will see setup files in boot.wim Windows Setup index do not match the setup disc. This decision seems invalid to me.
Imagine there is a file with the same name and hash are present both inside and outside a WIM file and their timestamps are the same. If that is the case, would you say that timestamp is not original? Timestamps outside of WIM files can change easily but timestamps inside the WIM won't. Remember our chat regarding that Neptune build? If the timestamp of a file is same as the timestamp of the same file inside an archive, would you say it is not original?
Once again, you take up the example of neptune :) and it is not the result of microsoft build process :)

Also it's very easy for timestamps to differ inside a wim and outside, and if you don't think it is, I encourage you to read Microsoft WIM format specification and/or try a few things with dism or wimlib-imagex :)
ComputerHunter wrote: I get your point that they might not be the same due to many reasons but if the timestamps matches exactly, it is a solid proof that the timestamps outside is now original. To clear up some confusion, I nave make those timestamps up, I only add or subtract offsets to undo all the damage done by packing and daylight saving.
What tells you daylight saving and packing is actual damage, and that it wasn't like this at Microsoft? Proof?
ComputerHunter wrote:
gus33000 wrote:Again I'm sorry, but I have the same argument and talk as above. It is extremely unlikely considering the era hardware and considering many different factors that the files must have the same timestamps as the PE header. Moreover how would you know if this doesn't have an offset built in or a timezone applied? There's no way to tell.
I have said this before, it is fine for them not to be the same but if they do match, it is a corroborating evidence for time timestamps being original. The timestamp inside COFF header should be the number of seconds passed after 1970 and it should be in UTC for everything with timezone applied. If you are building Longhorn in DOS or Windows 3.x, it might not be the case since they use local time.
If it was fine then why are you obsessed with changing timestamps and """fixing them""""?
You are also saying exceptions do exist, so there is doubts with your decision already. We can't really do anything based on doubts.
ComputerHunter wrote:
gus33000 wrote:It would have been appreciated to have command samples for all of these as it would help. But I have a few issues with these decisions, which I explained in detail above, but now I'll bring the rest
Command samples? Don't you already know all the documented commands? You have a script for building ISOs so I don't think it is going to be a problem.
You are making a post for The community not me. The community needs to know and it is very important for preservation. What if I die?
ComputerHunter wrote:
gus33000 wrote:One issue with your choices alone will sadly be (for you) 4074. The leaked WinHec 2004 4074 release ISO is deemed original because of the presence of the UUIDREF metadata specifically added by Microsoft to vouch for the authenticity of their ISO as well as their provenance. This ISO file (and the amd64 one) use UDF. This clashes with what you're saying here in a big way, and only confirms what i and other said about Microsoft experimenting with different cd format.
I do disagree with you on that since it was built by CDIMAGE 2.52 compiled months after 4074 was compiled. Also, I can embed an UUIDREF, you can embed an UUIDREF and everybody can so I don't know why having UUIDREF proves it original. It could simply be UUIDREF extracted from the original ISOs added to some crappy rebuilt ISOs.
And what? Microsoft can very well make the ISO file after it's compiled no? It's not impossible for them to use a newer cd image to begin with if it happens to be the latest one.
If you can embed an UUIDREF then what doesn't tell you some malicious person (ie me) didn't purposely make timestamps not uniform to begin with, basing them on binary compile time with a very short millisecond offset, just to fool people?
We can go really far with hexediting and conspiracies if needed.
ComputerHunter wrote:
gus33000 wrote:You also try to make an ISO out of what you certainly admit to be folder dumps from their SMB v1 share, but... that's not original either. If anything that should be preserved and the closest to original (even if that doesn't exist is a folder dump by itself. AutoCRC? Ok fair but does it really matter? Did MS always use AutoCRC? Why would you use AutoCRC, do we really know for sure if an iso was made from any build it was made with AutoCRC? You cannot in my opinion generalize decisions based on other different pieces of software, as there's really no way to tell what should have been done, and you'll most likely cause more damage than if you did not bother.
AutoCRC is only used for checking the integrity of a rebuilt ISO for something from folder dumps. I have no problem with all files dumped into an archive but we need ISO to make it easier to install. You know they are from network shares and I am more than happy to know the reasons why you have used AutoCRC.
Can you provide such an example of an official Microsoft ISO rebuilt from a folder dump by Microsoft? And proof of this claim?
You want to make an ISO to make it easier to install, but is that really what you are doing here? Your reply and this thread seems to hint you are doing it for more "originality" (subjective) and not for making people's life easier.
ComputerHunter wrote:
gus33000 wrote:People may not care about timestamps according to you, and maybe that is true, I have not made a poll so I can't claim that with accuracy, but I can assure you people actually do care when people like you and I try to modify a release (hence why I stopped and I did the bare minimum) as you will inflict damage no matter what, and you have no way to vouch for originality in any case. I'm ready to agree with you, but the issues i pointed out would have the merit of being explained, and proven otherwise or confirmed for us to agree.
May I ask a question before I provide you with an answer? Why have you changed all the timestamps so the are exactly the same? Doesn't that inflict damage? It is like using uniform timestamps for Neptune 5111 and since you are saying that I change my stance all the time, why have you changed your stance here? Again, sorry if this sounds rude and no bad intentions here.
Once again, 5112 isn't a valid example...
And still currently we got 0 example of a proper ISO from Microsoft build process of the time which doesn't use uniform timestamps.
May I also bring the subject of 4051 or 4033 ia64? Both of which are fine.

Again, list of things you think I changed along with proof would be appreciated, because even I do not remember which one I exactly changed and it would help fix them if the issues you point out turn out to be validated by an argument.
ComputerHunter wrote: Now, I will provide my response regarding your question. I think the bare minimum is to change nothing except for correcting aspects that are clearly unoriginal yet still repairable. I do provide evidence every time I fix something but they are simply ignored. I base everything off the original leak which sometimes are gone for good (I do have some original leaks of Longhorn builds saved to my hard drive back in the old days). If you fix something, throw away the original leak without putting a documentation of changes, it inflicts more damage than rebuilding the original leak, provide evidence for changes and write a full documentation including everything changed since it was leaked.
That's what you are doing as well no? You are replacing all ISOs that ever existed on earth with subjectively "better" ISOs in your opinion. Don't you think that's also destructive? You are doing exactly the same thing.
ComputerHunter wrote: If you want to talk about damage done, changing all timestamps to be the same does more damage than adding and subtracting offsets.
There is no gray area between more or less damage, damage is damage, no way around it. But the usage of the word damage is highly subjective, especially when it is founded on arguments without concrete proof (5111 isn't valid and I'll reiterate that claim).

I will add to this extremely long reply that you are complaining about timestamps, which is a file metadata and is not as important as the files inside the medium. You are trying to deal with files where there is no authenticity of their originality to begin with. All releases are not marked as original. To me, and maybe for others, all this effort and argumentation is actually not useful.

I don't mind though that I took the time to reply to you. We just hope you realize that your efforts, aren't really useful because of the very nature of these files.

Edit: I'm also going to stop replying because I have expressed my opinion and arguments on this matter, and I do not think the OP will change my opinion.

Lucas Brooks
Posts: 773
Joined: Sat Oct 20, 2018 11:37 am
Contact:

Re: Timestamp and parameter issues in most Longhorn builds

Post by Lucas Brooks »

gus33000 wrote:What about 4002? Or that server build? You need to be very precise especially when you write such a long post which consists only about nitpicks of small details.
OK, lets say this only applies for WIM based 32-bit builds.
gus33000 wrote:You haven't replied to my question, so I do not have a proof of where you got that:

1) I changed the timestamps for everything
2) I used the last modified date for everything
1) You have changed timestamps for everything because the -t parameter was used. If you are going to say you didn't use the -t parameter, then the creation time of the ISO would be 00:00:00 UTC the day the ISO was build which is not true in your rebuilt ISOs.

2) Not for all builds but most. Build 4020's eula.txt was modified so you have used the second latest timestamp (of install.wim) as timestamp for all files. I still have an unmodified version of eula.txt from 1st of May.

Build 4050, 4082, 4083, 4086 and 4087 from the recent leaks originally had inconsistent timestamps but that is no longer the case for those ISOs on the FTP. 4020 and 4093 are also damaged.
gus33000 wrote:You used the right word here, you dislike it and that is not a mindset to have when we are thinking about preservation, feeling and likings are one thing but you need to stay neutral. Again, it is in your only opinion that the timestamps are ruined.
You also evade the point I have made in my reply above. You are trying to recreate ISOs which you have:

- No proof ever existed
- No proof what so ever if they ever existed they used these timestamps?

so what about stopping making everything an ISO and just letting it be a rar? But of course no one wants a rar, you included. You keep contradicting your intentions from start to finish.
An ISO is meant to be uniform when it's the result of Microsoft build process, and not a manual intervention.
I get you point here but not all ISOs or discs officially release were from the proper Microsoft build process. I know that they shouldn't be in ISOs but they have to be in ISOs for convenience and putting files in ISOs doesn't damage anything. There are proofs the timestamps from those original leaks are closer to original and are more likely to be original since they matches timestamps inside install.wim and their link date. If you think they are completely wrong, then you shouldn't be basing your uniform timestamps off the latest file from that release.
gus33000 wrote:It's weird how you took once again, an irrelevant example. As I have said in my reply above, which you 50% discarded, Neptune was a set of patched files manually put in on top of Windows 2000 RC2, and is not the result of Microsoft build process as is.
Your justification is therefore not justified and I'm waiting for a new example. You are also saying it was an ISO originally, again, waiting for proof of that.
Neptune was not from the proper Microsoft build process but how do you know those Longhorn builds were? Some of those 408x range builds are just files placed onto an unleaked build from 04/23/2004.
gus33000 wrote:I am also saddened that you did not provide any example of the other wrong parameters we should not use. We need such a list so we know what you are talking about, and it is important for preservation purposes.
We also lack a full list of releases you judge incorrect, so we once again do not know what you are talking about.
The worst wrong parameter is -t and the other one is -o. Something from network shares don't normally have uniform timestamps and original copy of Longhorn build 4001 did not use -o. -o was widely used in those I386 based multi-sku ISOs but not very often for the new image based setup.

If you want a build list of those releases, it is impossible to get one because the timestamps are ruined either when:
- the release was downloaded
- the release was packed
- the release was burned to disc
- the release was shared
- the release was rebuilt
but I have provided examples above of builds that got their timestamps ruined by the repack prior to them being uploaded to the FTP by you.
gus33000 wrote:You are saying it doesn't matter where it came from, yet, that did matter enough for you when you say that they surely were distributed on physical disks and thus you feel the need to create an ISO. So does it matter or doesn't it matter? You are once again contradicting yourself.
Of course it doesn't matter where it came from as they are Longhorn builds regardless. It does matter when comes to repacking and I believe it should be in ISOs for convenience and I do not care if they gets repacked into RARs directly.
gus33000 wrote:If there is no evidence that they came from network shares, then why do you think the timestamps that aren't uniform are legit to begin with? Proof? explanation? these would be appreciated. If they are from network shares, you can't possibly go full on making an ISO, but by removing half of the rules applying to pressed discs.
There is no proof they came from network shares but many files on it have indicated that it came from network shares. ISO should be provided for convenience and of course it would be an ISO with most parameters for pressed discs removed so it preserves every bit of information parameters for pressed discs can't.
gus33000 wrote:According to you do we also need to convert floppy disc images to ISO files then? Because your logic would hint at that (because it apparently doesn't matter where it came from, it must be an ISO).
*hehe*
gus33000 wrote:You do realize all new builds are one day off, do you?
For some binaries, yes and for some, no.
gus33000 wrote:Once again, you evade the context of my reply.
You are taking the example of a disc manually done by an employee and not from Microsoft build script. Your argument is invalidated right from the start because we are talking about you saying physical discs surely existed, because you want to make them an ISO and as if it was out of Microsoft hands.
Have you ever seen winbuilds in your life? I would think no, and it is quite apparent, timestamps always differ between built ISOs and winbuilds.

May I ask why do you keep wanting to make ISO files like if they were out of MS themselves but also exclude half of what original ISOs from Microsoft build script have? Because once again, I do not see any legit example from you.
Lets not make this page longer by adding more repeated words... ISOs with half of those parameters are for convenience as they preserves everything from that folder dump yet it makes them bootable and easy to install. I don't think physical discs existed for most of those Longhorn builds but not coming from physical discs != you can't have ISO for convenience.
gus33000 wrote:Again, you are not taking the example of a disc that came out of Microsoft own build script, but was the result of manual modifications of a Windows 2000 RC2 disc. Your argument is still invalid. Please provide a good example and then we will discuss that case.
Again, you are thinking Longhorn was from discs that came out of Microsoft's build script. They are not just like that Neptune build. They are in fact files put onto a template with documents and images from earlier builds.
gus33000 wrote:You are willing to create an ISO, not a rar archive, and as a matter of fact we have 0 release out of Microsoft own build scripts not using the same timestamps for all files. Again, feel free to provide valid examples.
And you are still saying that the timestamps are original, we still see no proof.
How do you know Longhorn was from the Microsoft build script? I don't think there is a video about a Longhorn build being compiled, added to ISO with CDIMAGE parameters they use for official releases, burnt to discs and sent to developers. There are plenty of Microsoft stuff officially released that wasn't from the build script.
gus33000 wrote:Where did I say no release shouldn't be replaced? I'm merely pointing out issues in the thoughts you express here.
Again, looking authentic is not only subjective, but you also apply a lot of exceptions into your thoughts, which again, we have no proof that ISOsfrom Microsoft from their build process happened to not use uniform timestamps. So I'll be willing to listen to your explanation and accept it only if the basis of your analysis is founded, which right now, it is not.
I don't know why you think they were from the build script used to output official ISOs ready to be released to developers or burnt to discs. I think that is our main disagreement.
gus33000 wrote:So how do you explain UUIDREF? Because by the looks of it it must not be an issue in your thoughts at all, and you will not be open to discussion over the fact your choices may very well be wrong, and if they are, this will ruin the preservation of files.
You are ready to ruin a perfectly fine release just because you have doubts?
Have I ever said I was going to do anything to it? I have doubts so it is not something reliable and shouldn't be tagged as original because there is no artwork nor there is anything that proves it is original. Also, look at the leaked copy of CDIMAGE 2.52, it was compiled on the 13th of October 2004 so quite far from April. Of course if the date inside the ISO was in American format, then it is perfectly normal but what if it is not? I do admit that there are possibilities for the copy of CDIMAGE 2.52 we have being a recompile of the CDIMAGE used to build those Longhorn 4074 ISOs but there is no proof for that either.
gus33000 wrote:Once again, you take up the example of neptune :) and it is not the result of microsoft build process :)
Once again, you are assuming Longhorn was a result of Microsoft build process :).
gus33000 wrote:Also it's very easy for timestamps to differ inside a wim and outside, and if you don't think it is, I encourage you to read Microsoft WIM format specification and/or try a few things with dism or wimlib-imagex :)
But we are talking about early WIMs and the timestamps do match. If they don't, it is possible for timestamps being changed while adding files to the WIM but in this case, they do. I don't think it is possible for 2 files with different timestamps to have matching timestamps after one being added to a WIM and the chance of that happening is low.
gus33000 wrote:What tells you daylight saving and packing is actual damage, and that it wasn't like this at Microsoft? Proof?
I have no proof but it came from experience after repacking all those Windows XP and 2000 ISOs in the past 4 years (for my collection). That is most likely the reason and I couldn't think of any better reasons.
gus33000 wrote:If it was fine then why are you obsessed with changing timestamps and """fixing them""""?
You are also saying exceptions do exist, so there is doubts with your decision already. We can't really do anything based on doubts.
The chance of Longhorn being compiled on a 268 machines running DOS is not that high, is it? Using timestamps from the original leak has the least number of doubts in my opinion.
gus33000 wrote:You are making a post for The community not me. The community needs to know and it is very important for preservation.
I am reply to you and I assume you know all the documented parameters. Here are some very basic command line examples for those who are interested:

Code: Select all

CDIMAGE.EXE -lLB1PFRE_EN -j1 -bBootSect.bin -xx [FOLDER] [FILENAME].iso (no uniform timestamp)
CDIMAGE.EXE -lLB1PFRE_EN -j1 -tMM/DD/YYYY,HH:MM:SS -bBootSect.bin -xxUUIDREF.TXT [FOLDER] [FILENAME].iso (with UUIDREF and uniform timestamps)
Also, a good idea to set your computer date to the compilation date of that release when you are rebuilding ISOs without uniform timestamps. Timezone also should be in UTC if -g is not used.
gus33000 wrote:What if I die?
I honestly hope that doesn't happen and please don't joke about it.
gus33000 wrote:And what? Microsoft can very well make the ISO file after it's compiled no? It's not impossible for them to use a newer cd image to begin with if it happens to be the latest one.
If you can embed an UUIDREF then what doesn't tell you some malicious person (ie me) didn't purposely make timestamps not uniform to begin with, basing them on binary compile time with a very short millisecond offset, just to fool people?
We can go really far with hexediting and conspiracies if needed.
Still not convince why the presence of UUIDREF means it is original. Everybody can create an ISO with UUIDREF and since it involves no hex-editing, everybody who wants to make their ISO looks real can do it. It is not rocket science to learn how to use CDIMAGE and embed UUIDREFs. If (I am only saying if) somebody was to rebuild an ISO and they have used the UUIDREF from say the original copy of 4074 or any other build to make it looks authentic, how do you know they have malicious intentions? They might just want to rebuild it so it looks original.

Again, if the timestamps are 100% wrong, why would you set all timestamps to the latest file on that ISO? Why not set them to 12:00:00 like they did for most of their official discs.
gus33000 wrote:Can you provide such an example of an official Microsoft ISO rebuilt from a folder dump by Microsoft? And proof of this claim?
You want to make an ISO to make it easier to install, but is that really what you are doing here? Your reply and this thread seems to hint you are doing it for more "originality" (subjective) and not for making people's life easier.
I see nothing wrong with making something closer to original while making it easier to install. You have rebuilt them in ISO format, right? You know they came from network shares but why did you use ISO?
gus33000 wrote:Once again, 5112 isn't a valid example...
And still currently we got 0 example of a proper ISO from Microsoft build process of the time which doesn't use uniform timestamps.
May I also bring the subject of 4051 or 4033 ia64? Both of which are fine.

Again, list of things you think I changed along with proof would be appreciated, because even I do not remember which one I exactly changed and it would help fix them if the issues you point out turn out to be validated by an argument.
Again, don't want to make this long :) and I have already answered them. For those builds with timestamp from 1908 and 1909 (4040 and 4042 main), I have no idea why that happened so I don't care about them. 4020, 4050, 4082, 4083, 4086 and 4087 and 4093 got all their timestamps messed up.

Something I want to ask is how do you know Longhorn was from the proper Microsoft build process? All I can see is just files being put onto an older release overwriting binaries from that build. Also, what if the build script sends them to the network share directly instead of creating an ISO?
gus33000 wrote:That's what you are doing as well no? You are replacing all ISOs that ever existed on earth with subjectively "better" ISOs in your opinion. Don't you think that's also destructive? You are doing exactly the same thing.
This is not really subjecting because:
1) I have proof that time timestamps are likely to be original
2) You have no proof that the timestamps would be the timestamp you have used for all files if that build ever came on a disc
3) Less change is better and no timestamps were changed in the ISOs I rebuilt whereas all timestamps from your rebuilt ISO got changed.
gus33000 wrote:There is no gray area between more or less damage, damage is damage, no way around it. But the usage of the word damage is highly subjective, especially when it is founded on arguments without concrete proof (5111 isn't valid and I'll reiterate that claim).
What about this, say I have a copy of the original Longhorn build 4050 with Aero but I don't want to give it to you. I said you can have either all timestamps ruined or all the timestamp offsets messed up so that you won't ever have my original copy. Which one you you pick? If I was you, I will pick all timestamp offset messed up because the timestamps are still there.

If you think damage is damage, why don't we pre-crack all those unoriginal builds since they were already damaged the day they were downloaded or burnt to discs and more damage and less damage doesn't make a difference?

Again, I firmly believe using timestamps from the original leak does less damage than using the latest timestamp from the original leak as all timestamps.

Summary of this post:
I think the disagreement is whether or not Longhorn was from the proper Microsoft build process. You think it is and therefore all timestamps should be set to the same whereas I believe they are just files put on top of an older build just like that Neptune build so timestamps shouldn't be set to the same.

mrpijey
User avatar
Administrator
Posts: 9188
Joined: Tue Feb 12, 2008 5:28 pm
Contact:

Re: Timestamp and parameter issues in most Longhorn builds

Post by mrpijey »

I've read this entire thread and I think there are valid points from both sides, but I am only interested in two things:
  • Is it original?
  • Is it modified?
If it's original then it stays as it is, even if it's broken. We can provide patches to make it work (as long as it doesn't violate any of our abandonware rules).

If it's modified then we determine what is modified, document it, and fix it if possible, but only if the modifications altered the functionality (cracks etc). If it can't be fixed (original files missing etc) then the bad files are to be documented, removed, the release rebuilt and tagged and treated as incomplete.

When it comes to already non-original stuff such as these LH builds then it does not matter what's changed or not in terms of metadata. It's still not original, it doesn't alter the functionality, and we can't even know what changes would bring it closer or not to a true original as we have no basis for comparison. Microsoft distributed these builds in more than one ways, and they experimented with tools, flags and layouts which could change between one build to another. Normally we would keep these in its most original form possible, but we can't even be sure about what that was. For all we know a particular build could have been copied off an MS internal CD-ROM, uploaded somewhere and then treated as a download build. Or the other way around. So we treat these builds as if they were on optical discs, but only for convenience as installable CD-ROM/DVD-ROMs were the "natural" state of a Windows installation media. Not so anymore of course but Microsoft has also refined and standardized the installation media layout between the generations of Windows. With Windows 9x we knew how the disc layout looked like (WIN95, WIN98, WINME, no long filenames etc. (with some exceptions for some beta builds with WIN9X etc). With WinNT we also knew how the disc layout looked like and how to make the disc bootable (I386, ALPHA, PPC folders, bootsector etc). With LH not so much as they jumped between a I386-format and a WIM format, printed discs and downloadable files etc. All depending on the build and the source.

If we are to sit and alter timestamps then half of our releases will have to be altered, and for absolutely no benefit at all. They would still remain as unoriginal as before the change as there's no middle ground, no grey zone between something being original and something being not.

Summary: We only alter the layout of the disc if it has a practical benefit, such as transforming a downloaded fileset to a functional disc (Windows), or to fix actual layout issues that would cause the build to behave badly (such as unintentional trimming of long filenames to 8+3 filenames etc. as with some of the latest LH leaks). We do not alter timestamps or any metadata unless it absolutely affects the functionality (such as missing volume label on floppies where the installation software expects one).

We do not also assume a bunch of things when it comes to these development builds unless we have some undeniable proof. And we don't change stuff around unless we absolutely need to, such as fixing shortened filenames where there is not supposed to be any, or repair layout structure to make the installation work etc.
Image
Official guidelines: Contribution Guidelines
Channels: Discord :: Twitter :: YouTube

Post Reply