rom103-rev380--virgin or EXSUB?

[sdeens]

situation: just bought this at swap meet for $10:
--PVR522: the firmware is very old @ L208 (2.5 years ago)
--ICAM was unlocked externally on BGA board perfectly of course (see attached file dump from N2edit v2.58.
--card slot re-enable perfectly and works exactly right...done several before
I also perfomed the volitile memory dump hard reset..according to the exact procedure correctly (info/right/left etc...), just in case it needed purging.
Have relocated Dataspace back and forth from A500 to A700 using Nagraedit v5.1 from the original icam at rev380 which as you know must be at A500....I have used all known rom103 blocker permutations for icam(rev38B) and plastic too; Dishwiz, Penga, modified Codespace v15p etc...
you will pay careful note that the second IDEA key was never used by this PVR522 and it does NOT show up in the dump (this was common problem 2.5 years ago as I recall)....I manually added this patch to enable the 2nd slot for an IDEA key since the blockers for rom103 do NOT and they may be assuming it is already there from ex-subs.
0C 00 06 1B 1B 06 13 DB 00 01 01 00 00 46 08 10
--maybe this patch is wrong?
I have noted that when in Single tune mode: the PVR522 reports the dreaded "Warning 061" screen that is reserved for firmware updates, but it never updates and the scroll bar does NOT move or suggest any firmware is being spooled--even overnight....just stays there. This phonomemon was first reported in June when people incorrectly thought it was a prelude to a TSOP attack.
when in Dual tuner mode this "warning 061" screen is NOT observed at any time.
I will test only with Legacy LNB's integrated Twins for 110+119 since I use a model 6000 in this setup...maybe I must convert to Dish Pro or Dish Pro PLUS to get it to stream update--maybe L208 will not work with Legacy?
I updated TIERS using seval methods of patching, and in some permutations I first cleaned codespace and sometimes I did not....but in the end I tried about 2 dozen blocker permutations...Its is long been known that is better NOT to clean codespoace for reactivation of cardkess IRD's until you first get video restored.
1. why is this PVR522 NOT updating firmware from L208 and could this be the reason the video is all black, but preview channels work fine (i.e channel 101)?
--And I do NOT wish to do the eeprom corruption trick: short pin #3 +6 at startup--U23 chip to force firmware update for obvious reasons.
2. why is video still blacked out despite the guide looking fine, tiers looking good, and preview channels working perfectly with sound....?
testing of course all known keys even the one that changed today and was incorectly posted:
Key 0: (A6) 09 D3 14 86 DC 86 69 49 C3 5A 9E B1 68 45 1D(Active)
--and I also tried: (A2) 09 D3 14 86 DC 86 69 49 C3 5A 9E B1 68 45 1D
Key 1: 90 4E 48 12 4A 6B 33 FB A5 D4 41 32 94 DA 24 DC
BTW,
this must be an EX-SUB since the hardrive has 93 hours remaining and some TV shows were taped last Feb 2005...

or is it?
I want to test this with ST19, but I can NOT find the proper Atmel dump for rom103 rev38B that works serially with XPAtmel v1.3.1..
I attached the .hex file I found but it looks like it needs to be re-grouped for usage with serail flashing via XPAtmel into the two eeprom+program loader files.

3. anyone have the proper two(2) files for the Atmel for the rom103-rev38B for Charlie and ST19 testing and NOT just the .hex file?
Also, to circumvent the security of the UPLOAD mechanism:
just rename the rom103 file using any HEX EDITOR program (i.e HexEfdit v1.2 works fine)with the extension of .bn103 and save it as a binary file..this way you can examine it with Nagramaster v4.1 I had to upload it as a .txt file to get around this problem...same goes also for the rom103 2-chip Atmel flash for ST19 MAX-MEL emulation.



I removed the 522 file for your protection......that has your receiver and cam numbers in it. And the other in case it does too. If you really want them posted, knowing what I just said, PM me I'll put them back.

[skinerd]

A rev 380 can definately be ex-sub. Yours definately ex-sub, receiever number and tiers on it.
I always convert to plastic revisions, so that plastic blockers can be used. Setting an Icam to plastic revisions definately works, I have done several, no problem
A bn103 can be renamed to bn102, and 102 programs, like gendt08 will read it and you can set up keys etc. Just rename back to bn103 when done.
The low firmware version is prolly why you are black now.
There are ST19 testers here, so hopefully you will get some help on that.

I don't know about the LNBs, do a switch check and if they detect, they should be fine, if they won't detect, then it will never update as it gets no signal.


The 522 file you posted has all the info needed for someone to get your numbers and all the info needed to make a private keyset. Below is a cap of the GenDT08-SK reading showing some of the tiers in your file.

[sdeens]

I forgot that GenDT08 does not natively support rom103's...so renaming into a .bn102 allowed me to finally load it and be recognized...that's definately an out-of-date program that needs to add rom103 support properly.

What your testing for to verify if they are ex sub is not the presence of TIERs or box keys or IDEA keys but the card's RSA (P and Q) columns have to be populated when examined under old GenDT08 v3.3...and these are what would you see for EX-SUBs..virgins are blank...

P: C3478F63F51349B57E1E0F58E1D3D5C962CAC6DE773B4D8056 BADE57683C2403
Q: B9A95DB73FB919217DC8C2706295DCE8ED17E5BBCA967C23DE 2073AE32AC3C53


I am convinced that the problem is that the firmware is so out-of-date L208 and that is causing the blacked out video with only proper working preview channels...I have seen this before with cardless IRD's juts not a PVR522 at L208.

I can try a few more permutations working with some of the rom103 plastic blockers as opposed to icam blockers, since i already knew they worked for both...

If I get that working I can clean codespace and try st19 with that rev38b revision patch especially made just for emulation not plastic.

But, who has the proper rom103 rev38b 2-chip Atmel file...not the standard .hex file (6kb in size) but the 2 files for flashing serially with XPAtmel v1.31.?

i.e. rom103-rev38b.exe.eepro.hex
rom103-rev38b .exe.program.hex


but this receiver is worthless unless it talkes the update beyond L208 which is refuses to do for several days depsite proper Legacy check switches..stuck on that dreaded WARNING 061 screen I have been reading is a problem lately since first identified in June of this year.

and the Wildfrog JTAG cloning method is juts too complicated and is not well documenetd in any other forum besides rom10x, (I have all the files) since that was an exclusive method to the rom10x supporters and that site is now gone underground...and without access to that site and its technical thread its a problem not worth trying to clone because it was buggy to say the least and very hard to setup...it was a hundred pages deep that thread because of all the beta tetsing problems he intially had.

this leaves ONLY the corruptiuon of pin #3 and #6 of the U23 serial eeprom chip to try and force a download of firmware....or maybe first replace LNB's with DISH PRO only...or as a last resort Wildfrog CLONE method.

The presence of legacy LNB's and firmware L208 is probably a bad combination for stream loads, escpecially at that ancient L208 firmware.

These IRD's 2.5 years ago did NOT have a stable option for "single tuner" usage since the DISH-PRO separator was only then just hitting the public market...it was dual tuner or nothing or it would lock up or freeze in single tuner mode with old LNB's...that's excatly why they made that cheapo mini DISH PRO Separator so people could avoid changing out Dish Pro LNB's with the newer DISH PRO Plus LNB's and avoid running physically a second line.

[skinerd]

P and Q can be wiped during a desub, so there absense does not indicate a virgin.

The seperator requires a Dish Pro Plus LNB, only needs 1 cable from the LNBs.

[pecker88]

only way to get around the message 061 is to install a jtag and write more current fw to the ird, then it will properly update to current rev fw.

Their is already a thread started here by dirtyb115. Just did this last week and it worked great!!! Was having the same prob. at fw revL202.

good luck

[sdeens]

I'll check into that thread by: dirtyb115


But why not just disconnect hard drive ribbon cable and try first the serial eeprom corruption trick at U23-pins #3 and #6 shorted for 25 seconds at startup?

its worked flawlessly on many older Dish Pro and even Legacy receiver's that had stubborn firmware, but of course its risky and could fry that tiny chip and necessitate a virgin replacement.....never tried it on a cardless IRD

but its good to know now that this problem was first identified in June from the other threads I scanned...its fairly common....older firmwares like L202 and L208 suck.

bottom line:

old firmware L202 and L208= black video with preview channels as of Oct. 2007

you wont easily find this extremely vital tidbit in any of our threads but it appears to be true...at least as of June of this year when I first started hearing warnings about this 061 error code

Still looking for the proper ST19 Atmel flashes (yes both of them not just the 6kb .hex file which shoulkd be only about 2kb in size NOT 6kb) for XPatmel v1.31 serial flashing? So it has to be extrapolated and re-grouped.

looks like I should swap out to Dish Pro and try that next before the eeprom corruption trick and only then if that fails consider dirtyb115 method, which obviosly one would rather avoid.

also,

I forgot that the populated RSA (P&Q) columns could be wiped during a desub command....that is quite correct.

[skinerd]

Another option is to remove the eeprom chip, and put in a jtaggable receiver, then virginize it.
Of all the cips, the eeprom is prolly the easiest to remove and replace.

I have used the shorting trick in 311 cardless receivers, when a password was present, to erase the password.

[sdeens]

ok,

I finished reading that thread about warning 061:

http://www.dssftp.com/forum/showthread.php?t=71882

its the same problem Wildfrog already knew about a year ago and really is NOT a pratical solution for obvious reasons and I will explain why it was never popular even at rom10x when we first tested this circuit.

1. you have to build that special header board using some very obscure IC's, that are NOT common..you will spend about $15-20 in parts after shipping, plus you will have to run a CYGWIN + Hyperterminal emulator to run that e-jtag software.

(as I recall using a Linux kernel under CYGWIN is the only way to communicate with a Broadcomm chip set)

but CYGWIN is notoriously buggy and I have had much trouble running it under WindowsXP-SP2 envirnoments when I tried to do this a year ago...so I abandoned the project since desubs were easy to find.

this is NOT JKEYs guys...

It was a poorly supported project because of these reasons..it wasnt overlly complicated just cumbersome and buggy.

yes it works but its 50/50 at best and your going to spend dozens of man hours building the circuits installing the headers and debugging CYGWIN to erase the bottom half of that flash to allow a stream update to L447 or above on these cardless PVR's

it was about as complicated as it gets in this hobby.

the problem of error 061 is the BLACKLISTING of the unpaid PVR's. account or it was dealer model not for RE-sale...but you get the point...they want these PVR's dis-continued since they know we can NOT easily JTAG them.

I have no doubt that is exactly why they will NOT stream update to L447 from such an ancient older firmware level (i.e L202 or L208)...this is deliberatly being done to phase out the MPEG-2 hardware so people can't legally re-activate them and must therefore purchase a VIP MPEG-4 receiver which has even more security of its Broadcom chip set as I recall reading and is for HIGH DEF which is the future for Charlie.

we anticipated this error 061 almost a year before we observed its effect..I was one of the first beta testers for Wildfrog a year ago when he developed it...I never liked this method..and to me it was strickly for cloning virgins 522/625's and reapairing corrupted TSOPs' and I would only use it if Charlie decides to start to flag them via traditional ECM's.

but this firmware blacklist if changing the need for this device..it ssort of like a soft ECM approach...

I think the problem is still that serial eeprom, because I suspect that is how the blacklist is triggered or managed internally at the IRD and NOT in any part of the TSOP (upper or lower half or even bootsector)....and a serial eeprom is alot easier to re-program in-circuit serially via windows envriroment.

I suspect if we change some code on that eeprom chip and modify/patch our rom103's build configuration and bootstrap data we might be able to circumvent the warning 061 blacklist and force a stream re-load despite them being mis-matched; in fact being mis-matched might be the answer.
'
This was my thought a year ago when I first heard that this might be a problem with future firmwares.

sorry but this method is too just too time consuming but NOT too complicated; nevertheless its NOT the best answer--unfortunalety its the only answer...and I would only consider it if and when they start physically corrupting the botton half of that TSOP with an ECM.

there must be a better solution than erasing half that TSOP with CYGWIN and building that obscure circuit board/header ---:eek:


Mili:

should be thinking ahead here and contracting out an "all-ine-one" header board/E-jtag interface with self-locking pogo pins for the 522/625's UART port.

I have been waiting a year for such a device, but now because of the blacklisting of these PVR's we can't stream update them either...so demand for such a device will pick up for them dramatically in the next 12 calander months to peform this e-jtag erasure method.

it was originally designed for cloning virgins NOT stream updating de-subs..

BTW<

what about the JYF TEST POINTS to force the TSOP low and stream repair while at same time corrupting serial eeprom a pin #3 and #6


there has to be a better way to stream update these PVR;s from oldere firmware then building this goliath.

also it may involve the erasure of the hard drive--a utlity to virginize it might assist in this battle since they can patch code there too to perform the blacklist..I suspect the hardrive is part of this problem.

its great work by Wildfrog but this is NOT what it was intended for...it was for ONLY re-activating virgins and reapir TSOIPs after an ECM--and NOT for stream updating.

the blacklist is changing the demand for this device.

[pecker88]

You don't have to build the "goliath" db25 + db9 header as wildfrog outlines in the LONG thread over at the "unmentioned" site.

Their is a "522jtag part 1" how to over at the fileshop posted by gatekeeper that contains a link to buy an rs232 interface from some robot site. It is like 29 dollars and works well. In addition, you can use any buffered jtag. OR simple jtag.

Once you have these 2 interfaces, you are good to go. Using hyperterm and cygwin together is NO problem either, never got 1 error.

About the issue to blacklisted IRD's...I somewhat agree, and actually hypothesized this a week ago. The particular 522 that was giving the message 061 had a HUGE balance (called dn and confirmed) b/c it was a leased unit that was NEVER returned. Thus, figured that DN had blacklisted the ird/bk's.

However, after more current rev L417 was wrote to the ird, it automatically updated to current revL462 within hours. Therefore, it couldn't have been blacklisted by DN otherwise it wouldn't have updated.


One more thing, tried many of the other methods to try and get this ird to update, and none worked. Tried using ORIGINAL dumped image with NO blocker or intercept with ST19...no go. Tried using this image with rev380 flash...no go. Tried booting the ird w/out the hd plugged in...no go. Tried shorting eeprom pins...no go. No matter what, it would just sit at message 061. ONLY until it had revL417 would it update to current rev!!!

NEways, keep the discussion going, its good to read about newer ird's rather then outdated 27/28/39xx ird's!!!

[sdeens]

I think I know EXACTLY why it updated after you did this modification to the TSOP:

this was the same approach they used when they stopped supporting 4-5 years ago or streaming the full 100% of the bootstrap for the old grey box 3000/4000 recievers and later to some degree for the Dishplayer 7100/7200's. even the JYF did NOT work or update or repair these receievers via the stream...they occasionally would lift the BUILD CONFIG blacklist or filter to allow the firmware to go thru to their legit GREY BOX 3000/4000 accounts..but the stream reports I read indicated it was a hit or miss approach and only occured for a few days each year. Once you got it updated, it would then take normal stream updates a few times per year during the hit or miss "window of opportunity" as we called it as lonbg as the BUILD CONFIG/bootstrap was current.

so the WARNING 061 is exactly what I was expecting when I read they were pushing hard to replace the PVR522/625's with the new VIP recievers that support their emerging MPEG4 market. I figured they would start doing a BUILD CONFIG/Bootstrap check to stop the re-activation of the cardless 1st generation 522/625 receivers that only supported MPEG2...and execute a filter check from that point forward.

its the emergence of MPEG4 VIP fleet that is causing this problem with Warning 061. Its a deliberate filter/blacklist attempt against those older firmwares...first observed in June from the stream reports I saw.

its easier for them to flag such cardless receivers since we can NOT clone them easily or erase the hardrives properly to virgin status or virginize the serial eeprom in-circuit via JKEYs in Windows environment. I have found these cardless OEM HDD's are much harder to format in Windows XP BTW then the older PVR's like 501/508/510.

What is the best utility now to erase or format the cardless 522/625 HDD's in a windows environment?

they may be flagging one byte in the first few addresses of the serial eeprom when the PVR522/625 gets the "de-sub command" which contains the BUILD CONFIG/Bootstrap data; thus acting as the screening tool for the firmware PID's auto-load detection mechanism. This also could be coupled with code on the hardrive for addtional security to prevent firmware updates...this was problem for some of the 7100/7200's when people upgraded their hardrives to larger ones...so they had to be first exteranally virginized to get them recoignized by the firmware at the time.

this was talked about at great length by SatFTA when he was a member of ID...and its looks like this is a similar approach they used on the GREY BOXES and now on the early de-subb'd 1st generation cardless IRD's

same thing is happening here--technically its NOT a blacklist of CAM ID's or IRD #'s, but a filter blacklist against the data store in the serial eeprom (or wherever they put it) for that units particular outdated build config/bootstrap code..

this is why the problem probably can be solved more simply by virginizing that hardrive and virginizing the serial EEPROM or spoofing the BUILD CONFIG on the eeprom and the rom103 simulatenously with virignized HDD or maybe just by physically removing that EEPROM chip it after being installed into a model 2700 using JKEYs. to eerase the chip...socketed of course for easy removal.

shorting pin #3 and #6 wont virginze that serial EEPROM and the TSOP's firmware is probably coded now to ignore this old trick we used to get around the streamload PID mechnism.


Did you simply try to lift pin #3 or pin #6 of the U23 serial EEPROM to see if its removal or disabled status might trigger a stream reload--that was another trick?

...also maybe using lower case letters again might help...that's an old trick too...

I will check into that $28 RS232 interface to see what its all about:
http://www.superdroidrobots.com/shop/item.asp?itemid=337&catid=41

but that's a big time saver and I think I will get it and give it a shot...I have three(3) of these PVR522/625's in the same situation.

What we really need is an ALL-IN-ONE buffered E-JTAG/RS232 interface for these cardless wonders..no doubt such a tool will have enormous value with these Broadcaomm based VIP 622's later this year

I hope MILI is reading this, because this is the ALL-IN-ONE E-JTAG tool with self locking UART port-pogo pins for cardless IRD's will be a big big seller. I have been waiting for a year now.

Also, does this Wildfrog method also now READ the U23 serial EEPROM so we can examine the raw dump for build config/bootstrap code and does it allow in-circuit reflashing of this chip via CYGWIN and Hyperterminal?

That was problem a year ago when he first devloped it as I recall..I'm wondering if he figured out how to trap in-circuit now the serial EEPROM too.

[pecker88]

somewhat of an addition to the topic:

Just pulled a rev382 bga from a 522 at fw rev L239. Unlocked the bga and put on board. Re-activated the ex-sub image, added 50+ tiers, and b2kill blocker.

PUt in ird did check switch and got video. Turned off all tuners and the ird updated to current rev L461 within 10 minutes.

Guess fw L239 updates and L202 doesn't...figure that one out!!!

[sdeens]

nope,

that's exactly as expected...when firmware gets to be about 2.5 years old its no longer supported via stream updates...this is deliberate...they seem to have a rigid time table for each model receiver...and 2 years has been a good rule of thumb to live by.

your L239 is newer than 2.5 years old and still falls within the window of opportunity for normal stream updates...

in another 4-6 months it wont update at all from that level....

its a simple time equation seen this many many times before.

also I ordered that RS232 interface.....I have many PVR522/625's with much older firmware than even L239....its a crazy cumbersome hack but its the best we can do sadly.

hint:

for those thinking ahead and own a high def. PVR921/942 you better get them stream updated very soon, especially for those who own one that has been in a closet for the last 12 months waiting for a rev 389/38B unlocker (which still has not been released--even privately). Your window of opportunity to stream update these high def PVR's is quickly running out...especially since Charlie knows that unit is still NOT fully hacked and he is spooling rev10C for the rom102's..the next update for rom103's will be an even tougher to crack..

and as far as I know Wildfrog did not own any of those units (including the 811's) and has not tested them for his clone method either...at least as of 1 year ago when he developed the hack for PVR522/625's..this may have changed but I don't see evidence of it it anywhere...even our file shop has no TSOP-BGA support for the PVR921/942's

so what you saw is normal and fully expected.