首先我要感谢a9vg论坛的liquidzigong 也就是xReader的作者hrimfaxi(hrimfaxi是他在CG里面的称号) 他破解了MGSPW 一骑当千 东京鬼拔师...等等 其实伊苏F应该也是用他提供的代码解出来的 先不说这个 今天要说他对KHBBS的破解情况 KHBBS破解应援楼，不断更新...<最後一战> http://bbs.a9vg.com/read.php?tid=1464857&fpage=1 此贴被liquidzigong在2010-05-06 13:01重新编辑 现状： KHBBS缺失的函数所在的PRX： usersystemlib.prx (这个已搞定) utility.prx(这个已搞定) sysmem.prx(最後一战) GEN TEAM所谓的记忆卡封堵问题已解决！ 最後一战：看了看最近破解的MGSPW、YSF等游戏， 发现KHBBS和他们的初始化方法不太一样。 但愿这个是死机的唯一原因。 ================================================ 对sceUtility缺失的几个函数分析取得重大成果， 我已经知道为啥KHBBS读umd死机了发现了惊天秘密， 原来sony竟.....看来要打一场持久战了目前我只能说这麽多， 不能再发生上次的泄密事件了。 KHBBS这个记忆卡保护是KHBBS不能运行的关键问题！ 以前日本人对它的补丁完全是错误的！ 缺失函数已经不是重大问题了。 记忆卡保护才是KHBBS不能运行的关键问题。 ================================================ BBS1.DAT的解密这个有点奇怪，我本以为不能成功的， 对破解的理论是个打击，还没破解，就可以汉化了， BBSX.DAT里的都是游戏资源。我还不知道为什麽不能直接解密。 最简单的破解方法倒是想出来了，需要一台ＰＳＰ３０００或ＧＯ，６.２０固件。 ================================================ 部分档已经解密成功，NID也已经基本修复成功，曙光就在前面！ 加油啊！ 破解未出，汉化先行……以下是解密后的资源 ================================================ 搞到半夜才发现BBS0/4.DAT是没有加密的，还有sysmem.prx的函数没有处理。 真希望就是它导致出错啊。 我都做到这地步了。 不想前功尽弃啊。。。 我觉得那个记忆卡保护已经被干掉了，因为已经听到功能表按键声， 说明已经从记忆卡里读出音频资料。 但是出这个不大不小的BUG进不了游戏真令人心烦…… ================================================ 心静若水，最後一个未知函数已经被验明正身。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 112.104.80.50 ※ 编辑: q0212908 来自: 112.104.80.50 (05/06 16:03) 2010-05-06 22:25更新 ================================================= 所有函数都被解析，记忆棒保护也被解除，可就是进不了游戏………… 山穷水尽疑无路？ 如果一直不能破解，我将把全部的研究成果公开，希望下一个勇者能继续挑战。 ================================================= ※ 编辑: q0212908 来自: 112.105.217.128 (05/07 05:50) 国人破解王国之心最後文件解决 禁止记忆卡仍在作祟 http://psp.duowan.com/1005/137248131606.html 　　昨天为大家报道了国人liquidzigong（同时也是读书软件xReader的作者hrimfaxi） 已经将《王国之心 梦中降生》的破解进行到了最後一步， 而今天又有了最新的进展！ 　　昨天说的sysmem.prx问题已经得到解决， 然而目前发现游戏还是不能正常运行， 最终作者确定了这个问题果然还是因为「禁止读取记忆卡」功能所导致， 而前面日本人放出针对该机能的补丁其实是没有用处的， 这意味着需要重新对该功能下功夫，现在看来距离我们玩到这款大作， 还需要更多的一点耐心。 -- 结果.....又回到原点................什麽阿～ 翻桌 2010-05-08 14:23更新 ================================================= 其实破解就像抓罪犯： 现在我的5.03FW: 缺失函数补完了 记忆卡保护解除了 哪还有什麽马脚会可能泄露呢？ 唯一的犯人就是：解密后BBS1/2/3.dat文件比源文件更小。 如果SE把文件大小检查一下的话，就有可能发现有马脚！ 果然！ 看了下DiscInfoBind程序发现SE有记录BBS1/2/3.dat文件的 真实大小和文件创建时间，说不定就是这里有鬼！ ================================================= 恩，还保存了BBS1/2/3/.dat 的第一个LBA地址 ================================================= 已经写出程序获得BBS1/2/3.dat的SceIoStat信息了， 已经获得破解版的信息，正在复制原版到ISO目录，准备对比下有什麽不同 惨剧，还是老样子 插件欺骗程序工作正常，连我的测试程序都能骗过，可还是老样子- - myIoGetstat: disc0:/PSP_GAME/USRDIR/BBS0.DAT myIoGetstat: disc0:/PSP_GAME/USRDIR/BBS1.DAT Cheat BBS1 myIoGetstat: disc0:/PSP_GAME/USRDIR/BBS2.DAT Cheat BBS2 myIoGetstat: disc0:/PSP_GAME/USRDIR/BBS3.DAT Cheat BBS3 myIoGetstat: disc0:/PSP_GAME/USRDIR/BBS4.DAT 可以看到BBS1/2/3.DAT已经在欺骗了。 如果大家发现了能进游戏主界面的EBOOT.BIN请务必传我一个 ================================================= 一些新的怀疑： 是不是用到了sceIoOpenAsync? sceIoOpen的标志是否都正确？ 还有个疑点: Kernel_Library_37431849这个函数。 在YSF中没有用到，在KHBBS中被用到。 YSF和KHBBS都有用它所在的PRX: usersystemlib.prx， 然而YSF只用到比较简单的: Kernel_Library_A089ECA4, Kernel_Library_1839852A, Kernel_Library_293B45B8。 这几个函数只用几行指令，非常简单，当然没有它们的话是不要想玩游戏的。 YSF补丁就是用620的PRX补全了这三个函数，才让大家开始游戏的。 而Kernel_Library_37431849，在KHBBS的0x088c2cbc被调用， 奇怪的是0x088c2cbc这个地址却没被任何静态地址所调用。 值得注意的是， 出错线程AsyncFileAccess主要使用函数指针数组而不是静态地址调用函数。 看来要多加关注。 会不会是Kernel_Library_37431849不能用简单的PRX替换法？ 还是usersystemlib_620.prx必须先与usersystemlib_5XX.prx运行？ 提示： Kernel_Library_37431849和503里的Kernel_Library_DC692EE3，很相似。 我现在在加班，下班後才能开干。 =================================================== 我明白了! Kernel_Library_37431849是个尝试信号量是否可用的函数， SE的判断是只要返回不是0x800201c4就认为信号量可用。 然而可能Kernel_Library_37431849并没能成功， 返回了不是0x800201c4的其他错误值。 结果程序就错误认为信号量可用，所以在多线程环境中就出错了…… 晚上回家去试试看。 ================================================ 现状： KHBBS缺失的函数所在的PRX： usersystemlib.prx (在怀疑这里...) utility.prx(这个已搞定) sysmem.prx(已经确定没影响？相似的钢铁侠2同样能运行) 记忆棒封堵问题应该是解决了 思路： 如果我们让5.XX固件和6.20固件一样，拥有完全一样的API接口， 完全一样的功能，各种程序内外环境完全一样， 并且想办法让SE察觉不出资源数据文件发生了变化。 那一定不用到处修改游戏程序而成功运行。 因为6.20毕竟也要兼容老游戏，API接口一样，功能却发生变化的情况毕竟很少。 比如YSF只缺了三个简单的函数，经过补全6.20 PRX后就可运行了。 现在就要关注下 usersystemlib620.prx的最后一个函数Kernel_Library_37431849是否真的可用。 liquidzigong在2010-05-08 14:23重新编辑 -- 不要问我 我也看不懂作者在说什麽..... 简单说遇到贫井了 ※ 编辑: q0212908 来自: 112.104.211.173 (05/09 03:53) =================================================== [ 此贴被liquidzigong在2010-05-09 22:59重新编辑 ] 我写的usersystemlib补丁甚至能让YSF正常运行。 然而KHBBS出错还是如故。 不过我还是成功修复了一些函数， 已经不需要userlibsystem620.prx了。 轻量级信号量已经正常了。 但是AsyncFileAccess线程还是会出错。 =================================================== 经过艰苦调试後发现， AsyncFileAccess线程在读取已解密文件BBS3.DAT後，马上死机。 这是说明解密文件不正确吗？ 还是有其他的问题？ =================================================== 缺失NID已经完全被修复： 0x180F7B62 [0x08B249BC] - sceUtility_180F7B62 0x24AC31EB [0x08B249C4] - sceUtility_24AC31EB 0x32E32DCB [0x08B249DC] - sceUtility_32E32DCB 0x4AECD179 [0x08B249F4] - sceUtility_4AECD179 0xB57E95D9 [0x08B24A4C] - sceUtility_B57E95D9 0xA089ECA4 [0x08B24E0C] - Kernel_Library_A089ECA4 0x1839852A [0x08B24E24] - Kernel_Library_1839852A 0x293B45B8 [0x08B24E34] - Kernel_Library_293B45B8 0x37431849 [0x08B24E3C] - Kernel_Library_37431849 0x35669D4C [0x08B24EB4] - SysMemUserForUser_35669D4C 这些NID已经完全被解析，如果GEN队没有保留什麽我们应该已经玩上游戏了啊？ =================================================== 看了看噬神者的情况: 1. 缺失NID 2. 数据文件加密 3. 自修改代码，有许多Sync Break指令像地雷一样多 4. 真正的模块藏数据文件里 算了吧，我们还是回到破解KHBBS上吧。我靠你NAMCO！ =================================================== 已经在联系国内外破解高手一起攻关KHBBS。 [ 此贴被liquidzigong在2010-05-09 22:59重新编辑 ] ※ 编辑: q0212908 来自: 112.104.136.231 (05/10 01:44) [ 此贴被liquidzigong在2010-05-10 23:49重新编辑 ] =================================================== 1. 解密文件是否解密正确？ 2. 解密文件打入ISO的方法是否合适？ 3. 能不能更接近死机现场？ =================================================== 能进Intro了，但在主菜单显示之前死机 =================================================== Exception - Bus error (data) Thread ID - 0x0473071D Th Name - user_main Module ID - 0x032BE735 Mod Name - MainApp EPC - 0x088DE868 Cause - 0x1000001C BadVAddr - 0xFFFBF5FF Status - 0x60088613 zr:0x00000000 at:0xDEADBEEF v0:0x00000000 v1:0x00000000 a0:0x00000000 a1:0x000000FF a2:0x08B09C08 a3:0x00000000 t0:0xDEADBEEF t1:0xDEADBEEF t2:0xDEADBEEF t3:0xDEADBEEF t4:0xDEADBEEF t5:0xDEADBEEF t6:0xDEADBEEF t7:0xDEADBEEF s0:0x00000000 s1:0x000000FF s2:0x00000000 s3:0x09BEFCF0 s4:0x09F20000 s5:0x08B20000 s6:0xDEADBEEF s7:0xDEADBEEF t8:0xDEADBEEF t9:0xDEADBEEF k0:0x09FFFB00 k1:0x00000000 gp:0x08BCA930 sp:0x09FFF530 fp:0x09FFFA90 ra:0x088DE78C 0x088DE868: 0x8C840000 '....' - lw $a0, 0($a0) 高度怀疑sceKernelCreateLwMutex是不是元凶。 [ 此贴被liquidzigong在2010-05-10 23:49重新编辑 ] ※ 编辑: q0212908 来自: 112.104.4.160 (05/11 02:22)