如何对此处使用的编码/解码方法进行逆向工程？
我有要编码的页面，也有要解码的页面。
但是，我不知道如何在没有网页的情况下自己完成此操作。
我想做的是弄清楚如何对跳跃链接进行编码，例如：
http://geoffreyf6.earth4.hop.clickbank.net
进入
http://8e5250ieuas1d9b9bo6c6p8xat.hop.clickbank.net/
编码/解码页面在这里：
http://www.clickbank.com/hoplink_encoding.htm
http://www.clickbank.com/hoplink_decoding.htm
现在，我知道我可以点击他们的网站进行编码（并且我已经有代码可以做到这一点）但是我我想知道幕后发生了什么。
输出中有 26 个字符，因此字母替换似乎是不可能的。
有 x、t 等字符，因此它不能是十六进制（而且它太短了）。
我不认为它使用任何类型的哈希，因为这必须是 100% 唯一的，并且所有哈希都有可能发生冲突，对吗？
关于如何解决这个问题有什么想法吗？
I have the page to encode and I have the page to decode.
I don't, however, have the knowledge on how to do it myself without the web pages.
What I'm trying to do is figure out how to encode a hoplink like:
http://geoffreyf6.earth4.hop.clickbank.net
into
http://8e5250ieuas1d9b9bo6c6p8xat.hop.clickbank.net/
The encode/decode pages are here:
http://www.clickbank.com/hoplink_encoding.htm
http://www.clickbank.com/hoplink_decoding.htm
Now, I know I could just hit their website to encode (and I already have code to do this) but I'm wondering what is going on behind the scenes.
There are 26 characters in the output so a letter substitution seems to be out of the question.
There are chars like x, t, and so on so it can't be in hex (plus it's too short for that).
I don't think it is using any type of hash because this has to be 100% unique and all hashes have a chance of a collision right?
Any ideas on how to figure this out?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在表单中输入相同的详细信息每次都会给出不同的编码，因此编码/解码实际上是用词不当。 更有可能的是，他们将记录与此标识符（无论它是什么）一起保存，并将其用于查找。 这意味着
a）该值有点任意
b）你将无法绕过他们的“编码器”
Entering the same details in the form gives a different encoding each time, so encoding/decoding is actually a misnomer. More likely, they're saving the record, together with this identifier, whatever it is, and use it for lookup either. Which means that
a) the value is somewhat arbitrary
b) you won't be able to bypass their "encoder"
对于正确的哈希算法来说，发生哈希冲突的几率确实非常低；非常； 我猜它是一个散列，可能带有一系列备用散列算法，以防发生冲突。
更新：理论上需要 2^128 次尝试才能合理预期使用 SHA-256 发生冲突（我说理论上是因为我似乎记得听说过一些对 SHA-256 的攻击减少了这个数字，尽管不是不安全使用当前硬件的级别）。
The chance of a hash collision for a proper hashing algorithm are really, really low; I'm guessing it's a hash, perhaps with a sequence of alternate hash algorithm in case there is a collision.
UPDATE: As in, it would theoretically require 2^128 attempts before you could reasonably expect a collision using SHA-256 (I say theoretically because I seem to recall hearing about some attacks on SHA-256 that reduce this number, though not to insecure levels using current hardware).