two card monte with the kernel? A new possibility for hacking the HDVR2 w/o prom mods

[mrblack51]

I was looking around, trying to figure out some way to hack the hdvr2 w/o modifying the prom. I recalled something from the xbox-linux team's presentation for CCC, which was something close to "once you break the chain of trust, the box is forever compromised." I thought to myself: "self, if we can load one kernel via BASH_ENV, why can't we load a second kernel?"

I set that aside for a bit, but then descided to look around again, and ran across this link: http://www.scyld.com/products/beowul...are/monte.html

basically, we would boot into 3.1.U5, which would chain-load whatever version we wanted on the alternate partition set. im still working on it, but its definitely a start.


EDIT:

not to step on mrblack's toes, but things have changed so I've closed this thread & started a new one

two card monte with the kernel evolves in 2004

this thread is still an invaluable source of information for anyone wishing to learn, but should NOT be considered a howto

[orangejaylove]

ok remember im a green newb but would that mean you could have 3.1 load then "chain load" 2.5 or would the chipset differences and stuff negate that...

also you couldn't do this with 3.2 because of the signed stuff, all modifcations for file would be erased or something right...

just let me know if I'm anywhere near begining to understand this stuff

[mrblack51]

Originally posted by orangejaylove
ok remember im a green newb but would that mean you could have 3.1 load then "chain load" 2.5 or would the chipset differences and stuff negate that...

also you couldn't do this with 3.2 because of the signed stuff, all modifcations for file would be erased or something right...

just let me know if I'm anywhere near begining to understand this stuff

no compiled binaries from an s1 can be used on an s2, and since there is no 2.5 for the HDVR2, thats a big no.

as for loading 3.2...thats the whole point. we want to be able to chain load a newer version which prevents our known hack by using an older version which we can compromise (3.1.u5 and the BASH_ENV hack). if you are asking whether this chain loading could allow p3 cards to work, the answer is no.

[orangejaylove]

P3 cards who said anything about P3 cards

Ok so I thought that 3.2 was the version that nothing works on and the 3.1u5 was that hackable one...

if so please explain why you'd want to load 3.1 with all its hacks then have 3.1 chain load 3.2 and mess up all the hacks...

does doing this run the hacks before 3.2 checks for them or something

if thats true then yea that would be great load 3.1 run/start all your hacks then chain load 3.2 and get all your extra feature... what ever they are and no worries... sounds good

then again I've been known to be wrong...

[orangejaylove]

we want to be able to chain load a newer version which prevents our known hack by using an older version which we can compromise (3.1.u5 and the BASH_ENV hack).

ok I've read this three times

We want to be able to chain load a newer version which prevents our known hack-- why?

--by using an older version which we can compromise (3.1.u5 and the BASH_ENV hack). --wont that just shut down all the hacks...Why

[mrblack51]

we use a compromised version to break into a more secure version. this allows us to have the new features or bugfixes of a new version without leaving our bash hacks behind.

basically, its a method to get into versions higher than 3.1.u5 without flashing the prom. if you can't understand why thats good...well, i guess you should keep reading.

[orangejaylove]

so its like I said then you load a version get your hacks up in that then it loads the newer one and so on and so on... good deal if get it

[nitrous]

Great work MrBlack51!

Lateral thinking does it again.
But still, it is a bit of a stretch to see the full potential here.

If we use the bash compromise to chain load the updated OS, does that take the prom checks completely out of the picture? Each time the system is rebooted, hackinit reloads the bash stuff and anything else that would have been cleaned up by the prom checks that we put into the hackinit. BUT, once we chain into the other system, I assume that it is protected by virture of location from the prying eyes of the original, right?

Soooo, eventually, we can all expect to see the usual hacks in the rc.sysinit etc on the chained OS survive reboot without having to have them copied over from the primary boot OS (3.1.U5.), right? This limits the need to do too much in the hackinit beyond the bash and the noupdates parameter, right?

INteresting times MrB!
thanks again,
Nitrous

[burnt_soul]

I like the 2-card monte idea and it started me thinking: what if there were some sort of a hardware device that you could plug into the IDE cable which would intercept the first few IDE commands (reading the kernel to verify the signature) and instead return a "known good" quantity (i.e. the 3.1.U5 kernel image)? As soon as the first read was complete the device could revert to being a completely passive IDE passthrough.

This would be a great, non-intrusive "modchip" type solution - no soldering required. Just plug the device into the IDE cable.

The question is: does the kernel image get read once or twice? i.e. does the tivo:
a. load the kernel into memory, verify, then execute it from memory; or
b. verify the kernel on-disk, then load the kernel into memory for execution?

if it's (a) then this approach would not work.

[mrblack51]

Originally posted by burnt_soul
I like the 2-card monte idea and it started me thinking: what if there were some sort of a hardware device that you could plug into the IDE cable which would intercept the first few IDE commands (reading the kernel to verify the signature) and instead return a "known good" quantity (i.e. the 3.1.U5 kernel image)? As soon as the first read was complete the device could revert to being a completely passive IDE passthrough.

This would be a great, non-intrusive "modchip" type solution - no soldering required. Just plug the device into the IDE cable.

The question is: does the kernel image get read once or twice? i.e. does the tivo:
a. load the kernel into memory, verify, then execute it from memory; or
b. verify the kernel on-disk, then load the kernel into memory for execution?

if it's (a) then this approach would not work.

as far as i know, it loads, verifies, then executes

[TheHern]

Ok...got my cross compiler working, can build the kernel and any source. Ready to start the port of monte to MIPS.

I'm basing my initial implementation on MILO as far as moving the kernel into the correct place and beginning execution. I don't have my tivo available to me right now (wife is taping survivor), so I'm doing this blind as far as what the PROM does.

Does anyone have a disassembled PROM so I can compare that to MILO? I don't have a dissasembler for MIPS...so I'd hate to have to start down that path now.

Thanx!

[alldeadhomiez]

*bump*

VERY NICE work by MuscleNerd. I have tried this and it works as advertised.

posted elsewhere by MuscleNerd

Attached is a version of monte ported to the MIPS architecture. It comes in two parts: the module "kmonte.o" which should be inserted into the kernel using insmod. The user-level program called "monte" is then used to specify which "image.px" to load.

The "image.px" file is essentially a MIPS kernel and initrd combined into one image using TiVo's makeppceval script.

Note that monte completely bypasses TiVo's boot prom, so don't expect any signature checking of the image.px file. And if the initrd image within the image.px doesn't do any signature checking, well then there won't be any signature checking at all.

Don't forget to give monte the command line that the next kernel should use. Things like root=xx and console=2,1152000. Depending on what initrd you choose to package up, the command line will not be filtered for "approved" strings.

A number of people have been using this since February, so it shouldn't have too many kinks.

[alldeadhomiez]

remove the .bmp

[MuscleNerd]

Thanks....

The original download (and any future updates) are on alt.org

[mrblack51]

Originally posted by MuscleNerd
Thanks....

The original download (and any future updates) are on alt.org

Thanks for releasing this MuscleNerd. this is definitely a step forward in the s2 world.

just so you and everyone else knows, the original post about this linked to alt.org, but alldeadhomiez and I agreed that it might draw too many n00bs to alt.org, creating a bunch of extra work for the mods over there.

general FYI: alt.org is a serious dev site, not a how-to or whatnot site. as such, any general questions should be posted here rather than at alt.org, as per the rules of alt.org