The 285 is an improvement over 284. it is currently available only in the PUFF boot version. The following URLs will get you all that you need to convert or to just install a 284 or 285 BIN for your old 2500 or FLU.
[link removed]
[link removed]
[link removed]
Please read the instructions properly in the section you have chosen. PLEASE DO NOT ATTEMPT WITHOUT READING INSTRUCTIONS.
There is a a DIY method for converting and installing any of the 2700 group of receivers, i.e. genuine 2700, clone 2700 and converted 2700. [link removed] This has been developed by Tronic
You will need the latest genuine Pansat 2700 284 BIN from: http://www.future-fta.info
made a few adjustments..reset default, left DN and Bev autoroll on...used JVVH 285....back on on both...so far no freezing, but Bev seems to be aggressive lately in morphing so if you want a more stable platform yet less desirable channels selections, use DN
Hey psychmonster How are yo? Please tell my friend Plymouth what 2 streams are Yo have been here long enough to know He's new and some how thinks I'm making this up
Thanx Mon This is the link of the discussion https://www.ecoustics.com/electronics/forum/home-video/508270.html
Sorry for the hijacking I will delete within an hour
there are some different variations of the two stream from providers...one is the audio on one stream and visual on another, this is old school and coders have to put them both together for a compleat feed...another is Providers use a scrambling program that has variable encoding, the variable encoding controls the scrambling and de-scrambling, these are that we call "KEYS". These keys are indivually changeable by the provider and are kept in the receiver in sets of two or more. There are always 2 or more SETS of keys, that the provider can change individually, and only one key that is the "active key". The "Active key" is the one that is currently used to de-scramble the data stream. The secondary or "Non-active keys" are held in reserve by the provider and the provider can switch his subscribers to one of the the secondary set of keys through the data stream. The early FTA receivers were originally designed for manual key entry, as the providers key change was infrequent, and the FTA receivers required only a small amount of memory to accommodate this. However as a part of the providers security scheme they started more frequent key changes and manual FTA key changes became more frequent and problematic. To accommodate the more frequent key changes, and convenience, the FTA coders incorporated in their programs a automatic key change sub-program that we know as "Auto roll". Auto Roll, is incorporated into the program (.bin/.pgm) that we down load into our receivers, its function is to detect a key change, and then (Auto) roll the keys until the receiver decodes the data stream, and we get our video/audio. Currently "autoroll" is a necessity, no longer a luxury. All of the current FTA receiver programs have the autoroll feature....actually the providers may eventually send audio and visual in two different encryption modes...already been tried and defeated...they need to recall all of their boxes witch will cosat 500,000 mill and get rid of Nagra and use a new encrytion ...they cannot afford it so we will be watching tv for the for forseeable future...all they got is the mosquito in the room...pisses u off for a day or two and then sqauch it...ps...Nag 3 hase been cracked already, and the contract is so expensive to the providers that use it, they have no place else to go
With every ECM there is always a fair bit of misinformation about regarding the "new" encryption techniques used, and how it may portend the death of FTA.
With the present difficulties, for instance, the following items of interest have been repeated around the net on various sites:
* This ECM is specifically targeted at FTA * Multiple MAP call are being used * A dynamic code is being used * There is a new timer function
This ECM is specifically targeted at FTA
This is likely true! Card based hacks like plastic, card-sharing, and IKS (Internet Key Sharing, another form of card sharing) access video encryption differently than the emu in FTA firmware. Card solutions simply send encrypted VPID (video packets) to the descrambler chip where the included CW (control word) packets are sent right away to the CAM (conditional access module/card), the answer is sent back and then applied to the video packet. The actual CAM values, apart from definitions and order of the CW gathering commands (i.e., MAP calls) need not be known, as it is all done automatically when requests are sent to the card. FTA firmware on the other hand must know the precise CAM locations and thus order and routine of MAP calls, and this has to be patched into each bin; when this changes a new bin is required where relevant portions of the CAM are emulated.
Multiple MAP calls are being used
This is true, however this is nothing new either. Providers routinely use at least 4 or 5 MAP calls at any given time. MAP calls are intense arithmetic equations that request CWs from the CAM to be sent back to the descrambler. We now have 4e and 4d; there are others in play, but apparently these particular ones are the difficulties (i.e., CAM location unknown).
A dynamic code is being used
"Dynamic" implies changing according to some input. It sounds scary, like a mutating virus, lol. In actuality, "dynamic" is little different that "random" at the level of intense mathematics as the functions and outputs are extremely difficult or impossible to be predicted. By definition, control words are random numbers.
There is a new timer function
Each channel uses different CWs, and this is how now for instance some locals may be viewable and other pay channels remain scrambled. CWs change every few minutes, and this in itself is as secure as practically can be: even an NSA super-cryto computer could not solve an 8-byte algorithm in 2 minutes, lol. CWs have always changed this fast, and all TV providers, even cable, use the same system.
So what is going on?
Nothing radically new, likely. Coders are not crytologists, and even if they were, it would be senseless to attempt decryption on something that changes as quickly as CWs, as mentioned above. And neither can card data be read with any apparent ease (remember all the baloney a year ago about peeling the cards and reading with an electron microscope, hahahahaha, if you believed that one, well, I have some bog land you may be interested in....). Some CAM locations are known, some are not. ALL of the MAP calls CW answers are currently in the cards and are not changeable, this requires a card swap. What can be changed are the specific MAP calls and their order. These can be read and defined, and even used for card hacking (why IKS is up and running), but FTA is a different story, as mentioned.
Coders must be given specific CAM locations which can be patched into or emulated for FTA binary files. Saying a bin has the "full emu" is ridiculous, as it can't by sheer size limitations, as it would have to run in non-decompressed format. What is needed is a MAP map, as it were, lol. Or at least someone to give directions, like a navigator.
Most of this information is purchased rather than hacked, at least initially. When a group says they have the "full emu", what should be understood is that they have access to the information, and it may be purchased as a service over a period of time. This is rather like calling up customer service plan: you call to say your widget isn't working, and being told to press buttons 1, 2, 3, then A, B, C in that order, you do, it works, but you have no idea why. It seems Viewsat had an arrangement like this after MAP57, they bought a 1 year plan, lol. Others can purchase information on a one-off basis. Or once a bin is released, the bin can be dumped and reverse engineered for patching to different boxes, but this takes a little extra time.
DN PID 0106 keys... and Bev PID 0907
DN has introduced a new secondary key code and provider PID 0106...the usual main PID (Provider ID) is 0101...normally we change the keys and autoroll to keys 0101, which we must ALWAYS still keep updated and current...but with this new PID (intoduced originally 22 October) we cannot change these keys, and the autoroll doesn't input them, so a NEW bin is required whenever DN changes the keys in PID 0106...The new PID can be used on any specific channels that DN want to , so in many cases DN will input them on the PPV's, adult channels,and international channels..so that why U can get the regular channels with the older bins, but need a new bin for the channels that DN uses the new PID 0106 keys now...
The same thing applies to Bev PID 0907 secondary keys..****ually main active Bev keys are 0901, NOT 0907...but Bev can use either or both sets of keys 0901 or 0907....just like DN can with main active keys 0101 and secondary new 0106 keys now..ON ANY CHANNNELS THEY CHOOSE, WHENEVER THEY CHOOSE..OR ALL CHANNELS, IF THEY WISH..
AT THIS POINT IN TIME, U CAN NOT MANUALLY INPUT THESE SECONDARY DN 0106 AND BEV 0907 KEYS MANUALLY INTO FTA RECEIVERS..AND REQUIRE NEW FIXES...BUT SHOULD GET SOME CHANNELS UNLESS THE SECONDARY KEYS ARE APPLIED TO ALL CHANNELS... __________________