NoScramble Kernel Hack for 3.1.1 ??

[samsks]

I have been using Ghost Coder's excellent NoScramble Kernel Hack with my version 3.1.0 series 1 Hughes DirecTivo:
dd if=/dev/hda3 of=/dev/hda3 bs=1 skip=468 seek=550524 count=2

Now that they are sending down the new TiVo version 3.1.1, I am wondering if any of the true gurus have been able to come up with a similar Kernel Hack that will work with the new version. I am assuming that when my TiVo gets the new version that Scrambling will turn back on, and I won't be able to watch any of my recorded programs?

Does anyone have any info on the best way to disable scrambling with the new TiVo version? I did do a search on NoScrable and Kernel Hack, but all available info so far seems to be for version 3.1.0 and earlier??

Thanks for any info!

[AlphaWolf]

I have not heard the first thing about a "3.1.1" software version. The patch offset is easy to find with all known kernel versions thus far...I don't anticipate any difficulty in finding it with any newer sw versions.

[gobsmack]

Samsk,

Alphawolf is the master of this stuff -- if they send down a new version, you have nothing to worry about.

Also, I *think* that credit for the hack you mention goes to AlphaWolf, but since he didn't complain, it likely matters little.

[samsks]

Thanks for pointing that out. The thread where I originally learned about the kernel hack mentioned Ghost Coder, so I just wanted to give credit. Stuff gets passed around so much that it is often difficult to give proper credit. My thanks go to Alphawolf and everyone on this forum. I can tell from the many searches that I have done that he helps a lot of folks here.

The kernel hack is great. I found it to be the easiest, especially since I did not have any existing scrambled recordings in my now playing that I was worried about being able to watch.

I was asking just because several threads over at tivocommunity.com have mentioned that they have received the new software version 3.1.1, and I suspect that the new version will cause the scrambling to turn back on.

No worries, everyone here has been very generous with their help. All the hacks have made my TiVo that much more fun.
--sam

[Zak0]

I unplugged the phone line from my Tivo until I hear how to patch the new version. No way I'm giving up my current setup even if it means wading through the nag screens every day.

-Zak

[AlphaWolf]

Ok I found on TCF that this is actualy 3.1.0b for S1 units, and it fixes the audio dropouts caused while using trickplay (thank god, I have been waiting forever for an upgrade that will fix that).

If anybody happens to be watching their logs, post the wget URLs for the slice files to this update if/when they get it. If you do this, I can force my tivo to upgrade and have a look at the kernel immediately.

[Juppers]

I have the 3.1.0b slices if you need them. Or I could just send you a kernel image. Just PM me for which you would like.

[AlphaWolf]

Ok after having a look at the 3.1.0b kernel, it seems the patch offset hasn't changed at all. Because of the way the upgrade works though, you are going to need to change the partition number to 6. Or, if you want a "one that fits any case":


dd if=/dev/hda`bootpage -b /dev/hda` of=/dev/hda`bootpage -b /dev/hda` bs=1 skip=468 seek=550524 count=2


I haven't verified this though, I'll need more time to do this (didn't expect anybody to have the slice files this quickly :P ) as I have a lot of homework to do before I can start hacking around. But, from what I can see thus far, theres no reason that it shouldn't work.

[Juppers]

I also have the 3.1.1b for the HDVR2s and such. Care to take a look at that too? :)

[AlphaWolf]

I haven't looked at the S2 kernels before, and from what I understand its a bit different...the ones who would know how to do that are alldeadhomiez, embeem, disconnect, ppchacker, or musclenerd.

[Zak0]

Okay, my phone line is still unplugged for fear of getting this update. It's great if the offset is the same, but what do I have to do in order to re-apply the patch once my system has been updated? Will I be able to just telnet in, execute the dd command, and reboot the DirecTivo or will it be more complicated than that? I'd really rather not have to take the drive out and do the dd from a PC but can if I must.

