Right so I told you guys about the byte trick but basically when extracted most tv systems acutally have duplicate filesystems.(there is acutally another squash filesystem with a backup for UPDATING the tv, which is a ENTIRELY different rootfs for some reason. So really there are 4 filesystems, but I only showed 2 because it was easier to explain)
These duplicate filesystems contain a basic RootFS. Its interesting because embedded systems have such a EXTREMELY stripped down version of linux with NOTHING In the bin folder so you can not even do something as simple as ls or cd.
Now for this well lets just say agressive check to make sure that no file gets corrupted it got me wondering "Why would they put SO much effort into making sure things don't get corrupted" I mean to THIS much of a extreme is kinda insane, But I do have a theory.
Do you remember the Nintendo wii? Stay with me here ok. on the Nintendo WIi if you ever modded the console you have likely seen this screen before when making a nand backup of your console(STAY WITH ME I PROMISE THIS IS RELEVANT)
Now normally this would cause you to panic however if you check online youll see that this is perfectly normal.
"BootMii will begin backing up your NAND to the SD card, showing the progress on the screen. If your see any "bad blocks", don't worry; they're to be expected in the type of NAND chips used by the Wii."
On your X86 computer when you see a SINGLE bad block on your hard disk that typically means you should backup everything and replace it as soon as possiable. In embedded systems and similar that is not the case
Its normal for blocks to be bad when they come out of the factory, Infact most chip makers say THEMSELVES that 6-12 blocks will likely be bad
The reason why there are SO many data failsafes to the point of having 4 DIFFERENT filesystems, 2 for the main Tv system and 2 for the main updater. And those backup bytes I mentioned before is because the chips that come out of the factory on the TV likely have a few bad blocks and since you can't predict which ones are bad you have to do the next best thing and failsafe it. But that is just a theory. But im pretty damn sure that is the reason why.
Anyways back to /bin/ being empty on all 4 filesystems. You actually do not need the bin folder to run the linux kernel. There can be NO programs in there and it will still work. This TV does not have any programs in /bin/ and its likely normal although I have never really done firmware extracting like this before or well at all.
As for the actual TV part, it first loads a script called startup that mounts some JFFS2 Partitions and then starts the MAIN tv operating system which is actually just a linux binary/application.
Here is something weird. On this TV there is only ONE usb port, no ethernet or even way to connect to the internet, Only ONE usb port is on there besides HDMI and composite and that USB is meant for service and cant do anything from what im aware, However there appears to be USB drivers and also usb ETHERNET ADAPTER DRIVERS??
And support for SSH, I don't think this was just leftover stuff. Considering that they were so conservative they literately deleted everything in /bin/
I tried some usb Ethernet adapters on the physical TV and my router refused to show any new devices connected so I don't think I can do anything sadly. But if there is some secert SSH that would be really cool.
Now lets talk about the JSSF2 parition that the thing tries to mount, I also learned how to extract that to.
The Jefferson Parition contains a BUNCH of config files and nothing much else.
Weirdly enough almost ALL of these are copies,
aqsettings0, aqsettings3, aqsettings4, aqsettings 13, aqsettings 12 etc are all copies.
But some are NOT copies. SO its weird. Like almost every file is a copy of another file in here, and thats the whole folder is just these config files.
K so now we have all the context needed lets go how I was able to get this environment set up.
We know its mipsel which is a 32 bit MIPS architecture with little Edian. I tried to compile a old version of linux to work with QEMU for this but it failed, But I was able to find a VMLINUX that supported this architecture online.
Now its time to build a ROOTFS, Which is just the filesystem, You can mix and match shit when it comes to this.
I took the squash folder with the phillips folder and everything in there and made a new one pasting it in there. Then Id run a command to convert that folder into a disk we can use(MAKE SURE IT DOES NOT HAVE A 64 BIT FEATURESET)
Now because the bin folder is empty I just used busybox compiled for mipsel that I got online and just put that in the bin folder so I can that as a shell.
This is my linux command arcs
"../qemu-4.2.0/mipsel-softmmu/qemu-system-mipsel -M malta -kernel vmlinux.mipsel -hda philips_rootfs32.img -hdb mtdblock6_ext2.img -hdc mtdblock7_ext2.img -append "root=/dev/sda rw console=ttyS0 init=/bin/busybox-mipsel sh" -nographic -vnc :0"
**Note the MTD blocks are the jefferson files that I converted, not sure if I would need them but its important to have.
Once were in we have to do a few things,
Reverse Engineering the program which I learned how to do it seems that it access a /proc/ folder for a device that we do not have during the startup check AND worst of all it will error if it fails and terminate the program, Luckily ALL it does it check the mem size of that device. So we can fake it
I created a folder of the same name and just made a file named mem size and then just put a bunch of random numbers.
Problem solved right? Wrong.
As it turns out it uses those numbers in mem size to CHECK IN RAM and see if the value in ram that correlates with the mem-size address is not NOP or 00000000
so its just going to read that random number as a address, see that it does not belong to anything and error out.
However I have a ACE up my sleeve.
We can make a ram region or a MMIO in qemu and recompile it so that it will return something other than NOP whenever its called upon
THEN we can just point the mem size file to that address so that it ACUTALLY will return something that is NOT 0.
Ok so I have to say this is not in order, I did not figure this all out without even starting the virtual machine. All of this was discovered through trail and error in these past 2 weeks.
Lets now start QEMU(Im using a older version from 2019 because they got rid of system emulation for mipsel after that so I had to use a older version).
We first need to have everything in /dev/. If you do not know with the base linux kernel not everything is moved to dev automatically like you think. Base linux acutally DOES not do that. We need to use busybox here to setup /dev/ram/ and our jffs2 filesystems.(Which are ext2 but we can still mount it under jffs2 without changing the names of things in the startup script)
And with that were able to get past the "bootup process" of the thing and get pretty far before it crashes with a illegal instruction.
Ill try to go further but its insane I even got this far espically since I did not even know what a vmlinux was or how to reverse engineer anything 2 weeks ago. I fear that the illegal instruction is QEMU not supporting mipsel that well and I reached a hard limit, But I have a theory that the program is executing instructions located in the ram of the device that we faked with memsize and that mmio trick, in which case ill try making it return a Actual opcode(NOP) most likely and see if it will continue from there.
Hope this was a interesting read. Any questions or experiments you want me to do in QEMU or with the actual TV that I have let me know. Interestingly despite being a SONY tv the software is almost exclusively Phillips, I also know from the MOTD that its "MontaVista(R) Linux(R) Professional Edition 4.0 (0501140)."
