PDA

View Full Version : CSO patch for 4.01b2 doesn't work?



gorilla daddy
06-25-2004, 02:21 PM
echo -ne "\\x24\\x02\\x00\\x00" | dd conv=notrunc of=/var/hack/tivoapp bs=1 seek=8618248



0x00c380f4 8fbc0010 lw gp,16(sp)
0x00c380f8 ae500000 sw s0,0(s2)
0x00c380fc 8f9981ec lw t9,-32276(gp)
0x00c38100 00000000 nop
0x00c38104 27397be0 addiu t9,t9,31712 # t9 = 0x00C37BE0
0x00c38108 24020000 li v0,0 <--- replaced jalr t9
0x00c3810c 00000000 nop
0x00c38110 8fbc0010 lw gp,16(sp)
0x00c38114 10400018 beqz v0,0x00c38178


Ok, so the CSO's aren't created. That much works.

On my standalone S2 I'm getting all 0's on extraction for the actual TY data? So, the tystreams are still encrypted? Both with tserver & mfs_ftp.

I was up way too late last night. Any ideas what might be going on?

-- gd

psxboy
06-25-2004, 02:27 PM
Are you trying to extract stuff that was recorded BEFORE you applied the no-cso patch? The patch doesn't un-encrypt already recorded stuff... it just turns off encryption for any new recordings you make (while still retaining the ability to play-back any encrypted recordings that were made before the patch).

If I'm totally off the mark here, maybe you could explain what you mean by "getting all 0's on extraction"?

-psxboy

gorilla daddy
06-25-2004, 02:41 PM
Every byte in the downloaded TY file is 0. Yes, of course this is after applying the patch. The recordings play fine on the TiVo.

PSXboy, you have extraction/decryption and workingCSO patch for 4.01b2 or not? This is the latest rev for the standalones, that TiVo sent down these past few weeks.

If the above patch works for you, or anyone else, I'd like to know.

-- gd

malfunct
06-25-2004, 02:51 PM
Every byte in the downloaded TY file is 0. Yes, of course this is after applying the patch. The recordings play fine on the TiVo.

PSXboy, you have extraction/decryption and workingCSO patch for 4.01b2 or not? This is the latest rev for the standalones, that TiVo sent down these past few weeks.

If the above patch works for you, or anyone else, I'd like to know.

-- gd

Were the video's you are trying to extract encrypted before you applied the patch? If so they will play fine on the tivo but not be correctly extracted because of the encryption (though they shouldn't be all zero, they should extract as real tystream data and just be unusable by any of the tools on the PC due to encryption. Maybe its just mfs_ftp that can extract encrypted tystreams.). Anyways, the key to remember is that there is no tool for series 2 tivos at this time that unencrypt files that are encrypted, the patches just let you recorde new video as unencrypted. The patch you installed is an improvement in that you can still play the encrypted files on the tivo, and also that you can play the unencrypted files on an unhacked tivo (if you can find a way to get them in there) because they have proper cso keys set for unencrypted streams.

alldeadhomiez
06-25-2004, 03:11 PM
Every byte in the downloaded TY file is 0. Yes, of course this is after applying the patch. The recordings play fine on the TiVo.

That's not right. There is something wrong with the tools you are using to extract the streams. Check to make sure they are being built with the LARGEFILE stuff (and not the fake O_LARGEFILE flag that is used on the Series1 binaries).

gorilla daddy
06-25-2004, 03:59 PM
Hey guys, thanks for trying to help out, even though you may have thought I was being dopey & trying to extract encrypted streams made before the patch.

Yes, this happens with new recordings, made after the CSO patch. The CSO entries for the FSIDs are 0, as they should be. But the extracted TY is all 0's.

The tools are the same ones that I was using fine on 4.01b1

I may have mucked up something in my modified kernel. I'm restoring the original one, and will try it out.

psxboy
06-25-2004, 04:54 PM
Now you've got me nervous... I haven't tried extracting anything since I updated to 4.0.1b-2. But since the only differences between 1 & 2 were some text related to HMO, extraction should work the same as it did in 1.

I will verify that I can still extract valid video files later tonight...

-psxboy

gorilla daddy
06-25-2004, 05:18 PM
I put on the stock kernel, same problem.

So, now somebody extract from 4.01b2. And report your results.

gorilla daddy
06-25-2004, 05:22 PM
Homie, please post a tserver that has that LARGEFILE you were talking about. I'll report back.

