I have long been interested in the topic of authorization of media consoles in the Stalker portal, but it was not before that. One day I accidentally got the Infomir MAG250 prefix and I decided to tackle this issue.Training
First of all, I disassembled the prefix, soldered the cable to the connector and connected it to the computer. Having launched the terminal program, I was pleased with the familiar U-Boot. The boot process could also be interrupted by pressing any key (usually the manufacturer disables such chips and you have to spend a lot of time to bring U-Boot to the desired state). Access with root privileges was also available via ssh.
The console is equipped with 256MB DRAM and two flash drives, NOR 1 MB and NAND 256 MB. With NOR, U-Boot is loaded in the process, which loads the kernel and file system from NAND.Getuid () function
The prefix authorizes itself in the Stalker portal, sending a bunch of any information, such as, for example, type, firmware version, hardware version, serial number, etc. But I was specifically interested in the device_id parameter, which the gSTB.GetUID () function issued. At first glance, it was a hash like SHA256 or MD5. Referring to the official documentation soft.infomir.com/stbapi/JS/v343/gSTB.html#.GetUID , the function can take up to two parameters, but the first thing I was interested in was the option without parameters. By loading stbapp in the IDA, we can easily find this function.
Going a little further, we see an interesting moment
Here, the program allocates 0x41 bytes of memory, nullifies it, and calls the driver function / dev / stapi / stevt_ioctl, passing it this piece of memory and the parameter 0xC004C919. Therefore, a certain stevt_ioctl driver is responsible for generating the UID. To check this, I quickly sketched this code:
Running it on the console, I saw a familiar UID.stevt_ioctl
The next step is to disassemble the stapi_ioctl_stripped.ko driver, which is located in / root / modules. We load the driver into the IDA and find the handler 0xC004C919 ioctl (I called this function calcHash).
There are three interesting points. First, 0x41 bytes of memory are copied from user space to kernel space (this is exactly what is transmitted by the user and in our case consists of zeros), the get_mem_type function is called(along the way in the kernel itself) and the result (again 0x41 bytes) is then copied to the user's address area. To find the address of the get_mem_type function, I saw two possibilities: just look at the / proc / kallsysms file, hoping that access was not restricted, well, or, otherwise, write an assembly in assembler for the driver itself that will return the value of register r0 in the right place. Having looked in / proc / kallsysms, I was pleasantly surprised and found the address of the get_mem_type 0x8080E380 function .Core
For further analysis, you will need to analyze the kernel. The kernel itself can be found in the manufacturer’s firmware, or you can remove the dump using U-Boot
or mount the desired partition.Based on the U-Boot information, the kernel is loaded at 0x80800000, and the entry point is at 0x80801000. We load the kernel in the IDA and find the get_mem_type function .After analyzing the code, I discovered this section, which supposedly returned the UID.
So the UID is stored at 0x80D635EC. Next, we are looking for in the IDA, where this value is formed. This was in the init_board_extra function (I won’t translate the full listing)
So this is the same unknown value at the address of the r4 register from which the hash of interest is calculated (fill_hash by the way was resolved by SHA256). I really was eager to find out what it was and I quickly wrote an insert in assembler, which, through the printk function, returned the contents of memory at the address of register r2. Having modified the kernel in this way, I made a new uImage and uploaded it to a USB drive. And in the terminal U-Boot set:usb start
fatload usb 0:1 80000000 uImage
bootm
But after the last team, such a sadness was waiting for me.
U-Boot politely refused to ship my new kernel.Editing U-Boot
To convince U-Boot to boot my kernel, I decided to patch it in memory with the mw command itself . To start, I made a full dump of NOR flash, which is located at 0xA0000000. Having driven the dump into the IDA, I discovered the memory address where the U-Boot copied itself. It was 0x8FD00000. Again, dumping this memory area and starting the IDA, I easily found a function that checked the signature. If everything was correct, she returned 0. Moreover, she was called in two different places.
What exactly did this function do was not interesting to me. She just needed to return 0 like this:mov #0x0, r0
rts
nop
The corresponding code for U-Boot was now like this:usb start
mw.l 8fd0ec08 000b200a;
mw.l 8fd0ec0c 00900009
fatload usb 0:1 80000000 uImage
bootm
Then U-Boot happily loaded my kernel, which issuedEF0F3A38FF7FD567012016J04501200:1a:79:23:7e:2MAG250pq8UK0DAOQD1JzpmBx1Vwdb58f9jP7SN
Full analysis
So, what did the UID consist of? It was some unknown number of 8 bytes, the serial number of the console, the MAC address, the type of console and a piece of garbage. It remains to find out what kind of unknown number it was and where the garbage came from. I returned to the init_board_extra function again .An unknown number was taken from this code section:
Here, using the __ioremap function, the kernel accessed physical memory at 0x00000000 (which was the NOR address of the flash), wrote 0x0F to 0x00000000, then 0x98 to 0x000000AA and read 8 bytes starting from 0x000000C2. And what is it? These are the CFI protocol commands with which the kernel communicated with NOR. 0x0F brought the NOR to its original state, and with the 0x98 switch command mods CFI. In this module, at the address 0x000000C2 is the Security Code Area or 64-bit unique device number. Those. unknown number is a unique NOR flash number. The following is a dump of CFI identification.
You can make your dump directly in U-Boot by settingmw.w a0000000 f0
mw.w a00000aa 98
md.b a1000000 100
A piece of garbage was just an ordinary 32-byte character set that was sewn into the kernel itself.
And this garbage was processed before using the encryption function swap_pairs , which simply changed the position of the bytes[0x00000003]<->[0x0000000F]
[0x00000005]<->[0x0000001F]
[0x00000009]<->[0x00000002]
[0x0000000A]<->[0x0000001D]
[0x00000010]<->[0x00000015]
[0x00000004]<->[0x00000013]
[0x0000000D]<->[0x00000018]
Based on the information received, I dare to assume that the manufacturer’s database contains information on each ID NOR flash and the corresponding serial number and MAC address.Of course, it's impossible to select all this, but you can write your own software, which will fully emulate the console.