如何从给定的 GUID 预测下一个 GUID？
我已经向我们的客户发送了 10000 封邮件，每封邮件都有一个格式的链接
http://example.com/LogIn?key={guid}
不幸的是，我发送的 guid 是随机的 guid（测试数据由 Guid.NewGuid() 生成）所以客户都收到了无效链接...
根据我从网络服务器收到的 404，我发出了一些指导。 我读到 Windows 中的 guid 生成器很弱，因此您可以从已有的 guid 中预测下一个 guid。 有人知道怎么做吗？ 如果我能做到这一点，我就可以使我发送的指南有效，这样链接就可以再次工作。
I have sent 10000 mails to our customers and each mail had a link of the format
http://example.com/LogIn?key={guid}
Unfortunately the guid I sent were random guids (test data generated by Guid.NewGuid()) so the customers have all received invalid links...
Based on the 404s i receive from the webserver I have a few guids that I sent out. I have read that the guid generator in windows is weak so you can predict the next guid from one you already have. Does anyone know how? If i could do that I could make the guids I sent out valid so the links would work again.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
Windows 生成 GUID 的方式已经改变了好几次，并且互联网上许多看似可靠的建议是完全错误的（也许只是过时，也许总是完全错误）。
上次我研究这个问题时（几年前，可能是 XP SP2），我直接进入操作系统代码以查看实际发生的情况，它正在使用 安全随机数生成器。
我怀疑如果您以默认方式生成 GUID，您是否会很幸运地从另一个 GUID 中预测出它们。
The way Windows has generated GUIDs has changed several times, and lots of seemingly reliable advice on the internet is completely wrong (maybe just out of date, maybe always completely wrong).
The last time I looked into this (a few years ago, probably XP SP2), I stepped right down into the OS code to see what was actually happening, and it was generating a random number with the secure random number generator.
I doubt you'll have much luck predicting one GUID from another if you generated them in the default way.
首先你需要知道它们是否符合RFC4122，并且你需要获取版本。
如果是 UUIDv1，您可以预测它们
UUIDv1 由以下部分组成：
您只需迭代可能的时间戳。 请注意，那里有很多 100 纳秒的间隔！
有些软件生成 UUIDv1（Grafana 仪表板 ID、Airbnb 列表等），但有些软件依赖随机 UUID、UUIDv4。
如果是 UUIDv4，您可能会窃取 PRNG 上下文
正如 Nikolay «denish» Denishchenko（卡巴斯基）不久前所演示的，如果对生成 UUID 的进程进行调试访问，则可以窃取当前的 RC4 上下文并在其他地方重现最多 500000 个 UUID。 这已经在 Microsoft Windows XP 上得到了演示（嗨，Will Dean），它使用了有趣的 8*RC4 机制，并且每 500000 个 UUID 才播种实际熵。
在 Windows 10 上（不完全是 Windows 版本，而是 .NET Framework 或 rpcrt4.dll 版本），它不再是 RC4，而是 AES，大概在 CTR 模式下使用。 大概存在相同的熵重用。
有关更多信息，请查看我在那里所做的工作 https://uuid.pirate-server.com/blog /
First of all you need to know if they are RFC4122-compliant, and you need to get the version.
If it's UUIDv1, you can predict them
An UUIDv1 is made of :
You just have to iterate over the possible timestamps. Beware, there are a lot of 100-ns intervals out there!
Some software are generating UUIDv1 (Grafana dashboards IDs, Airbnb listings, etc.) but some software are relying on random UUIDs, UUIDv4.
If it's UUIDv4, you might steal the PRNG context
As demonstrated a while ago by Nikolay «denish» Denishchenko (Kaspersky), given a debugging access to the process generating UUIDs, one can steal the current RC4 contexts and reproduce elsewhere up to 500000 UUIDs. This has been demonstrated (hi, Will Dean) on Microsoft Windows XP which used a funny 8*RC4 mechanism and only seeded with actual entropy every 500000 UUIDs.
On Windows 10 (it's not exactly the Windows version but rather the .NET framework or the rpcrt4.dll version), it's not RC4 anymore but an AES, presumably used in CTR mode. There is presumably the same entropy reuse.
For more information, check the work I did there https://uuid.pirate-server.com/blog/
有几种不同类型的指南。 类型 1 使用主机 ID（通常是 MAC 地址）、序列号以及当前日期和时间。 类型 4 是完全随机的。 如果它是类型 1 UUID，您可能可以找出一组相当有限的可能的 UUID，但即便如此，您也无法生成单个 UUID 序列，因此您将无法确定特定用户的特定 UUID。
There are several different types of guids. Type 1 uses a host ID - usually a mac address - a sequence number, and the current date and time. Type 4 is entirely random. If it's a type 1 UUID, you can probably figure out a fairly restricted set of likely UUIDs, but even so, you're not going to be able to generate a single sequence of UUIDs, so you won't be able to pin down a specific UUID to a specific user.
即使您能做到，预测下一个 GUID 也是不可靠的，但就您所掌握的资源而言，这很可能是完全不可能的。
这里最好的选择是简单地添加从任何不匹配的 GUID 到通用页面的手动重定向，该页面要么解释出了什么问题，要么只是以编程方式找出它们应该结束的位置并将其发送到那里。
Predicting the next GUID would be unreliable even if you could do it, but more than likely is completely impossible with the resources at your disposal.
Your best bet here is to simply add a manual redirect from any non-matching GUID to a generic page that either explains what went wrong or just programmatically figures out where they should have ended up and sends them there.
GUID 的一部分是当前日期/时间。 如果您碰巧连续收到其中两个，那么您可以知道它们的创建速度有多快，从而很有信心地预测顺序。
Part of a GUID is the current date/time. If you happen to receive two of them sequentially, then you can tell how fast they are being created and therefore predict the sequence with strong confidence.