malfunct
06-25-2004, 06:40 PM
Homie, please post a tserver that has that LARGEFILE you were talking about. I'll report back.

So if I understand your post, you took the existing nocso (otherwise known as the "new" noscramble hack) hack and applied it to the 4.0.1b2 tivoapp? It seems like you even looked for the new offset to apply it at so I don't think its the simple issue of wrong offets. Could it be that tivo found out how we were bypassing thier code and changed things so that it didn't work that way? I'm reaching here but its something I'm wondering.

Something still sort of sticks with me though, if it were a common problem to be unable to extract after updating to the new version of the tivo OS, we would have far more complaints about it here so I sort of go back to thinking that you don't have things set up right.

BTW, sorry if this is a crazy rant, I'm just trying to brainstorm as I type so its probably sort of messed up :)

gorilla daddy
06-25-2004, 06:45 PM
Yes, I disassembled the latest tivoapp to find a similar nocso patch. It matches the existing one for 4.01x

I don't know why it's not working. I'm waiting for someone to confirm that they can extract video from 4.01b2.

I'll be glad to know either way. I just want to know where to focus my efforts.

SR712
06-25-2004, 07:57 PM
I don't know what 4.01b2 is... but I can tell you that 4.01b extracts just fine.

BTUx9
06-26-2004, 12:50 AM
echo -ne "\\x24\\x02\\x00\\x00" | dd conv=notrunc of=/var/hack/tivoapp bs=1 seek=8618248

If that was the actual line you executed, you've got problems.
By my count, that line would replace 16 bytes instead of 4.
I hope it's just a typo.

Sleeper
06-26-2004, 02:52 AM
If that was the actual line you executed, you've got problems.
By my count, that line would replace 16 bytes instead of 4.
I hope it's just a typo.

Yes, I am also wondering why he is escaping the backslash causing the second backslash and the following "x" to be 2 additional characters.

gorilla daddy
06-26-2004, 05:50 AM
Actual telnet log:



> 0x00000: 65 63 68 6f 20 2d 6e 65 20 22 5c 78 32 34 5c 78 echo -ne "\x24\x
> 0x00010: 30 32 5c 78 30 30 5c 78 30 30 22 20 7c 20 64 64 02\x00\x00" | dd
> 0x00020: 20 63 6f 6e 76 3d 6e 6f 74 72 75 6e 63 20 6f 66 conv=notrunc of
> 0x00030: 3d 2f 76 61 72 2f 68 61 63 6b 2f 74 69 76 6f 61 =/var/hack/tivoa
> 0x00040: 70 70 20 62 73 3d 31 20 73 65 65 6b 3d 38 36 31 pp bs=1 seek=861
> 0x00050: 38 32 34 38 0a 8248.


No, it wasn't a typo. Just part of a Perl script.

psxboy
06-26-2004, 04:36 PM
Ok... I've got no problems with extracting. I tested last night & everything's A-OK for me. Dunno what happened in your case, but there are virtually no changes in the binaries between 4.0.1b-2 and 4.0.1b-1... the only difference between the two versions was some HMO-related text added to the resources. The tivoapp patches for 4.0.1b-1 are exactly the same as for -2.

Looking back at your first post, I think I see the problem...

Sw Version Offset Original Value New Value
4.0.1 & 4.0.1b 00838108 0320f809 3C020000

That would make the command:

echo -ne "\x3c\x02\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=8618248

Restore your original tivoapp & re-patch it.

-psxboy

gorilla daddy
06-30-2004, 12:18 AM
Thanks everyone for letting me bounce this annoyance around with you.

Here's what happened: my kernel source files timestamps were mostly wrong, and definately unreliable. So, when I was compiling the kernel, some of my changes weren't compiled & linked in. Some were, some weren't.

I'll use Windows editors, sometimes linux programs, to manipulate the source files.

I run Virtual PC for my linux tivo compiles. The linux clock is never in sync. You can't fix it with synching to a timeserver, because it won't happen frequently enough. Any difference with the host time and you'll eventually get the problem I had.

Neither Microsoft nor Connectix ever released a proper host/guest timesync fix. They have them for DOS & Windows guests, but not Linux.

So I'm attaching one. Run this at your Virtual PC's guest linux startup. It syncs the linux clock with the host clock. And that's what you want.

gorilla daddy
06-30-2004, 12:21 AM
run as part of your linux startup (only when running under Virtual PC!)