diff options
| author | Ave | 2025-03-29 01:43:55 +0000 |
|---|---|---|
| committer | Ave | 2025-03-29 01:48:24 +0000 |
| commit | dcfa95441a601e883d2c982f9cb70424a0954ba8 (patch) | |
| tree | 745b2d99bd6165f8dee3bbb38f63e248b23f5dd5 | |
| parent | 1e1f9bd754a5e2286caa2d1ff4364f216f907c62 (diff) | |
| download | massgrave.dev-dcfa95441a601e883d2c982f9cb70424a0954ba8.zip | |
Fix incorrect info
| -rw-r--r-- | docs/kms38.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/docs/kms38.md b/docs/kms38.md index c81efc4..f09d51e 100644 --- a/docs/kms38.md +++ b/docs/kms38.md @@ -16,7 +16,7 @@ - In the Windows major upgrade process, the system uses `gatherosstate.exe` to carry over the remaining KMS activation period. It does this by creating a ticket that can be used offline.
- The trick is that we can fool the `gatherosstate.exe` about the remaining KMS activation period and manually put the desired period maximum up to January 19, 2038, 03:14:07 UTC.
- Why is it limited to the year 2038?
- It's related to the [Y2K38 problem](https://en.wikipedia.org/wiki/Year_2038_problem) as this date (19 January 2038 03:14:07 UTC) is the maximum date we can give to `gatherosstate.exe` without it looping back to the year 1970.
+ This is due to the [Y2K38 problem](https://en.wikipedia.org/wiki/Year_2038_problem). This date (19 January 2038, 03:14:07 UTC) is the maximum value that can fit into a signed 32 bit integer.
- How can we convince the gatherosstate.exe?
There are two methods for it.
**1-** Place a [custom slc.dll](https://github.com/asdcorp/Integrated_Patcher_3) file beside gatherosstate.exe:
|