cIOS 38(rev17)源代码导读

hqyhqyhqy

WII编程领域(这里将破解和自制软件开发通称为编程)经历塞尔达TP HACK，自制软件开发，cIOS开发，即将走入二次开发时代，以往人们的视线都放在微内核的驱动层程序的开发上，但随着新超马LeiJi Loader，零4的RiiRevolution Loader(其完整版宣称1-2月后放出，将支持所有游戏)，以及未来的一些可能出现的玩意儿，应用层上的再开发将逐渐成为下一个阶段的主旋律，我最近业余时间的工作正是致力于简化这一过程，简单说来就是让懂得使用脚本语言的人能做这部分开发，而不用自行编写汇编代码，将底层剥离出来。

比如，http://www.rayfile.com/zh-cn/fil ... -81c0-0014221b798a/，这个架在neogamma上的loader,在玩日版的太鼓达人一代时，会将手柄向下打鼓动作识别为手柄按键，只是实验，对是咚还是咔判断不准，这只是一个简单的例子，表达出一种二次开发与原程序无缝柔和的气氛。

不过最近几天的基本实验遇到点问题，来这换换心情，国内有一些自制Loader开发者，随着cIOS38的开源，也许会涌现一些驱动开发者。

---
打开cIOS38的源代码包，.h后缀的文件是头文件，.c后缀的是C语言源代码文件，.s后缀的是汇编代码文件。

首先应该了解从应用层到驱动层的访问流程。
应用层访问DVD设备时，会调用IOS_Open("/dev/di",mode);
成功打开设备后即可调用IOS_Ioctl系列函数传输控制码进行期望的操作。

而这些操作都会传达到驱动层进行处理。
cIOS38是DIP部分，也就是当应用层访问设备路径/dev/di会自动访问它。

观察stub.s文件：
    .global _emulateIoctl
_emulateIoctl:
    ldr    r3, =DI_EmulateIoctl + 1
    bx    r3

    .global _emulateCmd
_emulateCmd:
    ldr    r3, =DI_EmulateCmd + 1
    bx    r3

WII微内核跑的是ARM THUMB指令，ldr为寄存器写值，bx为跳转到该处执行，也就是按文件名所描述，这是两个跳板函数，按照某种规则(这个这里不用深究)符号_emulateIoctl会在派发控制码时被进入，这里就跳转到DI_EmulateIoctl函数执行。

从函数名来看，这个函数用来模拟控制码传输操作，打开plugin.c寻找它，可以看到它对自己关心的几种命令做了处理，其他情况都调用原始函数进行默认处理。这里仔细看下DI_EmulateCmd函数，主要控制相应都在这里被处理分发，比如：

    /** Disc BCA read **/
    case IOCTL_DI_READBCA: {
        /* Read disc BCA */
        ret = __DI_ReadUnencrypted(outbuf, size, 0x40);

这就是新超马和阿凡达所使用的BCA保护，此保护实际是从应用层对设备传输一个IOCTL_DI_READBCA控制码获取BCA数据，而早些时候的cIOS没有对此控制码进行相应，而直接进入默认过程，回到应用层后数据校验错误，于是进入惩罚函数，表现为黑屏或者说明书之类，所以说来很可笑，新超马的所谓破解只是在进入惩罚函数时直接返回，治标不治本，不过它是有效的:)

plugin.c文件顾名思义，他是DIP插件的主体，根据设置的情况(谁设置呢？自然是loader)将数据控制分派给DVD光驱或者WBFS格式的磁盘存贮，DIP插件设置结构体定义在plugin.h里，可自行观看。

当设置为光盘执行时，操作被路由到dip.c中的函数里，设置为WBFS格式执行时，操作被路由到wbfs.c中的函数里。

这个文件中有定义：
static char *fs[] = { "/dev/usb/ehc", "/dev/sdio/sdhc" };

前者是USB2.0设备路径，后者是SDHC卡的设备路径(???  /dev/sdio/slot0是普通SD卡的设备路径可以确定 )，则在WBFS_Init函数中，打开设备fd = os_open(fs[device], 1);

