Our multi threaded ryzen processor its just too fast and causes these issues when doing threaded operations that just do not happen on a super slow single core design cpu that the TV uses from my theory. And it would line up with the inconsistencies that we see.
Guess who just got confirmation that I was semi right that it was about timing.
and now its time to see if it worked
No old me from a few days ago your attempts did not work. But they did not go in vain thanks to the help of others.
Yeah the reason why the ioctl calls were not in order was because of timing.
If you recall previously while compiling GCC I finally went back after a short break. I want to thank
@analrapist for helping me out as he scoured the entire internet and managed to compile working binarys of gcc and binutils that had everything I needed. It was not as easy as simply compiling he had to scour and do alot of stuff because they were using custom patches to enable Libc. Show this guy some love seriously hes amazing and I wish I was half as useful as him.
Anyways what was I saying oh right.
We remember how everytime I ran the program the ioctl calls that would be ran would be inconsistent and would execute out of order/randomly.
Two different times running the binary. 2 Different execution results. Wow that sounded poetic
Well we got confirmation that this is not how its suppose to be ran(duh). If you recall I did find a old monta vista image that while a few years eariler than this version of Monta Vista still had alot of stuff that was relevant. Check the documentation. There appears to be stuff that I don't even think the MODERN linux kernel has but also confirmation that im heading in the right direction
"CONFIGURING LATENCY TRACING Note: At least one latency timing options must be selected before it is possible to configure latency tracing. To enable latency tracing, use DevRocket or run make menuconfig or make xconfig to complete the following procedure: 1 Open the Kernel Hacking menu. 2 Select the Latency Tracing option. 3 Save your project. If you have enabled Project > Build Automatically, when you save your project, DevRocket automatically generates a new kernel. RUNTIME CONTROL OF LATENCY TIMING AND LATENCY TRACING Runtime control of the three available types of latency tracing is performed via a common set of control functions. RUNTIME DISABLE LATENCY TRACING Latency tracing can disabled by issuing the following command: echo '-1' > /proc/sys/kernel/trace_enabled RUNTIME ENABLE LATENCY TRACING Latency tracing is enabled during kernel boot, by default. The status of latency tracing is reported using: cat /proc/sys/kernel/trace_enabled 1 The system returns a non-zero value, if latency tracing is enabled. The following command is used to re-enable latency tracing: echo ‘X’ > /proc/sys/kernel/trace_enabled The value of X depends on the tracing mode, as discussed in the following sections. RUNTIME CLEARING OF LATENCY TRACE BUFFER Before running a test using latency tracing, it is necessary to clear the latency trace buffer with the following command: echo ‘0’ > /proc/sys/kernel/preempt_max_latency"
This means that the Monta Vista kernel that the TV uses most likely has latency options that prevent it from running these threaded ioctl operations out of order which is what is causing it to crash(may be something else but it wont hurt to fix regardless)
Sometimes its not just about knowledge but about strategy. Having a plan, you knock out one could be problem or future to be problem and you now can say "We know thats not the problem scratch one" or say "Well we now have made it even more accurate". Its not like fixing a issue with something will make your project even more unfinished if its done well.
Anyways lets discuss something else to, yeah my friend got a update file for the TV. Not analrapist but he managed to dissect SOME of it and found what appears to be the VMLINUX. Now for reference the firmware image I have is not a update image but rather a dump of the little epprom on a already installed TV. Weird that binwalk did not find the vmlinux on THAT one. But oh well. He told me that its in a file called AppKernel.TDF and this is where things get weird. .TDF appears to be a proprietary format to store files that
Does not compress any data? Despite being the only reason why someone would a company would want to make there own file format for a vmlinux besides .ELF
Encrypts or obsfucates nothing.
Litterally just stores the raw VMLINUX image with no edits or cuts
Why would you take a Linux kernel, a system that can compile for .ELF already with no problem(vmlinux) and then instead of doing that you make it store vmlinux in your own file format that does not even reduce the filesize nor encrypts or does anything basically creating the exact same thing as a .ELF without using a .ELF is beyond me. But lets inspect this shall we
This is LITTERALLY just a VMLINUX image with some modules. Again there is NO point in using this format when you could have just built for .ELF which does the EXACT same thing. Its not like this obfuscates it either.
At the end of the file are a bunch of zeros
Nothing intresting there but now lets look at the very end of the file
If you don't know those first few bytes and arguments is a GZIP magic number(1F 8B 08 ). Yes that's a GZIP file it seems but its storing nothing? Its at the very end where no file could be stored. if we were to try and extract this it would show NO files in it.
Why the FUCK is there a empty gzip with NOTHING in it at the end.
Well wait a minute.
Lets look at some of the obvious strings and values in here that are not just raw binary
"3070704" Definitly means something, same with 0mb and 91F. My guess is that this is NOT a gzip archive. it would make no since to have a gzip archive with NO files at the very end of the file. But the 1F 8B 08 magic number is WAY to spefic and the fact its at the end of the file does not mean its just some compiled code. It could be reusing some gzip stuff. My guess is that its header information for this .TDF filetype.. maybe they just reused code from gzip and its stored at the start and end of the files??? I mean its obvious that the 1F 8B 08 were intentional to be a gzip magic number(or maybe there is a 1% not but it definitly ISN'T just some overlook here.)
https://files.catbox.moe/55zxkn.tdf
if you want this weird obscure .TDF shit that almost no one in the world has ever seen before here is the link.
Alright so you got all that with the end of the file and the Gzip header? Alright then now.
Now throw it out the window we don't need it.
The vmlinux is contained perfectly with no compression encryption obfuscation we literally just have to cut it.
We know where it ends. We just have to search for where another file header begins(In this case .ELF) and can assume that it ends there
Alright so 7F or the symbol behind the . In .ELF is the end of the Vmlinux(I also checked a valid Vmlinux image for mipsel that despite for debain also ends similarly)
Now we need to find the Start and then just DD it.
Alright... Defusing the bomb and deciding "Which one is the starting byte of the Vmlinux"
It could be 01 here... BUT look next to it and then next to the 44 F1 26... a bunch of zeros afterwards instead of bunch of instructions... I don't think that would make since for the beginning of a kernel... It could be the thing that tells the .TDF file "This is where the File starts". If that is true this is one of the most fucking weird file formats of all time.
It starts with a magic number and then meta data and then padding which is normal, But then has on the line above it a thing saying "This is where the thing starts" and then at the end of the file a .GZIP magic number that is not acutally a gzip but further metadata that is stored at the very bottom instead of at the top?" But fuck it, it makes more sense than the first few instructions of a kernel image having 00s as padding.
So where could it start then? Well Its most likely here
K so we have a start and a end. Thats good. When I get back on my main computer ill DD it and see if we can run it in QEMU. That way we can have a kernel image with ALL the right config options and timing support.
Anyways I know I said I was going to do that GPIO stuff to the TV but amazon delivery dates a bitch. So I cant get the usb to UART adapter stuff RIGHT now.
Anyways right now im trying to use IDA instead of ghirda to see if it produces a better output.. Dont know why just have nothing to lose.
