killhdinitrd 0.9.x Support Thread

[darylhuff]

Why don't you just killhdinitrd a 3.1.1c kernel as stated in the post above and try it with no monte and see if it works.

Where would I get one of those? As I stated in my original post I took the advice found a number of times elsewhere in this forum and waited until after the dtivo had called in successfully before starting my enhancements. It was on that call that the software upgraded from "c" to "d".

If not you can always monte from 3.1.1c into 3.1.1d.
NutKase

Same problem.

[darylhuff]

If you used killhdinitrd before on your 3.1.1c than it is probably still sitting in /dev/hda6. Try :

dd if=/dev/hda6 of=/dev/hda3

This assumes that you had a 3.1.1c killhdinitrd'd kernel on hda6 and your new kernel in hda3.

Which I didn't. As stated in the original post, I waited until the dtivo had called in once before I started the proceedure. It was on this call that the unit went from 3.1.1c to 3.1.1d. Also, if you look at the partition table in my original post you'll see that the /dev/hda6 parition is 4096 while the /dev/hda3 partition is 8192 so doing the above would probably not be the best of ideas.

I searched through the forum and didn't find any other references to 3.1.1d. Is this something they just released and I'm the first to hit this kernel? I'm hoping that the killhdinitrd utility will get upgraded. That, or there is going to be a good black market for 3.1.1c kernel images.

[NutKase]

Where would I get one of those?

<SNIP>

Same problem.

Search. I did.

Here's a link because we have snow ... and I feel skiing and Christmas in the air... yeah my christmas spirit jumps Halloween ... Ho-Ho-Ho!


I've confirmed that it's still good... 9/29/04 0432,ZULU, UTC, GMT, or whatever you call it...

Woohoo! Five minute turn-around isn't bad .


Some newer Kernel Files.

Includes:

3.1.1c
3.1.5
4.0.1a

ANY kernel a killhdinitrd hacker needs , thanks Fletch319.


NutKase

[NutKase]

I searched through the forum and didn't find any other references to 3.1.1d.

There are at least 3 threads on 3.1.1d...

I'm not sure why you didn't find them.

Did you click on the S2 Support forum topic?

http://www.dealdatabase.com/forum/sh...ad.php?t=37872

http://www.dealdatabase.com/forum/sh...ad.php?t=37918

http://www.dealdatabase.com/forum/sh...ad.php?t=38079

The best 'searching' advice I can give you is 'read' what pops up...

Also, select 'Search Entire Posts' as the default under 'Keywords' for your search page.


NutKase

[pbolya]

Which I didn't. As stated in the original post, I waited until the dtivo had called in once before I started the proceedure. It was on this call that the unit went from 3.1.1c to 3.1.1d. Also, if you look at the partition table in my original post you'll see that the /dev/hda6 parition is 4096 while the /dev/hda3 partition is 8192 so doing the above would probably not be the best of ideas.

First of all the size of the partition do not matter. The actual data in there is less then 2mb (1.7MB for 3.1.1c to be exact). So regardless of which way you are going even copying 3 to 6 would work (just ignor error message).

Second the block size is 512 bytes so hda6 is 2M and hda3 is 4M

What I surgest is to run killhdinitr on /dev/hda6 if it works that means that you have a completely good 3.1.1c kernel in you inactive kernel partition (now hacked). Than just DD it over.