根据传入参数的不同打开USB硬盘或者SDHC卡，这里的参数1是指打开模式为读。

工程里也不是所有函数都是wanin自己实现的，有一些是调用原始过程来实现的，还有一些则是系统调用。

打开syscalls.s查看系统调用列表，这里定义了各个底层函数的系统调用号，打开arm_syscalls可以看到系统调用的触发过程，SVC其实就是以前的SWI，也就是软中断。这个不用关心，知道有哪些底层函数可用就够了。

打开link.ld会看到一些原始过程函数的地址，这应该是通过逆向工程手法定位到的，一般开发不会去涉及它，在访问DVD设备时对控制码调用原始处理过程将进入这些函数中，具体路由过程可以参考dip_calls.s文件.

wiiwaker

好文~

“我最近业余时间的工作正是致力于简化这一过程，简单说来就是让懂得使用脚本语言的人能做这部分开发”
这就是楼主大大前几天说的新玩意吗？真是一个大大的surprise啊
出来后势必会产生很多有趣的应用，非常期待~

hyew

看来是个马甲高人。。。。从ID上来看。。
还有。。文章看不明白。。但还是支持一下~

hqyhqyhqy

@wiiwaker

那个新玩意其实可以看做上面说的那个东西的一个“应用例子”，其实也就是游戏通用文件重定向到SD卡的代码库，提供给各个WII LOADER使用，这样可以避免伤害到开源软件以及可能的法律纠纷(不去修改游戏公司的版权文件)，因为这些代码在loader层面触发，其实并不对loader生效，而是对被load的游戏生效。

目前在一个底层问题处卡住了，在解决前一切都没法进展，那个SD卡重定向库在GBATEMP上已经提过了，之后几天零4小组的Tempus就放了他们的loader(因为不打算开源所以只能boot正版光盘),并宣布1-2月后放出支持任何游戏的完全版，隐式的构成了竞赛(这个Tempus也是雷吉关卡编辑器小组的)，目前来看稍微有点危险.

脚本语言我选择用Lua,应该说比汇编C什么的好学多了，做这套东西的想法已经验证过，但是实现中遇到具体问题也是不可避免的。

@hyew

感谢支持，这种概念性的东西在没发挥实际作用前可能不太好看懂是做什么的，另外这帖子是源代码“导读”，对于想读这套源代码的人起个引导作用应该是没多大问题的。

zoujilong

过来支持一下。。。

youth

强文，对cios的机理有了更多的了解：）

该用户已被禁言

又一个代码级的强人
想请教下lz，目前只有少数游戏采用了BCA保护校验？介揍似之前游戏木有问题，而少数新游戏有问题的原因？
（可能问题比较白，请不吝赐教）

hqyhqyhqy

@njtumaq

确实介揍死之前游戏木有问题，而少数新游戏有问题的原因。

老任在WII软件上的最大错误就是让早期的官方开发包在网络上肆意流传，而新版开发包无论如何进化，也不可能说和早期的完全不同，所以说对有经验的逆向工程工作者来说看WII的发行游戏中的程序在某种程度上说只要有点耐心就跟读自己写的自制软件没什么区别。

而这种强度的所谓逆向工程在要求工作者对工作平台有基本了解后，用一个朋友的话说，只是文字排版处理一级的工作。

pengomega

说句实话~ 这些讲解依旧难懂

借个地方说句话
http://gbatemp.net/index.php?showtopic=205511

其中的 bootmii mini 是需要怎么的编译环境~
只查到有源码。但是不知道如何构建编译环境

hqyhqyhqy

@pengomega

昨天只是写程序郁闷了过来乱谈几句，看代码这事如果有些基础不具备的话恐怕要讲清楚得说上几天，把cIOS主体结构剖析清楚我的目的就达到了，一些细枝末节的地方说起来也没什么意思。

那个工程很有意义，其实在应用层重定向访问到NAND比重定向到SD卡要简单的多，但在系统菜单中做这件事可能难度类似，因为系统菜单程序中有以文件系统方式读取SD卡中文件的现成函数。

bootmii没编译过，找个arm的gcc试试，强烈建议安装devkitpro