能否告诉我如何用Bin破解游戏,谢谢

boot.bin 和 eboot.bin 的区别

这两个文件都存在于 UMD/ISO 的 /PSP_GAME/SYSDIR 目录内，它们两者的本质是一样的，主要用于设置 PSP 游戏的运行环境，包括系统需求，频率设置，内存分配，资源路径等等。区别在于以前游戏的 boot.bin 是没有加密的，它的存在主要用于验证加密算法以及解密模块的追踪和调试；而 eboot.bin 是加了密的，因此 eboot.bin 可以理解为 Encrypted boot.bin，也就是加了密的 boot.bin。在以前的游戏中，boot.bin 含有具体数据并且系统需求是明文，因此自制系统里面有一个高级选项：通过直接执行 boot.bin 来启动游戏，该高级选项位于恢复菜单 Advanced->Advanced configuration->Execute boot.bin in UMD/ISO。在自制系统中启用该选项的话，有时候的确能在低版本系统中运行一些本来需要更高系统版本才能运行的游戏，譬如在 $ony 刚发布 5.00 系统的那段时间，有部分游戏是通过直接修改 boot.bin 的系统版本需求，并打开直接执行 boot.bin 选项来运行的，后来 $ony 封堵了这个漏洞，用 "00" 来对 boot.bin 进行填充，也就是“空”文件，不含任何数据，因此现在这条路已经行不通了。

PSP 的数据储存和处理

PSP 的 CPU 是 32 位 RISC 架构，数据储存是低位在前，高位在后，但 CPU 在处理数据的时候要反过来变成高位在前，低位在后。用过 IdStorageManager 或 KeyCleaner 的人应该有印象，key 从 Flash 中 dump 出来之后是反过来显示的，比如 0x0007 TA85/86/88 的亮度控制 key，首 4 位字节是 "APaD"，实际用 16 进制编辑器读出来是 "DaPA"。

如何区分未加密、已加密和已解密 eboot.bin 文件

可以用 16 进制编辑器查看。未加密文件头为 " PBP" 实际对于 PSP 来说是 "PBP "，相当于 Windows 的 .exe 可执行文件，虽说是未加密实际上还是用 Gzip 进行了封包；已加密文件头为 "~PSP" 实际对于 PSP 来说是 "PSP~"，相当于 Windows 的压缩文件(譬如 Zip/RAR/7z 等)，需要解包之后才能运行；已解密文件头为 " ELF" 实际对于 PSP 来说是 "FLE "，不能直接执行，但可以通过进程加载调用，相当于 Windows 的 .dll 文件。

$ony 采用的加密算法

$ony 采用的加密算法目前包括 Gzip，Rlz，Kl3e/Kl4e。其中 Gzip 是从 1.50 开始使用的，Rlz 是从 2.71 开始使用的，Kl3e/Kl4e 是从 3.80 开始使用的。

什么是 Tag，它有什么作用

Tag 是保存在 eboot.bin 文件中 0xD0 开始的 4 位字节。是用于区分文件加密法则的标签，告诉 PSP 该文件应该如何来进行解密。

各系统版本的 Tag 基本如下表所示：

Tag 0x08000000 - 1.xx eboot.bin

Tag 0xC0CB167C - 2.xx eboot.bin

Tag 0x8004FD03 - 2.71 eboot.bin

Tag 0xD91605F0 - 2.8x eboot.bin

Tag 0xD91606F0 - 3.xx eboot.bin

Tag 0xD91607F0 - 3.71 eboot.bin

Tag 0xD91608F0 - 3.8x eboot.bin

Tag 0xD91609F0 - 5.00 eboot.bin

Tag 0xD9160AF0 - 5.50 eboot.bin

Tag 0xD9160BF0 - 5.55 eboot.bin

Tag 0xD9160CF0 - 6.00 eboot.bin

Tag 0xD91611F0 - 6.10 eboot.bin

Tag 0xD91612F0 - 6.20 eboot.bin

如果你用 16 进制编辑器查看噗哟噗哟 7 的 Tag 的话(又或者 GVGNP，火影忍者 3 等等)，你会发现是 F01216D9，请不要奇怪因为前面已经提到过，数据保存是低位在前，高位在后。

替换 eboot.bin 的成功之路