I was in the same boat. I had 3.1.5 HD TiVo and it upgraded to 3.1.5d. After checking in this thread and confirmed that there is no fix for that kernel in the near future and the previous kernel works just fine I backed up both kernels with a dd command to a fat32 disk (hda6 was 3.1.5 - killhdinitrd'd, hda3 was 3.1.5d - original) and copied 6 over to 3. Took less than a minute (backup including) and worked like a charm.

As far as the 3.1.1d concerns I have not yet received that update (scheduled to connect on Saturday). You are probably within the first batch of people.

[darylhuff]

What I surgest is to run killhdinitr on /dev/hda6 if it works that means that you have a completely good 3.1.1c kernel in you inactive kernel partition (now hacked). Than just DD it over.

Already tried that.

Let this be a lesson to any other new person that stumbles across this thread. *DO NOT FOLLOW THE ADVICE OF OTHERS AND WAIT FOR THE FIRST CONNECTION TO TIVO. BACK UP THE DRIVE IN IT'S ORIGINAL STATE BEFORE ALLOWING A CONNECTION TO TIVO*

[NutKase]

Already tried that.

Let this be a lesson to any other new person that stumbles across this thread. *DO NOT FOLLOW THE ADVICE OF OTHERS AND WAIT FOR THE FIRST CONNECTION TO TIVO. BACK UP THE DRIVE IN IT'S ORIGINAL STATE BEFORE ALLOWING A CONNECTION TO TIVO*

Well, you should try it again. Have you read the last few posts?

Maybe you should post your steps because you're missing a command or some syntax.

Tell me what I'm missing. You seem to be getting frustrated and it's just because things are new to you. Most people aren't having these problems.

Here's what I think I read of your situation. Correct me if I'm wrong.

You had a HDTivo with 3.1.1c in /dev/hdx6 (you just didn't know it)

You waited on the advice of others until you called up tivo
-- I think in your case this was good advice because if you'd hacked it first you would probably be confused even more trying to manually switch partition pairs.

You got an update to 3.1.1d and started trying to hack your tivo with killhdinitrd. Your new kernel, which you found to be in /dev/hdx3 is not supported by killhdinitrd.

The solution is to run killhdinitrd on /dev/hdx6 as was stated

Then dd your new 3.1.1d kernel out to a file for backup reasons.

Then dd /dev/hdx6 over /dev/hdx3

Add your hacks and you're done.

The linked thread that you said you read says the same thing. If you still can't get it post more information, commands etc. it could be a simple mistake.


NutKase

[darylhuff]

Well, you should try it again. Have you read the last few posts?

Yes.

Maybe you should post your steps because you're missing a command or some syntax.

1. dtivo drive attached to /dev/hda
2. booted using MFStools 2.0 cd
3. mounted usb drive where I have all the utilities
4. run "<path to killhdinitrd on usb drive>/killhdinitrd /dev/hda6 which fails to find a kernel
5. run "<path to killhdinitrd on usb drive>/killhdinitrd /dev/hda3 which find a kernel but reports "no exploit found for this kernel"

Tell me what I'm missing. You seem to be getting frustrated and it's just because things are new to you.

No, the source of my frustration is that I believe in the power of open source software.

Most people aren't having these problems.

...yet. 3.1.1d is apparently just getting released. Folks that have had their tivo's for a while and have a backup of 3.1.1c (or other), will be able to back out the change. It is only folks that just got started and don't back up their systems before letting it call tivo that will have the problem.

Here's what I think I read of your situation. Correct me if I'm wrong.

You had a HDTivo with 3.1.1 in /dev/hdx6 (you just didn't know it)

You waited on the advice of others until you called up tivo
-- I think in your case this was good advice because if you'd hacked it first you would probably be confused even more trying to manually switch partition pairs.

You got an update to 3.1.1d and started trying to hack your tivo with killhdinitrd. Your new kernel, which you found to be in /dev/hdx3 is not supported by killhdinitrd.

Close, I just don't agree on when a system should be backed up. In hind sight, a more reasonable sequence would be to:

1. back up your drive before it calls tivo (don't hack it yet).
2. let the system call tivo and do whatever.
3. start hacking.

Step 1. won't change anything on the drive, but will make a backup of the original system in case 2. makes the system unhackable.

It is entirely possible (probable?) that tivo and/or directv engineers study this forum and work on defeating the hacks with each release of the software. If I worked at tivo, I know that is what I'd do. They may not be able to stop the folks that have already hacked, but they can stop new customers from hacking. It's called "hacking" for a reason.

The solution is to run killhdinitrd on /dev/hdx6 as was stated above (you don't even have to pull the drive.)

See above on the killhdinitrd on /dev/hda6.

I am curious how I could attempt this without pulling the drive. The whole reason I'm trying to hack the system is so that I can get networking and USB enabled on my dtivo. Without which I can't get software to the system nor can I even log onto the system. Am I missing something?

Then dd your new 3.1.1d kernel out to a file for backup reasons.

Then dd /dev/hdx6 over /dev/hdx3

Add your hacks and you're done.

The linked thread that you said you read says the same thing. If you still can't get it post more information, commands etc. it could be a simple mistake.
NutKase

Perhaps it is a simple mistake, do you see anything wrong with the sequence in my message above?

[NutKase]

I am curious how I could attempt this without pulling the drive. The whole reason I'm trying to hack the system is so that I can get networking and USB enabled on my dtivo.

You still didn't type the exact commands you used so I have no idea.

I forgot we weren't starting with a hacked 3.1.1c tivo.

Not sure what's going on... your old kenel should be sitting all virginal and happy in /dev/hdx6.

You can get another stock 3.1.1c kernel and put it on /dev/hdx6, killhdinitrd it then dd it over the /dev/hdx3 one as suggested above.


NutKase

[pbolya]

Not sure what's going on... you old kenel should be sitting all virginal and happy in /dev/hdx6.

You can get another stock 3.1.1c kernel and put it on /dev/hdx6, killhdinitrd it then dd it over the /dev/hdx3 one as suggested above.

NutKase

darylhuff,
did you by any chance backed up your 3.1.1d and restored it from that backup ? MFS Backup only backs up the active partitions and the restore wipes out the inactive ones. That would explain why you do not have a valid kernel in hda6.

If that is not the case than maybe you have trouble mounting hda6. What is the exact text from killhdinitrd ? You can try backing up hda3 (or full backup with mfsbackup) than dd hda6 to hda3 and than killhdinitrd from there.

However the easiest solution would be at this point if you use FTP to get a virgin backup of a 3.1.1c kernel from the post referenced several times in the last few posts and dd that to hda3 and killhdinitrd away.

Regards,
Peter

[darylhuff]

darylhuff,
did you by any chance backed up your 3.1.1d and restored it from that backup ? MFS Backup only backs up the active partitions and the restore wipes out the inactive ones. That would explain why you do not have a valid kernel in hda6.

If that is not the case than maybe you have trouble mounting hda6. What is the exact text from killhdinitrd ? You can try backing up hda3 (or full backup with mfsbackup) than dd hda6 to hda3 and than killhdinitrd from there.

However the easiest solution would be at this point if you use FTP to get a virgin backup of a 3.1.1c kernel from the post referenced several times in the last few posts and dd that to hda3 and killhdinitrd away.

Regards,
Peter

Thanks to both Peter and NutKase! Yes, the disk I'm working on was backed up and restored using the MFS tools so the above explains why killhdinitrd won't work on the /dev/hda6 on my new disk. Tonight I'll put my original tivo disk (sealed and put away in the closet) back in my computer and dd out the /dev/hdx6 and dd it back into the /dev/hdx3 of my new disk and see if that allows me to run killhdinitrd and proceed with the hack.

I also pulled the stock 3.1.1c kernel from the referenced ftp site and will try that if I can't get the above to work.

[pbolya]

3.1.1d is apparently just getting released. Folks that have had their tivo's for a while and have a backup of 3.1.1c (or other), will be able to back out the change. It is only folks that just got started and don't back up their systems before letting it call tivo that will have the problem...

...I just don't agree on when a system should be backed up. In hind sight, a more reasonable sequence would be to:

1. back up your drive before it calls tivo (don't hack it yet).
2. let the system call tivo and do whatever.
3. start hacking.

Step 1. won't change anything on the drive, but will make a backup of the original system in case 2. makes the system unhackable.

Well we do not know what happened with your kernel yet but you can just as easily buy a TiVo 6 month from now with 3.1.1d on it and you could back it up all day still wouldn't work (assuming that killhdinitrd is not updated by than). That is why we have this forum. Just because it did not work out for you it does not mean that others will have the same problem.

I went through the same thing with upgrading from 3.1.5 to 3.1.5d a week ago and even though I had a hacked 3.1.5 it is the same princable (I just did not have to run killhdinitrd). When TiVo upgrades to a new release it leaves the old kernel and root in the inactive partition. There is no reason to change that in the future since it is important to have it there so it can revert back to the old release if something goes wrong.

I bought 5 different TiVo's at 5 different times over the last 4 years (HD Tivo, S2 DirecTiVo, S1 DirecTiVo, S2 SA and S1 SA - which is the only one I already sold). I never backed up any of them out of the box. Why ? because I wanted to see if it works first before I open it up and lose my warranty. Also I like to have a backup which contains all of my config/season passes etc.

It is entirely possible (probable?) that tivo and/or directv engineers study this forum and work on defeating the hacks with each release of the software. If I worked at tivo, I know that is what I'd do. They may not be able to stop the folks that have already hacked, but they can stop new customers from hacking. It's called "hacking" for a reason.

I have thought about that but I do not think that will happen. The reason is that I do not think generally TiVo cares about pepole hacking the TiVo's unless they get pressured by others to do so (e.g. DirecTV). They will do enough to please them but they concerned more about making there own software better - to bad D* is for some reason (mainly security I guess) refuses to give us the new software TiVo already developed and implemented 2 years ago.

Any way if they where to release new versions that raises the security like for instance signing the entire kernel, making new releases not work with previous kernels, they would just make more and more people using an outdated software causing more and more issues. The only way to stop it is to get an airtight software/kernel combo and a new hardware which will only run on that kernel and nothing else. Than either add some software improvements that already capable doing most of the stuff we are doing with hacking out of the box (not likely as we still not have even something as simple as folders) or replace every box and stop the feeds to the old boxes (cost too much to be worthwile). In either case no matter what they do they can limit the number of people hacking but they can never eliminate it. Even Microsoft can not stop people hacking there software. They could eliminate at least half of the hacked D* machines by just releasing 4.0 with free HMO.

[Vegas]

My S2 Dtivo (hdvr2) upgraded to 3.1.1d lastnight.
Figured I would have to use monte to re-hack it because it has been
reported that killhdinitrd will not work on the 3.1.1d kernal.

I ran killinitrd on the 3.1.1d kernal and got this error:
0x00002e68: Expected 0x1040004a but instead got 0x00000000!

So it looks like 3.1.1d is not hackable with the currant tools.

Good news is:
I copied the 3.1.1c kernal that I had run killhdinitrd on, over the 3.1.1d kernal,
restored all my hacks and booted it up.

It's running fine right now with the 3.1.1c kernal

Vegas

[alldeadhomiez]

It is entirely possible (probable?) that tivo and/or directv engineers study this forum and work on defeating the hacks with each release of the software. If I worked at tivo, I know that is what I'd do. They may not be able to stop the folks that have already hacked, but they can stop new customers from hacking. It's called "hacking" for a reason.

FWIW, the 3.1.1d and 3.1.5d kernels both have the new "TCD1" header. Obviously this header is useless without new code in the PROM to check it, and as we know the PROM on current units is not in-circuit flashable. Therefore this header does not affect any Series2.0 units yet.

Maybe the release of killhdinitrd has encouraged TiVo/DTV to roll out new machines with an updated PROM version. Maybe not. On the plus side, the visibility and the perceived ease of hacking has declined a bit in recent months, so hopefully thwarting our changes will become a lower priority in their view.

[darylhuff]

Here's an update on the situation with my system. I was able to pull out the 3.1.1c kernel from /dev/hdx6 of my original dtivo disk then dd it back to /dev/hdx3 of my new, expanded drive. This allowed me to run killhdinitrd and I was able to boot the system. One step down.

I then tried to enable a USB network adaptor (Linksys USB100TX) so I copied over the modules to /var/hack/lib and tried the following rc.sysinit.author:

#/bin/bash

export PATH=$PATH:/var/hack/bin

insmod /var/hack/lib/usbcore.o
insmod /var/hack/lib/usb-ohci.o
insmod /var/hack/lib/pegasus.o

sleep 10

ifconfig eth0 192.168.1.20 broadcast 192.168.1.255 netmask 255.255.255.0
route add default gw 192.168.1.1 netmask 0.0.0.0 metric 1

/sbin/tnlited 23 /bin/bash -login &

I connected the USB adaptor to my network and started the system. It came up fine, but wouldn't respond to a telnet client.

I'll move further discussion about USB support to the appropriate thread, but I wanted to know how folks configure the Windows Hyperterminal to talk to the box. I have my serial<->RCA cable built, but I can't get the system messages to come out to the hyperterminal. I did add the following line to my rc.sysinit.author file:

/bin/bash</dev/ttys2&>/dev/ttys2&

But, nothing came out after I connected (hit return in the window). I know it is supposed to be set to 9600 baud, 8-n-1, and no HW control. Do you leave the "Emulation:" setting as "Auto detect"?