Page 1 of 26 12311 ... LastLast
Results 1 to 15 of 379

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

  1. #1
    Join Date
    Jun 2001
    Posts
    3,108

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

    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
    Last edited by rc3105; 08-22-2004 at 07:47 PM.

  2. #2
    orangejaylove Guest
    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

  3. #3
    Join Date
    Jun 2001
    Posts
    3,108
    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.

  4. #4
    orangejaylove Guest
    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...

  5. #5
    orangejaylove Guest
    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

  6. #6
    Join Date
    Jun 2001
    Posts
    3,108
    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.

  7. #7
    orangejaylove Guest
    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

  8. #8
    Join Date
    Nov 2001
    Posts
    120
    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

  9. #9
    Join Date
    Jan 2002
    Posts
    8

    hardware 2-card monte

    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.

  10. #10
    Join Date
    Jun 2001
    Posts
    3,108

    Re: hardware 2-card monte

    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

  11. #11
    Join Date
    Apr 2003
    Posts
    8
    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!

  12. #12
    Join Date
    Jan 2002
    Posts
    1,778
    *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.
    Last edited by alldeadhomiez; 06-01-2003 at 03:08 PM.

  13. #13
    Join Date
    Jan 2002
    Posts
    1,778

    monte tarball

    remove the .bmp
    Attached Images Attached Images
    Last edited by alldeadhomiez; 06-01-2003 at 03:33 PM.

  14. #14
    Join Date
    May 2002
    Posts
    314
    Thanks....

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

  15. #15
    Join Date
    Jun 2001
    Posts
    3,108
    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
    Step one: search button!
    Silly Wabbit, guides are for kids

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •