PDA

View Full Version : MRV transfers involving 7.1 certificates



hmo_rox
02-23-2005, 09:51 PM
Since the 7.1* rollout started, it has been noted that:

1. unhacked 7.1 boxes will not communicate with any superpatched box
2. SA boxes running 4.0.1b that are on the 7.1 rollout list receive new, incompatible MRV group certificates which are not recognized by tivoapp. In addition, certificates created by set_mrv_name_ADH.tcl are wiped during the daily call, since the keyserver does not recognize them.
3. the "no thanks" patches address the dropped key and nightly reboot issues
4. there is currently no public superpatch for 7.1

Upon further investigation, we find:

5. 4.0.1b will accept MRV group certificates named MRV_2-* and TIVOVID_2-*
6. the 7.1 MRV group certificates are named MRV_production-*
7. 4.0.1b can be forced to recognize group certificates named in this way by patching tivoapp offset:

d3e354: 32 2d -> 00 00

8. absent the superpatch, it MAY be possible to convince 4.0.1b to accept group certificates with invalid signatures (either 7.1* certificates or set_mrv_name produced certificates) by changing the following tivoapp offsets:

19f87c: 00409021 -> 00009021
19f89c: 00409021 -> 00009021

9. Attached to this post is a modified version of set_mrv_name, called set_mrv_name_test.tcl, which creates group certificates using the 7.1 naming pattern. Actual 7.1 certificates may vary; if they do, tell us why.

10. set_mrv_name will need to be modified for 7.1 (or this version will need to be used on a 7.1 box), since set_mrv_name_ADH.tcl creates TIVOVID_2-* certificates on a 4.0.1+ system. TIVOVID_ is no longer a valid MRV certificate prefix on 7.1.

Based on your situation, you may take one of two approaches:

1. If you are using MRV between hacked and unhacked boxes, and some of those hacked boxes are held back at 4.0.1b, apply the three patches in this post and accept the authentic 7.1 MRV certificates from the mothership. Optionally, apply the "no thanks" reboot patch, but not the ADD/DROP patches. You will not be able to use the NoCSO patch with this setup, and therefore cannot extract video from the hacked box. Do not run set_mrv_name* on an SA box.

2. If you are using MRV exclusively among hacked boxes, but one or more of those boxes are SA units that are being held back at 4.0.1b, apply the certificate name patch from this post and superpatch-4all. Do not run set_mrv_name* on an SA box.

Notice: portions of this strategy are untested. This thread is for intelligent discussion. Do not waste your time posting support requests here.

hmo_rox
02-24-2005, 12:18 AM
1. If you are using MRV between hacked and unhacked boxes, and some of those hacked boxes are held back at 4.0.1b, apply the three patches in this post and accept the authentic 7.1 MRV certificates from the mothership.

These patches may also be required to force full HMO functionality on a non-superpatched unit absent valid 4.0.1b spigot keys. Addresses are file offsets, not VMA.


0xc8b14: 00408021 -> 24100001
0xd3f34: 00408021 -> 24100001
0xe56ec: 00408021 -> 24100001
0xec678: 00408821 -> 24110001
0x179318: 00409821 -> 24130001
0x406ed8: 00408021 -> 24100001
0x406f00: 00403821 -> 24070001

Note: all of the patches I have posted so far, except the MRV_2- patch, form a subset of the 4.0.1b port of the HMO superpatch. These are not new discoveries.

NutKase
02-24-2005, 04:23 AM
At the risk of 'intelligent' discussion, I thought I'd write up what I've done thus far regarding your new found information. Congrats btw.


Previously, I had 2 SA tivos that were superpatched according to the superpatch-4all directions and with that set_mrv_name_ADH.tcl applied.

I requested to be on the list for early rollout of 7.1 but was away on business and kept my tivo from calling in, until I could return and capture the slices, so I received 7.1a-01 as the new tivo OS.

Member '7.1' was kind enough to post the patches for stopping the nightly 'pending restart' and tell us how to prevent from getting 7.1a keys.

I applied both of these patches immediately.

Now one thing to note is that I'd been running my 2 SA tivos and having no problems using HMO and MRV so either the 'fake' key provided by the script stayed with me or I was receiving valid certs from tivo. I never thought to check. So I'm unable to confirm that I was losing them and would have problems with 7.1 lying around uninstalled. Maybe some other SA users can help.

Trying to learn to port the superpatch to 7.1a, I removed the 'no thanks' add/drop keys patches and was able to get 7.1 keys downloaded.

At this point, I was messing with unsuperpatched tivoapps and cert keys having no real luck.

Your efforts are to be applauded!

I confirmed that my MRV group cert is named as stated and I proceeded with Approach#2. I also searched and confirmed that all the 'spigot' patches in the second post were part of and applied by superpatch-4all.

