长期以来，我一直对Stalker门户中的媒体控制台授权这一主题感兴趣，但是之前没有。有一天，我不小心获得了Infomir MAG250前缀，因此决定解决此问题。训练
首先，我拆解前缀，将电缆焊接到连接器，然后将其连接到计算机。启动终端程序后，我对熟悉的U-Boot感到满意。也可以通过按任意键来中断引导过程（通常制造商会禁用此类芯片，并且您必须花费大量时间才能将U-Boot置于所需状态）。还可以通过ssh使用root特权进行访问。
该控制台配备256MB DRAM和两个闪存驱动器，即NOR 1 MB和NAND 256 MB。使用NOR，将在进程中加载U-Boot，该进程从NAND加载内核和文件系统。Getuid（）函数
前缀会在Stalker门户中授权自己，发送一堆任何信息，例如类型，固件版本，硬件版本，序列号等。但是我对gSTB.GetUID（）函数发出的device_id参数特别感兴趣。乍一看，它是像SHA256或MD5这样的哈希。参考官方文档soft.infomir.com/stbapi/JS/v343/gSTB.html#.GetUID，该函数最多可以包含两个参数，但是我感兴趣的第一件事是没有参数的选项。通过在IDA中加载stbapp，我们可以轻松找到此功能。
再往前走，我们看到了一个有趣的时刻
此处，程序分配0x41字节的内存，将其无效，然后调用驱动程序函数/ dev / stapi / stevt_ioctl，并将该内存和参数0xC004C919传递给它。因此，某个stevt_ioctl驱动程序负责生成UID。为了检查这一点，我快速绘制了以下代码：
在控制台上运行它，我看到了一个熟悉的UID。stevt_ioctl
下一步是拆卸stapi_ioctl_stripped.ko驱动程序，该驱动程序位于/ root / modules中。我们将驱动程序加载到IDA中，并找到处理程序0xC004C919 ioctl（我将此函数称为calcHash）。
有三个有趣的观点。首先，将0x41字节的内存从用户空间复制到内核空间（这正是用户传输的内容，在我们的示例中由零组成），调用get_mem_type函数（沿着内核本身的方式）和结果（再次为0x41字节），然后复制到用户的地址区域。为了找到get_mem_type函数的地址，我看到了两种可能性：看一下/ proc / kallsysms文件，希望访问不受限制，否则，否则在驱动程序本身的汇编程序中编写一个汇编程序，它将在正确的位置返回寄存器r0的值。在/ proc / kallsysms中查看后，我惊喜地发现了get_mem_type 0x8080E380 函数的地址。核心
为了进行进一步的分析，您将需要分析内核。内核本身可以在制造商的固件中找到，或者您可以使用U-Boot删除转储
或安装所需的分区。根据U-Boot信息，内核加载为0x80800000，入口点为0x80801000。我们将内核加载到 IDA中并找到get_mem_type函数。在分析了代码之后，我发现了本节，据说该节返回了UID。
因此，UID存储在0x80D635EC。接下来，我们在IDA中寻找该值的形成位置。这是在init_board_extra函数中（我不会翻译完整列表）
因此，这是在r4寄存器的地址处相同的未知值，从该值可以计算出感兴趣的哈希值（顺便说一下，fill_hash由SHA256解析）。我真的很想知道它是什么，所以我很快在汇编器中写了一个插入，该插入器通过printk函数在寄存器r2的地址处返回了内存的内容。以这种方式修改内核后，我制作了一个新的uImage并将其上传到USB驱动器。并在终端U-Boot中设置：usb start
fatload usb 0:1 80000000 uImage
bootm
但是在最后一支队伍之后，如此悲伤的等待着我，
U-Boot礼貌地拒绝运送我的新内核。编辑U-Boot
为了说服U-Boot引导我的内核，我决定使用mw命令本身将其修补到内存中。首先，我对NOR闪存进行了完整转储，它位于0xA0000000。将转储驱动到IDA之后，我发现了U-Boot复制自身的内存地址。这是0x8FD00000。同样，转储了这部分内存并运行了IDA之后，我很容易找到了一个检查签名的函数。如果一切正确，她返回0。此外，在两个不同的地方叫她。
这个功能到底做了什么对我来说并不有趣。她只需要这样返回0：mov #0x0, r0
rts
nop
U-Boot的相应代码现在如下所示：usb start
mw.l 8fd0ec08 000b200a;
mw.l 8fd0ec0c 00900009
fatload usb 0:1 80000000 uImage
bootm
然后，U-Boot愉快地加载了我的内核，该内核发出EF0F3A38FF7FD567012016J04501200:1a:79:23:7e:2MAG250pq8UK0DAOQD1JzpmBx1Vwdb58f9jP7SN
全面分析
那么，UID由什么组成？它是一个未知的8字节数，控制台的序列号，MAC地址，控制台的类型和一块垃圾。剩下的就是找出那是什么未知数字以及垃圾来自何处。我又回到了init_board_extra函数。此代码段中提取了一个未知的数字：
在这里，使用__ioremap函数，内核访问了物理内存0x00000000（这是闪存的NOR地址），将0x0F写入0x00000000，然后将0x98写入0x000000AA，并从0x000000C2开始读取8个字节。还有，这是什么？这些是内核与NOR通信的CFI协议命令。 0x0F使NOR进入原始状态，并使用0x98切换命令mods CFI。在此模块中，地址0x000000C2是安全代码区或64位唯一设备号。那些。未知号码是唯一的NOR闪存号码。以下是CFI标识的转储。
您可以通过设置直接在U-Boot中创建转储mw.w a0000000 f0
mw.w a00000aa 98
md.b a1000000 100
一块垃圾只是一个普通的32字节字符集，它被缝入内核本身，
并且在使用加密函数swap_pairs之前已对该垃圾进行了处理，该函数只是更改了字节的位置[0x00000003]<->[0x0000000F]
[0x00000005]<->[0x0000001F]
[0x00000009]<->[0x00000002]
[0x0000000A]<->[0x0000001D]
[0x00000010]<->[0x00000015]
[0x00000004]<->[0x00000013]
[0x0000000D]<->[0x00000018]
根据收到的信息，我敢于假设制造商的数据库包含有关每个ID NOR闪存的信息以及相应的序列号和MAC地址。当然，不可能选择所有这些，但是您可以编写自己的软件，该软件可以完全模拟控制台。