Digging into 500 .bin file

[GerryDazoo]

Any Linux experts out there that might want to take a look at this?
The file name s_uImage_mips_gz_378.bin smells awful like a Linux ramdisk/boot image. Would anybody like to unpack it and do a quick mount on the file to see what's there? You never know we might be able to add our own executables to the image.
I'd do it myself but I'm kinda busy.

-Gerry

[regmar505]

Where could we find s_uImage_mips_gz_378.bin and the SDK you talked about in "Digging into 500" ? Would it make sense to have them available here?

[GerryDazoo]

get it here
http://home.dazoo.net:64888/slinger/s_uImage_mips_gz_378.bin

[GerryDazoo]

Bueller? Bueller?

[DVoorhees1957]

Not sure it means anything, but the contents of the hwid.txt file are just the last 24 bytes of the squashfs-3-lzma.img file, so ignore it for the moment. The combined size of the other 2 files, vmlinuz (1048576 bytes) and squashfs-3-lzma.img (4412784 bytes), is equal to the size of the original s_uImage_mips_gz_378.bin file (5461360 bytes) - and the beginning of the vmlinuz file matches the beginning of the s_uImage_mips_gz_378.bin file. So it seems like the "extract" process simply picked a point to split the s_uImage_mips_gz_378.bin file into two parts, the 1st part becoming the vmlinuz file and the 2nd part becoming the squashfs-3-lzma.img file. What if the extraction process simply choose the wrong split point? That might explain why the unsquashfs process isn't working...

[GerryDazoo]

That makes sense.

[DVoorhees1957]

I've spent the better part of the day trying to understand the LZMA file structure and the uImage file structure... an LZMA file has a 13-byte header, the 1st byte of which is the Properties byte (which usually has the value 93 (x'5D'), the next 4 bytes are the Dictionary Size, and the last 8 bytes are the Uncompressed Size... still working on pinning down a specific format for a uImage file. I've seen uImage files with 64-byte headers, and some with 128-byte headers.

I've also been trying to use the Binwalk took, which is supposed to be able to "parse" most binary files, find interesting/common file signatures, etc... But for the life of me, I can't get Binwalk to find anything useful to report, either on the original BIN file or on the extracted squashfs IMG file. So I feel sorta like I've been spinning my wheels...

[GerryDazoo]

Standby, let me have a look through the packet capture of the firmware download. There may be some metadata in there that tells the existing firmware how to unpack the image.
Here's something.

{"payload":"{"config":{"updateVersion":"1.8.402","firmwareComponents":{"appfsMain":{"critical":false,"crc":123,"order":1,"reboot":false,"url":"www.abcdf.com","size":123,"version":"0.5.102"},"uImageMain":{"critical":false,"crc":516463924,"order":0,"reboot":false,"url":"http://cbfu-prod.slingbox.com/Intrepid/Intrepid_FW_1_8_392/s_uImage_mips_gz_378.bin\",\"size\":5461360,\"version\":\"1.8.378\"}},\"applications\":{\"sbCore\":{\"critical\":false,\"reboot\":true,\"url\":\"http://cbfu-prod.slingbox.com/Intrepid/Intrepid_FW_1_8_402v2/intrepid_sbcore_f_p_1_8_402v2.tar\",\"version\":\"1.8.402\",\"size\":64235520}}}}","header":{"signatureEncoding":"base64","msgType":"plain","signature":"MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAADGCAg8wggILAgEBMHkwdDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFDASBgNVBAoTC1NsaW5nIE1lZGlhMRMwEQYDVQQDEwpNRCBET1dOIENBMSUwIwYJKoZIhvcNAQkBFhZtZGFkbWluQHNsaW5nbWVkaWEuY29tAgEDMA0GCWCGSAFlAwQCAQUAoGkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQxMTIwMDgwOTQwWjAvBgkqhkiG9w0BCQQxIgQglWihrwzPfsDK5wDEMiMkMejkD4G9NXEPF0PCjcOcpd0wDQYJKoZIhvcNAQEBBQAEggEAYQuM+IVVcODQU976GWQ2dMjh3zeN9GY6m5iVtGqHlsucChTPsoVJ4LHVxAuZhYPhddL3LRXWtHXtm8lFDNRv7dh9ToK7Aw4SgboYDRYXC/hYwneGapllD5hxEbycamnLewmDp/hAa5dpAOjLJm4c7uqHAr6mitd052dVpOaArltrY0JJBwugZ5OFk7NbByh6DosqwtSdz7dLtT5IK/Kec8lRWnqdMPvWJiNImdekI/HIYCxZRjMfr5DWVsO7lZAcCUB8q0ADqwL34nYJsr/3IK/XLtenF01ASYCcwBL5pN8sRp8sZflLUBNjv8D3oYa5SPK2Q1O6Dr++lEIewZx/VgAAAAAAAA==","configEncoding":"none"}}

Holy smoke; I never noticed this before!
http://cbfu-prod.slingbox.com/Intrepid/Intrepid_FW_1_8_402v2/intrepid_sbcore_f_p_1_8_402v2.tar

[GerryDazoo]

Mode LastWriteTime Length Name

---

-a---- 8/19/2014 10:55 AM 452046 App-Mgr_0.0_all.ipk.smime
-a---- 8/19/2014 10:55 AM 7057710 kernel-modules_0.0_all.ipk.smime
-a---- 8/19/2014 10:55 AM 12729646 lib_0.0_all.ipk.smime
-a---- 8/19/2014 10:55 AM 146014 ME_0.0_all.ipk.smime
-a---- 8/19/2014 10:55 AM 59233 MTW-App_0.0_all.ipk.smime
-a---- 8/19/2014 10:55 AM 79734 mymediaservice_0.0_all.ipk.smime
-a---- 8/19/2014 10:55 AM 1140518 PS-App_0.0_all.ipk.smime
-a---- 8/19/2014 10:55 AM 28257 scripts_0.0_all.ipk.smime
-a---- 8/19/2014 10:55 AM 16405742 uiapp-common_0.0_all.ipk.smime
-a---- 8/19/2014 10:55 AM 17185451 uiapps_0.0_all.ipk.smime
-a---- 8/19/2014 10:55 AM 8933766 utils_0.0_all.ipk.smime

[DVoorhees1957]

@GerryDazoo is there anything more that's useful to do on this thread? My suspicion is that the intrepid_sbcore_f_p_1_8_402v2.tar file you discovered is the core Slingbox code, and that code in turn knows how to load and interpret the s_uImage_mips_gz_378.bin file.