As far as Approach#2, I interpreted this as use only the cert patch in Item#7 and a superpatched tivoapp. I had no luck with this although everything appeared as 'Active' and my box was 'named' properly in the tivo system info, I could not see the other tivo at the bottom of my Now Playing lists and therefore no MRV.

In my earlier trials I'd been able to have my tivo's appear in each others Now Playing list but only as the 'tivo' serial number and not any kind of unique name. Also, MRV would not function indicating a cert problem or some other problem over my head right now. (There's no shortage of that.)

So I had to have a look at your script.

Well, here's where it gets tricky. I'm not sure why but it seemed to me that basically the same event was taking place so I applied it to my tivos against your advice to help with testing...

Anyway, I've become quite adept at starting over if need be...


So far it works! I can MRV both ways. Both Tivos are named properly and I appear to be back in business. Of course that's why this hobbie is fun. It may crap out when I 'force' a call in a few minutes but I wanted to report some success for now.

I don't recommend that anyone else try this. I was probably lucky or something I'd done and forgot about mattered. I'll try to duplicate and help if I can.

Anyway, just wanted to report in.


Now, ...let me force those calls and see if I'm rebuilding tivo's this weekend.

[EDIT] Looks good through a forced call and reboot x 2. I'll check on what type 'keys' I have tomorrow.

[EDIT#2] Couldn't wait, keys look the same but I guess we'll see what happens when their expiration date rolls around.


NutKase

ljvk61
02-24-2005, 08:07 AM
My Current Setup:

TCD5400040
Stock
No PROM mod
Unhacked

Software level - 7.1a 02-2-540

TCD240004A
Unmodded
Software hacked
160GB HDD MFSTools expanded to 137GB (LBA28)
killhdinitrd 4.01a
NO monte
'updatesoftware=false' in bootparms
enlarged hda1 (tivopart)
Serial bash
telnet
ftp
tivowebplus (1.1?)
tivoapp w/ only 30 sec skip patch applied.

Software level - 4.01b-02-2-240
Accepted download and blocking install of 7.1a-02-2-240

Behaviors noted:
DVR name missing after download of 7.1a-02-2-240
No MRV communication either direction between boxes.

Previous steps (before this patch) taken to try to resolve:
TCD5400040
Nothing

TCD240004A
[EDIT] : Initial post did not list what I ran
Ran set_mrv_name_ADH.tcl using name listed at tivo.com

Behaviors noted:
DVR name not accepted by TCD240004A.
No MRV communication either direction between boxes.
tcl script generated MRV key deleted after phoning home.

Further steps taken (02/25/2005):
Applied patches from this thread (current 02/24/2005 5:00AM)


d3e354: 32 2d -> 00 00

19f87c: 00409021 -> 00009021
19f89c: 00409021 -> 00009021


rebooted
No further patches made or scripts ran

Observations noted:
DVR name now appears in Settings (note - not sure if this because this is what the DVR was originally named or is a result of the set_mrv_name_ADH.tcl script run previously)
MRV communications takes place in both directions.
MRV transfers work both directions (remember these are still encrypted files)

Further steps needed to take:
Daily Call (Forced and normal)
reboot
observe, observe and observe

Comments:

This is exactly what I was looking for. So far I do not need the patche(s) listed in the second post. That may change after calling the mothership and reboots, not really sure.

I stated in another thread that I did not have sufficient skills to be a worker and for the moment was relegated to being a beggar. Well I figure that testing this would be a happy medium.

If there is any missing or confusing information listed, please let me know and I will attempt to correct as best as my memory serves me (Didn't take notes :o )

Thanks to the many members of DDB who make things like this possible!!!!

regards,

ljvk61

philhu
03-01-2005, 03:06 PM
At the risk of 'intelligent' discussion, I thought I'd write up what I've done thus far regarding your new found information. Congrats btw.


Previously, I had 2 SA tivos that were superpatched acording to the superpatch-4all directions and with that set_mrv_name_ADH.tcl applied.

I requested to be on the list for early rollout of 7.1 but was away on business and kept my tivo from calling in, until I could return and capture the slices, so I received 7.1a-01 as the new tivo OS.

Member '7.1' was kind enough to post the patches for stopping the nightly 'pending restart' and tell us how to prevent from getting 7.1a keys.

I applied both of these patches imediately.

Now one thing to note is that I'd been running my 2 SA tivos and having no problems using HMO and MRV so either the 'fake' key provided by the script stayed with me or I was receiving valid certs from tivo. I never thought to check. So I'm unable to confirm that I was losing them and would have problems with 7.1 lying around uninstalled. Maybe some other SA users can help.

Trying to learn to port the superpatch to 7.1a, I removed the 'no thanks' add/drop keys patches and was able to get 7.1 keys downloaded.

At this point, I was messing with unsuperpatched tivoapps and cert keys having no real luck.

Your efforts are to be applauded!

I confirmed that my MRV group cert is named as stated and I proceeded with Approach#2. I also searched and confirmed that all the 'spigot' patches in the second post were part of and applied by superpatch-4all.

As far as Approach#2, I interpreted this as use only the cert patch in Item#7 and a superpatched tivoapp. I had no luck with this although everything appeared as 'Active' and my box was 'named' properly in the tivo system info, I could not see the other tivo at the bottom of my Now Playing lists and therefore no MRV.

In my earlier trials I'd been able to have my tivo's appear in each others Now Playing list but only as the 'tivo' serial number and not any kind of unique name. Also, MRV would not function indicating a cert problem or some other problem over my head right now. (There's no shortage of that.)

So I had to have a look at your script.

Well, here's where it gets tricky. I'm not sure why but it seemed to me that basically the same event was taking place so I applied it to my tivos against your advice to help with testing...

Anyway, I've become quite adept at starting over if need be...


So far it works! I can MRV both ways. Both Tivos are named properly and I appear to be back in business. Of course that's why this hobbie is fun. It may crap out when I 'force' a call in a few minutes but I wanted to report some success for now.

I don't recommend that anyone else try this. I was probably lucky or something I'd done and forgot about mattered. I'll try to duplicate and help if I can.

Anyway, just wanted to report in.


Now, ...let me force those calls and see if I'm rebuilding tivo's this weekend.

[EDIT] Looks good through a forced call and reboot x 2. I'll check on what type 'keys' I have tomorrow.

[EDIT#2] Couldn't wait, keys look the same but I guess we'll see what happens when their expiration date rolls around.


NutKase


So, NutKase,

The 'final' solution for sas2 units running 4.01b in 'pending restart' is to:

Do superpatch-4all on each sas2 tivo.

Add the Nightly reboot patch
4.0.1b: Code:
5f78e4: 10400007 -> 10000007

Run the Certificate name recognition patch:
d3e354: 32 2d -> 00 00

Run the new Set_MRV_Name_Test.tcl on the 4.01b sas2 tivos (both of them)

And we should be good to go? No 'Pending restart', MRV working again and subbed callouts ok?

Did I miss something?

COOL!

philhu
03-01-2005, 03:29 PM
I tried to take superpatch, and change it to change the 2 patched items as shown:

#array set p {
# 6256868 "10400007 10000007" 13886292 "322d0000 00000000"
#}
array set p {
2062564 "10400007 10000007" 9691988 "322d0000 00000000"
}

FYI - 2062564 is decimal for 5f78e4-400000=0x1F78E4
FYI - 9691988 is decimal for D3E354-400000=0x93E354

When I run it, I get:
At offset 9691988, expected 0x322d0000 but got 0x3c060000
Aborting...

So, the certificate patch is looking for 32 2d, but it is seeing 3c 06

Anyone know why on 4.01b-02?

-edit- Something is wierd here......Using the modded superpatch, the first location is right (at 5f78e4), but the second shows wrong.

Using doHack.tcl (See post in this group), the first is wrong, but the second (at D3E354) is right! Very confused here, but I ran superpatch, applied the first location from my modded superpatch, and did dohack for the second

I am NOT moving the file or rebooting until I find out WHY it does what it did.

-end edit-

NutKase
03-01-2005, 10:49 PM
The 'final' solution for sas2 units running 4.01b in 'pending restart' is to:

No. I only posted what I'm testing, it'll probably kill your tivo or quit working.




FYI - 9691988 is decimal for D3E354-400000=0x93E354

If you mean you got that error message from superpatch-4all, it's right.

d3e354 isn't a VMA address.

The other value is.

I'm not sure posts on how to hex edit belong here.


NutKase

philhu
03-06-2005, 01:48 PM
No. I only posted what I'm testing, it'll probably kill your tivo or quit working.




If you mean you got that error message from superpatch-4all, it's right.

d3e354 isn't a VMA address.

The other value is.

I'm not sure posts on how to hex edit belong here.


NutKase

Ok...got it

So, after a few days, is it still working?

And I know, off topic, but, how do you know if you have a VMA address or not?

NutKase
03-06-2005, 03:52 PM
Ok...got it

So, after a few days, is it still working?

It was still working as of last night when I put 7.1a back in to look for patches and work on TWP.

And I know, off topic, but, how do you know if you have a VMA address or not?

You can just tell by the numbers after a while. :)


NutKase

Just kidding, usually the poster will let you know or the thread standard 'like the tivoapp patches thread' will be posted all one way. Attention to detail.