I'm currently running a DSR6000 with software 3.1.0. No Xtreme hacks - just TurboNet, TivoWeb, TyServer, and the dd-applied kernel patch for 3.1.0.

-Zak

[AlphaWolf]

Well, just so long as you know how to get bash working again, it should be as simple as executing the DD command I mentioned earlier. Be sure to back up your kernel first though.

[Zak0]

Okay, I know how to use dd to back up my kernel. But how do I get bash working again without removing the hard drive? If I won't be able to telnet in once the upgrade is done, I won't be able to edit the rc.sysinit. Right?

I guess I'll wait a bit longer for the upgrade to become a "sure thing" then plug my phone line in and force a daily call when I have the time to remove the drive, fix bash, and apply the noscramble patch.

If there's an easy way to just eliminate the daily call nag (other than fixsub), it might be easier for me to just do that - I don't need the update for anything (I don't have audio dropout issues).

-Zak

[alanjudy]

So I'm interested in the same thing Zak0 is interested in... How to deal with this upgrade without pulling the drive. I posted a couple of questions in this thread

http://www.dealdatabase.com/forum/showthread.php?s=&threadid=28447

I never got any answers.

Basically I have changed rc.sysinit so that the upgrade is downloaded, but the reboot needed for the final installation is not done.

1. Can I telnet into my tivo, mount the alternative partitions under a mount point and edit rc.sysinit on the alternate partition (adding in my telnet and $path changes) and then let the reboot happen?

or

2. Can I edit the MFS object STATE/SYSTEMSTATUS (or something close to that name) to change the version number that my DTivo reports. In this way my box could stay on 3.1.0 and but would report that it was upgraded to 3.1.0b.

=alanjudy

[AlphaWolf]

You can do things like this that don't require you to remove the hard disk, but I myself have never done them before...all I know is that its possible.

Everytime I upgrade, I pull the hdd out, set bash_env, and kill the initrd. From there I reconfigure everything from the ground up.

[swspjcd]

Has anyone gotten the "dd if=/dev/hda6 of=/dev/hda6 bs=1 skip=468 seek=550524 count=2" command to work? When I run it it says:
2+0 records in
2+0 records out
but if I do "dd if=dev/hda6 of=/var/hack/scramble.hack/kernel.bak"
and compare kernel.bak with the backup of my kernel, they are identical. In other words, even though it says it patched the 2 bytes, it doesn't seem to really be doing it.
Any ideas why?
John

[AlphaWolf]

You may be patching the wrong kernel image. Replace the partition number with `bootpage -b /dev/hda` (note, that is a " ` ", not a " ' " ) and try again.

[swspjcd]

I forgot to mention that I had already ran the "bootpage -b /dev/hda" command to find which partition to patch which is how I used /dev/hda6.
J.

[swspjcd]

I'm getting a little nervous that somewhere in the hundreds of times I've been trying to fix it, I ran the command twice and/or somehow screwed up the original backup of the kernel I had and now I don't have a clean untouched kernel to start from. At what offset does this patch and what 2 bytes? I thought it was FFF76 and the original bytes were "40 86" and they get changed to "48 00" but when I look at the bytes at offset FFF76 on both the backed up original kernel and the backed up hacked kernel, they both have "40 86" at offset FFF76 which I think shouldn't be.
Of course I've been staring at this thing for about 3 hours now and maybe I've just gone completely insane or something.
J.

[swspjcd]

Nevermind my previous posts. Somewhere along the line I got the names of the copies of the kernels, mixed up. I have no idea how I managed that but now have everything back up and working. I can record shows and then extract them as well as the plethora of shows that were already on there, can also be viewed. All is well again. Thanks for your help and patience.
John

[AlphaWolf]

I know this thread is old, but I want to add something for both my own (as well as others') future reference, and this is the best place to do so:

The DD command for undoing the scramble patch for 3.1.0b would be as follows:

dd if=/dev/hda`bootpage -b /dev/hda` of=/dev/hda`bootpage -b /dev/hda` bs=1 skip=10256 seek=550524 count=2