可是为什么要在这种场景上使用 RSA 呢？
以及同时你还将自己的 ssh 私钥置于了危险之中（读入内存以后没有清空）

安利一个自己的答案： https://www.zhihu.com/question/29865340/answer/119744048

我记得半个月还是一个月前还推过通知，说是为了维护和手机版一样的体验，淘宝 HD 不是要停掉就是要改版了（反正就是这个意思），然后就变成现在这个样子了。。。

@baogaitou 不不，是我要感谢您，提供给我了一些原本不明确的信息。改日我打算拆设备时再来请教您。

@baogaitou 感谢！我也觉得这个路由器特别有可玩性，性能也不差，但因为里面用的是 coreboot+chromeos 感觉很容易搞坏又不太好修复的样子，所以才想买坏的来拆。。。

我看了一下网上的 PCB 是有开关的，附图：
http://imgur.com/a/TMbtV
http://imgur.com/a/t9OE4

红框圈出的 SW6 和 SW7 就是我说的开关，如果你的 PCB 上没有的话应该是 PCB 的版本不一样吧，从开源的的代码上看 Gale 有至少 5 个版本的 PCB ，不知道会不会是后续版本阉割了调试功能，如果是这样就很无奈了。

三个打问号的地方从网上的拆解来看貌似是没有连接东西的，旁边还有标记为 TPx 的调试点，感觉要是能知道这些 IO 接口怎么用会非常有戏啊。

只看出这么点东西来，还请您指教

@baogaitou 感谢！我自己有一个可是舍不得拆。。。依着前两代 onhub 的尿性看是卸下一个螺丝就开启 developer mode 的，不知道这一代是怎么设计的，我看网上的图好像在 PCB 的正中间正反两面都有一个按钮的样子，不知道是不是真的按钮。

山寨看起来会比较难吧，有 root 之的兴趣吗？ chromeos 也算是个 linux 可玩性应该不会太差。

PS ：不知道您手上那台坏成什么样子了，有出的意向吗？

@baogaitou 请问有高清 PCB 图和结构图吗，网上一直没有找到完整的拆开图，比如有个红白电线的插座不知道是连在哪里的，以及看 IO 板好像是用 PCI-E 类型的插座连起来的，不知道会不会把剩下的 3 个千兆口也引出来。
照理说 Google 的路由器上都有 developer mode 的按钮的，要是能找到的话对 root 里面的 chromeos 很有帮助。

@rekulas 我也只是略微知晓一点，所以技术上的讨论还是放在这里吧，有更厉害的看到了也能指点一下。私以为 hiddenkey 没有太大用处。如果让我设计的话，最简单的就是最保险的，每个文件随机产生一个定长 IV ，正确使用 AES 产生伪随机数并与明文异或，最后把 IV 放在密文之前就行了，如果需要 MAC 的话可以用 HMAC 附在明文后，简单方便，几乎避免了我上面提到的所有问题

@rekulas
我又仔细读了一下算法，发现自己漏看了 keyC 是随时间变化这个关键点，所以选择明文攻击只能有限度的进行
吐槽一下那段 c 代码，看起来很头大，很多循环和变量完全都可以合并在一起，很多地方看起来很危险很容易越界的样子

下面是我看出来的一些弱点：
1. 使用了基于时间的 IV
这是最大的弱点，其使得选择明文攻击得以成为可能。仔细观察一下，你可以注意到挂出来的那个文件夹里 5+3 个文件都共享了相同的 IV ，如果计算速度足够快，就有可能整个项目共享一个 IV ，相同 IV 的文件中只要一个文件的明文已知就可以推出其他文件中至少一部分的明文内容了。原理是 ciphertext xor plaintext = key ，不详述了。

2. 加密方法暴露了密钥长度
算法没有规定最小密钥长度，这本来不算大问题，但是对 keyC 画蛇添足进行截断就会暴露原始密钥的长度。试想使用者如果设定了一个较短长度（比如 32bit ）的密钥，攻击者就可以在十几分钟内通过穷举攻击破解出来。

3. 密钥空间不够大
算法一开始就把输入的 key 做了 md5 ，然后平分拆成 keyA 和 keyB ， md5 输出一共才 128bit ，拆一半只有 64bit 了，由于 keyC 随密文提供，完全秘密的只有这 64bit 的 keyA ，虽然穷举 2^64 也是非常困难，但我觉得在现代密码中这也能算得上是一个设计弱点了。

4. MAC 设计有问题
我读了算法发现前面被分出来的 keyB 只在预处理明文的时候被用到过，结合上下文我大胆的猜想你是想要实现 MAC 机制。然而 MAC 机制本不需要用到密钥来实现，这里分出 keyB 既没有好处，也影响到了密钥空间的大小。

5. 过期机制的实现有问题
源码里有提到 expire 的概念，相信你是想提供过期机制吧，但这个过期只能在逻辑上做判断，并没有提供数学上的保证，如果攻击者在过期后获取到密钥，仍然可以构造出 keyA 并对文件进行解密。

综上所述，这个算法的核心就是一个内部基于 RC4 ，并且提供了初始向量支持的代码加密算法。先不说对解释执行的代码进行加密是否有意义，即使作为纯文本加密，也是有很多弱点的，而这些弱点并非理论本身的缺陷，都是在你设计加密算法时不慎引入的，我没有接受过系统的信息安全训练都能看出那么多问题，所以不建议自己设计加密算法的原因就在这里。

@rekulas 好吧是我理解错了，撤回上一条回复

@rekulas 你提供的压缩包里一共有 8 个文件，其中`install_var.php`, `install_extvar.php`, `install_mysqli.php`这三个文件的加密密钥和其他五个文件不同，同时这两个加密密钥和你在主贴里提供的以`f83c0c86454591265c9f772eb499ea4a3+Mrn7H3huTwgitNLGtAZlrixw5B`开头的密文使用的密钥也是不一样的

@rekulas
你在帖子正文中附了一串挑战用的 code ，是一串经过你的算法加密后的密文，这条密文对应的明文长度比如说是 100 ，我现在需要的就是长度大于 100 的使用同样密钥加密的明文密文对

@rekulas 我看下来就是完完全全的 RC4 啊，都没什么改变。
理论上做已知明文攻击只要一条明文密文对就行了，要求是加密用的密钥和你给出的挑战用密文使用的密钥是一样的，明文的长度不小于挑战用明文，其他没什么了，我想试试看。

如果我没理解错的话楼主的算法其实就是 RC4 吧，有统计学弱点，但光凭一条密文做唯密文攻击是很困难的
不过这不代表不能玩已知明文攻击啊，楼主愿意的话再用相同的密钥加密一串等长随机字符串，把明文和密文都发上来就可以玩了。

@yymdude 不不 是两回事 看这里https://developer.chrome.com/extensions/windows#type-Window的type字段 有一个panel，但貌似只能在dev下用，如果我没记错的话

4楼说得对 看这个样子应该不是普通窗口 看样子不是popup就是panel了 什么叫改action添加监听？

的确是有区别 但和污染没有关系吧