实际 PSP 游戏执行的过程是：读取 eboot.bin 的 Tag 获得加密信息，然后根据相应的算法对 eboot.bin 进行解密，然后再执行。系统版本更新后，$ony 一般会对密匙进行修改或导入新的加密算法，这样就导致旧的系统版本不能对新加密的数据进行解密，从而导致游戏无法运行。但是如果我们将 eboot.bin 通过其他方式解密并替换，跳过 PSP 自己解密的那一步的话，这样游戏就可以顺利地被 PSP 直接运行了。5.50 GEN B2 闪红屏/D3 闪紫屏的过程其实就是 PSP 在解密 eboot.bin 的过程，执行解密后的 eboot.bin 就不会有这个闪屏了。5.xx 的内核对 UMD/ISO 的可执行文件进行了限制，不能直接执行 "PBP " 格式，实际上是将已解密的 eboot.bin 当成 PRX 来处理的。解密之后的 eboot.bin 你会发现要比原来的文件小一些，这是因为解密的过程将加密数据脱了壳，减少的那部分正是“壳”的大小。

eboot.bin patcher 的作用

主要是将解密后的 eboot.bin 系统需求版本从 5.50 改成 5.00，因此你会发现只改了 1 个字节，改 2 个字节的则是将 5.55 改成 5.00。有些游戏的 eboot.bin 根本就没有设置系统需求版本，因此什么都不用改(修改 0 字节)，所以这种游戏 3.71 也是可以运行的，大家请不要惊讶。

version.txt 的作用

version.txt 位于 /Flash0/vsh/etc 目录内，本来 $ony 是通过直接读取该文件来确认 PSP 系统版本的，自从 DA 发现了这个秘密之后，通过修改 version.txt 里面的内容来进行系统欺骗，实现以低版本系统冒充高版本系统。该选项位于恢复菜单 Configuration->Use version.txt，可以将 version.txt 的内容改成你需要的系统版本，这样就可以运行一些本来有更高版本需求的试玩游戏，以及早期登录 PSN。但现在 $ony 已经加强了系统版本的认证，直接修改 version.txt 已经无法登录 PSN 了。

PS：防止误刷官方系统的一个方法，将 version.txt 改成 9.99，这样在刷官方系统的时候就会提示版本已是 9.99 不用升级。

Opnssmp.bin 的作用浅析

采用 0xD91612F0 最新加密法则的游戏，其 UMD/ISO 的 /PSP_GAME/SYSDIR 目录内引入了一个新的文件 Opnssmp.bin。这个 Opnssmp.bin 可以用 PSARDumper 或者 PRXdecrypter 来进行解密，但 Opnssmp.bin 里面不含有任何密匙。它的作用仅仅是设置生成动态密匙，真正的密匙是通过 6.xx 内核的 mesg_leg.prx 来随机生成的。这样解密 eboot.bin 的过程又增加了一步，首先要调用 Opnssmp.bin 生成动态的密匙，然后再用这个密匙来解密。

0xD91612F0 最新加密法则的破解过程

破解者先是修改 Opnssmp.bin 以固定它所生成的密匙，然后根据这个固定的密匙来解开 eboot.bin 获取明文，因为 $ony 的算法已被掌握，比较明文和密文找到 eboot.bin 中调用 Opnssmp.bin 的那部分也不是什么难事，然后只要绕过调用 Opnssmp.bin 的这一部分就行了，这样就又回到了原来的情况。

5.00 M33 目前是否过时了

可以很肯定地告诉大家，破解者手中的自制系统主流还是5.00 M33，所以 Yoshihiro 发布 Gamedecrypter 以及 mc707 发布 eboot.bin patcher 都是因为 5.00 M33 庞大的用户群。继 5.50 GEN D3 发布之后 mc707 接着马上发布了 Edecrypt 也是基于同样的道理。当然喜欢尝鲜的朋友，喜欢第一时间玩新游戏的朋友刷 5.50 GEN D3 无可厚非，那是你的自由，有人坚守 3.71 M33 那也是他们的自由。

将来会不会有 PSPGo 或者 6.xx 内核的自制系统

同样可以很肯定地告诉大家，虽然 GEN 目前已经有了一个 6.00 的 HEN，虽然 PSPGo 也已经实现了 Hello World，除非近期 $ony 出现重大的技术泄密，又或者破解工作取得了辉煌的进展，否则在可预见的将来都不会有 PSPGo 或者 6.xx 内核的自制系统出现。因为 $ony 给 6.xx 内核加入了太多的障碍和限制，用破解者的原话来说是 "6.xx kernel is unfriendly"(6.xx 内核不够友好)。6.xx 内核的自制系统之路还有很长的路要走，GEN 之所以选择发布 5.50 GEN D3 而不是发布 6.00 GEN 是有它的道理的。