PDA

View Full Version : Reading/writing kernel memory



alldeadhomiez
01-18-2003, 02:58 PM
Attached please find a simple C proggie that will allow you to "peek or poke" 32-bit words in code or data memory in your running kernel image. Compiled for MIPS, source should work on any platform.

Usage:

./kmem 8013a6f8 <- reads "jiffies" from my kernel image

./kmem 800214a8 00000000 <- screws up the stack pointer in schedule() and probably crashes your box :)

Take a look through /proc/ksyms on your tivo to see what kinds of interesting functions and variables you can play with. Please exercise extreme caution, because messing things up in the kernel is likely to corrupt data or at least cause a panic.

Recall that the kernel source is free for all at:

http://www.tivo.com/linux/30/TiVo_3.0_linux_2.4.tar.gz

Edit 2004/11/13:

kmem is used with virtual memory addresses. Should you need to use physical addresses instead, try something like devmem2 (http://www.lart.tudelft.nl/lartware/port/devmem2.c).

alldeadhomiez
01-18-2003, 04:09 PM
Ok guys try this if you're bored:

./kmem 800b23b4

iff you get "800b23b4 = 8fa200f0" then try:

./kmem 800b23b4 00001021

Tried on 3.1 with a series2.

This *may* turn off video scrambling. When I did it, it invalidated everything the tivo had recorded, but new recordings were valid.

This should have the effect of changing line 1136 in drivers/ide/ide-disk.c from:

if (tagarray[TIVOTAGIO_SCRAMBLER].present) {

to

if (0) {

According to the checks contained in that function, we can no longer corrupt the scramble magic in tivoapp, because that will cause ide_dosectors() in the kernel to fail out with EINVAL.

AlphaWolf
01-18-2003, 10:42 PM
I don't know this for certain, but I am pretty sure that when streams are hashed (scrambled in laymans terms), the entire thing is hashed.

If you get a working binary of mfs_export, extract the first 128k of a tystream and post it here. Assuming its hashed along with the rest of the stream, it should be easy to tell whether or not the streams are in fact descrambled using this method. I don't have a D2 unit, so I can't do any testing.

mrblack51
01-19-2003, 12:54 AM
ok, i did the following, once from a clean booted recording, and once with a recording after the kmem patch:


mfs_export -c 131072 80793 FILENAME.ty


attached are the results below. mfs_stream and mfs_export seem to work fine from my testing with other files in the mfs (PNG files).

AlphaWolf
01-19-2003, 02:48 AM
alldeadhomiez: looks like you pulled it off! I took a look at the master chunk posted by mrblack51, it appears perfectly descrambled. The magic number is correct, all of the other info looks right too.

As expected, the scrambled one he posted doesn't even look nearly right, its all garble

Well done!

TheDoctor
01-19-2003, 02:51 AM
A comparision of the unscrambled.ty files looks VERY similay to an unscrambled ty stream header. The first 12 bytes are identicale to a file extracted from a 2.0 dtivo, and the rest of the structures appear to have the same layout. The scrambled version looks... well... scrambled....

Humm... It does not look like I am going to get much work done this morning.

TheDoctor
01-19-2003, 02:54 AM
O.k. A.W. so you beat me to it by 3 minutes...

AlphaWolf
01-19-2003, 02:56 AM
Just some more info to show you what im basing this off of.

Heres a hex dump of the first 32 bytes of the non hashed one:

F5467ABD <-- Magic number is correct
00000002
00020000
0006FA04
00000008
00000002
3B9ACA00
00000468

If you look at the information posted by PPChacker on this thread (http://alt.org/forum/index.php?t=msg&th=15&start=0&rid=&S=0dd0866177b669c57d5a4e30c31434dc#msg_num_11) about what a normal Tystream header should look like, you will notice that it looks very correct.

Now, heres the header of the hashed one:

9D30D75A
6EC93AD1
0B7FFE4E
7FC4B95C
B6BAF51C
F160AAB2
EBE61BE6
C8D9429C

As you can seee, its just garbage.

AlphaWolf
01-19-2003, 02:58 AM
Ah! doc! you scared me... :)

TheDoctor
01-19-2003, 04:03 AM
I had not bothered to check before but apparently the SA units are still unencryptred on the Sereis 2, so I cannot try this out.

olaf_sc
01-19-2003, 04:29 AM
Hello

I guess that we are talking about S2 DTivo here. If so it would be very nice if you could send me say 200 chunks of a tystream. Tydemux can already demux S2 SA streams but I have not yet got my hands on a DTivo S2 so I can't be sure if tydemux can demux it. It would also be nice to just take a look at it in general.

Cheers Olaf

PS: My ftp site is ftp://66.121.15.35/S2 if you want to upload please attache your nick to the filename.


Originally posted by mrblack51
ok, i did the following, once from a clean booted recording, and once with a recording after the kmem patch:


mfs_export -c 131072 80793 FILENAME.ty


attached are the results below. mfs_stream and mfs_export seem to work fine from my testing with other files in the mfs (PNG files).

jdiner
01-28-2003, 12:39 PM
Originally posted by mrblack51
ok, i did the following, once from a clean booted recording, and once with a recording after the kmem patch:


mfs_export -c 131072 80793 FILENAME.ty


attached are the results below. mfs_stream and mfs_export seem to work fine from my testing with other files in the mfs (PNG files).

Execellent. While what is there is not even 2 complete chunks. I was able to verify that what is there from the second chunk is indeed pretty standard.

Starting at HEX 1 F000 you get:

3 0x01 packests, 3 0x02 packest, and a bunch of audio and video interleaved packets. But what should follow as the unencrypted data does not line up as data. The problem is there is just not enough of that clip to really dig into it.

--jdiner

egocentric
04-29-2003, 11:56 AM
Originally posted by alldeadhomiez
Ok guys try this if you're bored:

./kmem 800b23b4

iff you get "800b23b4 = 8fa200f0" then try:

./kmem 800b23b4 00001021

Tried on 3.1 with a series2.


I just tried this on a Series 2 DTivo (HDVR2) with 3.1.U5-01-2-151 image.

After changing the value at that address, I couldn't watch previously recorded shows.. as expected. When I recorded something new, however, I couldn't watch it either. Both cases gave me a delete option when I tried to play it. When I set the memory value back to the old value (8fa200f0), I got the same thing. I had to reboot in order to regain the ability to record and watch previously recorded shows.

Someone mentioned, in another thread, the existance of a 'noscramble module'. Has anyone created a module that does this? Or, should this command, as shown above, work?

Is it possible the address moved for my system? When I cat /proc/ksyms and grep for that address (800b23b4), I see nothing. I know just enough about this stuff to really do some damage, so I'd appreciate some pointers before I poke around anymore.

Thanks...

mrblack51
04-29-2003, 02:05 PM
the command works as posted. you should be running it from your hackinit script on boot, and it will work fine.

the 'modules' that people refer to are for the s1 units only. no module for the s2 exists yet.

egocentric
04-29-2003, 05:05 PM
Following up to say it worked! In case any other noobs (like me) stumble upon this thread.... I put the kmem statement above in my hackinit file. I lost the ability to view all my previous recordings, but I didn't mind scrapping everything. A simple test with a short clip showed that the video was unscrambled.

Thanks a lot alldeadhomiez and Mr. Black!

blunderbuss
06-05-2003, 10:33 PM
Just as a followup for those running v4.0 on a Series2/Standalone... you can still use kmem, however you need to use the address 800bf958. i.e.:



kmem 800bf958 00001021


Thanks again to alldeadhomiez for posting the original work.

alldeadhomiez
06-05-2003, 11:29 PM
Originally posted by blunderbuss
Just as a followup for those running v4.0 on a Series2/Standalone... you can still use kmem, however you need to use the address 800bf958. i.e.:



kmem 800bf958 00001021


Thanks again to alldeadhomiez for posting the original work.

That's interesting. I'm curious to know, though - are you using monte to load a 4.0 kernel with a null initrd beforehand, so that you can get a shell on the box? In that case it would be pretty easy to just #ifdef the scrambling crap out of the kernel and recompile.

Anyone play with LBA48 yet?

blunderbuss
06-06-2003, 01:09 AM
Originally posted by alldeadhomiez
That's interesting. I'm curious to know, though - are you using monte to load a 4.0 kernel with a null initrd beforehand, so that you can get a shell on the box? In that case it would be pretty easy to just #ifdef the scrambling crap out of the kernel and recompile.

Anyone play with LBA48 yet?

Yes, I am using monte. I used Steve White's killinitrd-s2 (http://tivoutils.sf.net) to neuter the initrd.

While it certainly wouldn't have been a problem for me to recompile the kernel without the scrambling support, I figured it would be easier "for the masses" if they could just throw kmem into their rc.sysinit file, hence the post.

mrblack51
06-06-2003, 03:05 AM
Originally posted by blunderbuss
While it certainly wouldn't have been a problem for me to recompile the kernel without the scrambling support, I figured it would be easier "for the masses" if they could just throw kmem into their rc.sysinit file, hence the post.

even if you aren't compiling the kernel from scratch, a dd modification would be better suited, since it can be done once, rather than having to run kmem on bootup. you are modding the kernel once, might as well do it again.

gotta say good job on finding the new location for the patch.

Hamsterman
06-07-2003, 12:53 AM
Originally posted by mrblack51
even if you aren't compiling the kernel from scratch, a dd modification would be better suited, since it can be done once, rather than having to run kmem on bootup. you are modding the kernel once, might as well do it again.

gotta say good job on finding the new location for the patch.

When I used dd to make a backup of the U5 kernel, there were two locations containing 8fa200f0. The first, at 000B03D4, is the one being modified by Kmem at 800B23B4, since there is a 32-byte header at the start of the kernel image and the load address of the kernel (contained in the header) is 80002000. The other, at 000B6098, is unknown.

BTW, that 32-bit header contains the length of the kernel (hint for future initrd killers) and the length of the kernel + initrd. I don't know if this will be a problem if they aren't changed to 'correct' values when the initrd is killed.

Anyone with a hex editor, a kernel image, and can follow the well-commented code for kmonte.c can see what I mean.

Hamsterman
(part of the teeming masses)

MuscleNerd
06-07-2003, 01:53 AM
Originally posted by Hamsterman
the well-commented code for kmonte.c
Heh...thanks!

bitwaster
06-07-2003, 11:32 AM
i have a tivo 60-hour sa/s2 using monte to boot a patched 4.0 kernel. i've been trying to get kmem to "do the right thing" and unscramble the video, but i'm not sure i have it right.

i have the kmem binary in /var/hack/bin, and i tried the line

/var/hack/bin/kmem 800bf958 00001021

at the end of /etc/rc.d/rc.sysinit and also somewhere in the middle (before the kernel module for the fan was loaded in). in both cases, the tivo records just fine and while it is recording i can view it just fine. once the video finishes recording, i can select it in the now playing list however the tivo refuses to play it. it complains that the signal must of been bad, or something like that.

does anybody have any ideas?

mrblack51
06-07-2003, 12:30 PM
Originally posted by Hamsterman
Anyone with a hex editor, a kernel image, and can follow the well-commented code for kmonte.c can see what I mean.

Hamsterman
(part of the teeming masses)

i agree, and i could have done it myself if i had the files in front of me. however, i found it refreshing to see someone come in and use their first post to give out useful information.

Hamsterman
06-15-2003, 12:55 AM
I dusted off my rusty c skills and heavily modified MrBlack51's replace_initrd program. It is useful only for those with modified proms or using 2-kernel monte (ie not me, yet).

s2_fix_kernel replaces the existing init_rd with alldeadhomiez null-linuxrc.img.gz (embedded in the program) and fixing the 32-byte kernel header. It also searches for and patches the kernel for noscramble, which works (at least for 3.1).

I'm only attaching the c code, since I'm embarassed to say that I don't have a gcc that works with those bootable linux cds, which is the only linux I have. If you know which gcc works with that linux, let me know. I debugged in a dos environment, so I couldn't actually test the backup function. I checked the results with a hex editor, so at least it is doing what I think it should be doing.

Testing:
3.0 - Untested
3.1 u5 - Noscramble at b03d4 (kmem 800b23b4). Not tested in unit
3.1 01 - Noscramble at b03d4 (kmem 800b23b4). Not tested in unit
3.2 - Noscramble (?) at b0370 (kmem 800b2350). Not tested in unit
4.0 - Noscramble at bd978 (kmem 800bf958). Not tested in unit

It would be useful to see if the noscramble search finds the right location in 4.0, and whether it gets a false positive on 3.0 and 3.2.

Just trying to give something back.

Hamsterman

MuscleNerd
06-15-2003, 04:38 AM
I didn't try out the initrd functionality, but your code correctly identified the patch locations for 3.2 and 4.0 (800b2350 and 800bf958)

Homer S
06-18-2003, 01:11 PM
Hamsterman,

I used the killinitrd file on my kernel (I like the patch approach v. the null initrd approach). What needs to be modified in this file to only do the patch, not the nullinitrd part? Here would be commenting out what I think writes the nullinitrd part:

/* Go to start of init_rd and replace it */
/* fseek(kernel, kern_size + 32, SEEK_SET); */
/* fwrite(&kString, 1, NULL_LINUXRC_LEN, kernel); */

Will that do it? A more elegant approach might be to add a switch for either function or both...

Thanks

Homer Out

P.S. Still working on getting a cross-compiler to work on my Win98 box (have CygWin and have tried gcc and am working on some others CC's).

mrblack51
06-18-2003, 08:02 PM
Originally posted by Homer S
Hamsterman,

I used the killinitrd file on my kernel (I like the patch approach v. the null initrd approach). What needs to be modified in this file to only do the patch, not the nullinitrd part? Here would be commenting out what I think writes the nullinitrd part:

well, one option is to make a copy of the backup of the kernel which im sure you made before doing any modifications. also, if hamsterman's code is based on mine, then it shouldnt be a problem to run it on a kernel which has already been nullinitrd'd or killinitrd'd.

course, you could make a backup of your current kernel and then use his code and try it. its not going to fry your unit or anything. worst case would require you to pull your drive and dd the kernel backup over to it.

Homer S
06-18-2003, 11:44 PM
Hi Mr Black!

I did backup my 3.1.0 kernel (I have a bunch of backups... not taking any chances here). I will use this program to patch following the killinitrd, once I get it compiled.

After that comes resizing the partitions to use the mimimal 3.1.U5 parts to monte from.

I keep bumping into things to learn, installing and building Kraven's pkg. The latest trick is that it hangs on a particular bit and locks up the whole PC. Can't figure a way to exit it gracefully.

Thanks,

Homer Out

Hamsterman
06-19-2003, 12:40 AM
Originally posted by Homer S
Hamsterman,

I used the killinitrd file on my kernel (I like the patch approach v. the null initrd approach). What needs to be modified in this file to only do the patch, not the nullinitrd part? Here would be commenting out what I think writes the nullinitrd part:

/* Go to start of init_rd and replace it */
/* fseek(kernel, kern_size + 32, SEEK_SET); */
/* fwrite(&kString, 1, NULL_LINUXRC_LEN, kernel); */

Will that do it? A more elegant approach might be to add a switch for either function or both...

Thanks

Homer Out


I will assume that the 'killed' initrd has zeroed out the gzip header and/or made the initrd length zero in the 32-byte header.

You can just comment out the fwrite in order to prevent adding a new initrd, but since earlier I check to see if there is a gzip header after the end of the kernel, that would also have to be modified as well:


/*
if ( l_word != GZIP_HEADER )
{
printf("Kernel %s does not have init_rd in expected location, aborting.\n", argv[1]);
printf("Read %x\n", l_word);
printf("Expected %x\n", GZIP_HEADER );
fclose(kernel);
exit(1);
}
*/


and then comment out the part that changes the initrd:

/* Adjust kernel + initrd size in boot block header */
/*
image_size = kern_size + NULL_LINUXRC_LEN;
fseek(kernel, 24, SEEK_SET);
l_word = byteswap(image_size, swapped);
fwrite(&l_word, 4, 1, kernel);
*/
/* Go to start of init_rd and replace it */
/*
fseek(kernel, kern_size + 32, SEEK_SET);
fwrite(&kString, 1, NULL_LINUXRC_LEN, kernel);
*/


Since I'm still re-learning c I'm working on command line options first. Since that uses <unistd.h>, I'll probably have to re-write the file functions to use those functions instead of <stdio.h>. Then I can have it do all sorts of things, such as truncate the file to include only the kernel image + initrd, reducing those 4MB dd'd files down to 1MB.

Hamsterman

Hamsterman
06-23-2003, 01:58 AM
Originally posted by Homer S
Hamsterman,

I used the killinitrd file on my kernel (I like the patch approach v. the null initrd approach). What needs to be modified in this file to only do the patch, not the nullinitrd part? Here would be commenting out what I think writes the nullinitrd part:

/* Go to start of init_rd and replace it */
/* fseek(kernel, kern_size + 32, SEEK_SET); */
/* fwrite(&kString, 1, NULL_LINUXRC_LEN, kernel); */

Will that do it? A more elegant approach might be to add a switch for either function or both...

Thanks

Homer Out



I took this as a learning experience. I figured out how to use the command parser, and now it does a lot of patch stuff, including searching for a different value, or writing to a specific location.

Thanks, Musclenerd, for checking out the patch locations.

Hamsterman

<edit: changed source code for a couple errors, specifically that if the initrd isn't changed, the kernel won't be patched. Added a fixed-length file truncation so I could make my 4M u5 kernel image to a 2M >

<edit 2: now have compiled version in the zip, no need to find a compiler now :-) >

Hamsterman
06-25-2003, 01:09 AM
Oops, there were a couple of bugs, most notably if the init_rd isn't changed then the kernel won't be patched.

While I was at it I added another feature, truncating the file to a fixed length. This would be useful to turn a 4M dd'd kernel image to a 2M one.

Hamsterman

Hamsterman
06-28-2003, 12:05 AM
Okay, I managed to get access to a Linux machine and compiled my program there. I was able to run it on my machine using the latest Turbonet boot CD, and the backup function did work.

So, the zip file now contains a linux 586 binary in addition to the source code.

Hamsterman

needo
07-11-2003, 11:31 AM
Originally posted by blunderbuss
Just as a followup for those running v4.0 on a Series2/Standalone... you can still use kmem, however you need to use the address 800bf958. i.e.:



kmem 800bf958 00001021


Thanks again to alldeadhomiez for posting the original work.

I'm curious. How are you extracting the ty streams to your PC? What apps are you using on the 4.0?

Thank you.

bitwaster
07-11-2003, 11:41 AM
has anybody patched the 4.0 kernel to remove encryption yet? just wondering if this is something i should put on my todo list.

for reference - i used steve white's killinitrd to create a kernel that i'm loading using the two kernel monte (using BASH_ENV to load up my 4.0 system without hardware checks). but ideally i would like to see a utility that will not only kill the hardware checks, but remove the encryption routines.

also - is the source to killinitrd posted somewhere?

needo
07-11-2003, 11:47 AM
Originally posted by bitwaster
has anybody patched the 4.0 kernel to remove encryption yet? just wondering if this is something i should put on my todo list.

for reference - i used steve white's killinitrd to create a kernel that i'm loading using the two kernel monte (using BASH_ENV to load up my 4.0 system without hardware checks). but ideally i would like to see a utility that will not only kill the hardware checks, but remove the encryption routines.

also - is the source to killinitrd posted somewhere?

Not that I've found so far. Im using the same basic configuration you are. I posted instructions on http://www.superhero.org/tivo/

If you could let me know how you are pulling down the streams it would be a great help.

Thank you.

bitwaster
07-11-2003, 12:12 PM
i'm just using vserver binary with tivo-mplayer that has been compiled for the series 2. if you use the kmem trick, i find (if i remember correctly) that i could stream the television shows off my tivo fine using tivo-mplayer, but i could not play them back on the tivo.

needo
07-11-2003, 12:18 PM
Originally posted by bitwaster
i'm just using vserver binary with tivo-mplayer that has been compiled for the series 2. if you use the kmem trick, i find (if i remember correctly) that i could stream the television shows off my tivo fine using tivo-mplayer, but i could not play them back on the tivo.

Yeah unfortunatley Im running Windows and need a way to get the .ty files on to my PC.

bitwaster
07-11-2003, 12:20 PM
oh - that shouldn't be a problem at all. there is mplayer binaries compiled for windows (using cygwin) on the tivo-mplayer site. i believe i also did stumble upon mfs-ftp compiled for the s2...

needo
07-11-2003, 03:27 PM
Originally posted by bitwaster
oh - that shouldn't be a problem at all. there is mplayer binaries compiled for windows (using cygwin) on the tivo-mplayer site. i believe i also did stumble upon mfs-ftp compiled for the s2...

Im having a hard time finding mfs-ftp for series2 if you know where to find it please Im all ears!

fixn278
07-11-2003, 03:38 PM
File is here....

http://www.dealdatabase.com/forum/showthread.php?s=&postid=93832&highlight=mfsftp+mips#post93832

needo
07-11-2003, 11:49 PM
Originally posted by bitwaster
i have a tivo 60-hour sa/s2 using monte to boot a patched 4.0 kernel. i've been trying to get kmem to "do the right thing" and unscramble the video, but i'm not sure i have it right.

i have the kmem binary in /var/hack/bin, and i tried the line

/var/hack/bin/kmem 800bf958 00001021

at the end of /etc/rc.d/rc.sysinit and also somewhere in the middle (before the kernel module for the fan was loaded in). in both cases, the tivo records just fine and while it is recording i can view it just fine. once the video finishes recording, i can select it in the now playing list however the tivo refuses to play it. it complains that the signal must of been bad, or something like that.

does anybody have any ideas?

I'm getting the same thing. I can rip to my PC all day long but I can no longer view the video on the TiVo. Did you ever find any thing?

needo
07-12-2003, 12:37 AM
Originally posted by alldeadhomiez
That's interesting. I'm curious to know, though - are you using monte to load a 4.0 kernel with a null initrd beforehand, so that you can get a shell on the box? In that case it would be pretty easy to just #ifdef the scrambling crap out of the kernel and recompile.

Anyone play with LBA48 yet?

How would you go about recompiling the kernel?

Hamsterman
07-12-2003, 04:55 PM
Originally posted by bitwaster
i have a tivo 60-hour sa/s2 using monte to boot a patched 4.0 kernel. i've been trying to get kmem to "do the right thing" and unscramble the video, but i'm not sure i have it right.

i have the kmem binary in /var/hack/bin, and i tried the line

/var/hack/bin/kmem 800bf958 00001021

at the end of /etc/rc.d/rc.sysinit and also somewhere in the middle (before the kernel module for the fan was loaded in). in both cases, the tivo records just fine and while it is recording i can view it just fine. once the video finishes recording, i can select it in the now playing list however the tivo refuses to play it. it complains that the signal must of been bad, or something like that.

does anybody have any ideas?

If you have a copy of your kernel on your pc, make a few backups and then use s2_fix_kernel2 (or a hex editor) to find other instances. For instance, keep running

s2_fix_kernel2 -i <kernelfile1>

and note the address locations of additional locations, and kmem combinations of these in addition to the first one.

Well, it WAS just an idea.

Hamsterman

needo
07-12-2003, 06:25 PM
Originally posted by Hamsterman
If you have a copy of your kernel on your pc, make a few backups and then use s2_fix_kernel2 (or a hex editor) to find other instances. For instance, keep running

s2_fix_kernel2 -i <kernelfile1>

and note the address locations of additional locations, and kmem combinations of these in addition to the first one.

Well, it WAS just an idea.

Hamsterman

Thanks. Im running this now, what exactly am I looking for? Do you have any output examples for 4.0?

Thanks!

needo
07-12-2003, 08:23 PM
I ran s2_fix_kernel three times and it found valid memory addresses to patch. I don't have them written down unfortunatley. However everything I record with the Tivo I can no longer watch on the Tivo.

I can stream it off just fine, I just cannot watch it directly from the TiVo.

Any ideas?

I patched the kernel using s2_fix_kernel -i and then I killinitrd'ed it using the tools from tivoutils.sourceforge.net. When letting s2_fix_kernel do both the TiVo failed to boot.

needo
07-12-2003, 08:34 PM
Originally posted by needo
I ran s2_fix_kernel three times and it found valid memory addresses to patch. I don't have them written down unfortunatley. However everything I record with the Tivo I can no longer watch on the Tivo.

I can stream it off just fine, I just cannot watch it directly from the TiVo.

Any ideas?

I patched the kernel using s2_fix_kernel -i and then I killinitrd'ed it using the tools from tivoutils.sourceforge.net. When letting s2_fix_kernel do both the TiVo failed to boot.

s2_fix_kernel found 0xc5110 in addition to 0xbd9778 . Also 0xc525c was patched.

This time s2_fix_kernel initrd did work. I let it run all the way through the above memory addresses then did the initrd patch.

However everything I now record are still unplayable on the TiVo.

Any ideas? Im stumped.

buktotruth
08-18-2003, 10:15 PM
I'm having the same problem as needo. I can't watch anything i recorded on my tivo. I applied the kmem patch and it runs on startup with no problems, but this still doesn't help (with previously recorded shows, as well as ones recorded after kmem)

Please help...i'm sitting here with my just recently bashed tivo and i can't watch it :confused:

mrblack51
08-18-2003, 11:34 PM
i dont remember who actually got that kmem patch to work. as such, i will pull it if nobody can post sucsess with it soon

buktotruth
08-18-2003, 11:38 PM
Originally posted by mrblack51
i dont remember who actually got that kmem patch to work. as such, i will pull it if nobody can post sucsess with it soon

I would really appreciate it if you could pos t this ASAP as I am without Tivo :( .

Thanks!

David Bought
08-20-2003, 11:09 AM
Originally posted by buktotruth
I'm having the same problem as needo. I can't watch anything i recorded on my tivo. I applied the kmem patch and it runs on startup with no problems, but this still doesn't help (with previously recorded shows, as well as ones recorded after kmem)

Please help...i'm sitting here with my just recently bashed tivo and i can't watch it :confused:

Hey, I have an idea. If the patch doesn't work, why don't you just remove it and watch TV again? If the patch hosed your tivo and you need to reimage, what are you waiting for?

It has been mentioned that recompiling the kernel with the scramble code disabled will probably solve the problem. If you have not tried this yet, what are you waiting for? If you have tried this with no success, what went wrong?

buktotruth
08-20-2003, 11:13 AM
Originally posted by David Bought
Hey, I have an idea. If the patch doesn't work, why don't you just remove it and watch TV again? If the patch hosed your tivo and you need to reimage, what are you waiting for?

It has been mentioned that recompiling the kernel with the scramble code disabled will probably solve the problem. If you have not tried this yet, what are you waiting for? If you have tried this with no success, what went wrong?

As far as watching TV, i do watch without the Tivo (I know I know...its not the same).

Recompiling the kernel...well...i'm a semi-newbie and have no clue how to do that...if you could refer me to a how-to i would greatly appreciate it.