Here's the latest, as previously stated by ex67, and copied directly from another site (which I can't name according to MJ's rules, just don't get the wrong idea and think I figured this s**t out myself - hell I can't figure out who's gonna cover a basketball game).
Preliminary analysis is in. Here is a copy and paste of RAM9999's post:
"Preliminary findings:
The location of C9 Dynamic code was moved from 893C to 8924 (USW64)
The allowable length of a C9 was increased from 17 bytes to 21 allowing for longer, more complex C9 packets (USW65)
A bug in CmdEF which allowed for packets longer than the card could handle was fixed by USW66.
USW67 added a new hash routine at the old C9 location which accepts a starting address and a # of bytes and then stores the result of the XOR hash back in RAM.. This routine is presumably to be called by some new, upcoming C9's and can be used to implement easy, rotating, dynamic hashing of DPBB's and range-comparison ECMs"
From what RAM9999 is saying, this could potentially be the end of hacking with Bootloaders. In the past, it was possible to work around ECM's with the bootloaders by loading special 3Ms. Now, however, it is highly likely that DTV/NDS will use these new changes to randomly hash different bootloader areas and various other parts of the card.
In English, this means that if you are currently running a card inside a bootloader with some sort of code/hack on it, it will probably lose video in the days to come. These latest updates are just more "tools" for DTV/NDS to use against that particular type of hack, and they will undoubtedly pull them out of the shed in time.
Before a flood of people start to ask...YES: emulation setup's with AUX cards inside bootloaders should not be affected by this. This is not necessarily a "bootloader attack" but more properly a "bootloader outside of emulation attack."
Please note: all references to any sort of hashing, attacks, etc. are speculation on the part of several people (myself included). For the record, no harmful action has physically taken place yet, although the stage has been set.
Many people have been claiming to have received emails / warnings about a CMD78 in the stream. These "warnings" were in fact just false rumors intended to stir things up I guess, making newbies think there was some kind of ECM coming soon.
Here is a direct quote from RAM9999 as posted in ????????????.com:
"Man, this B.S. is everywhere... I suppose you heard something about "Cmd78's"??
First - there are no Cmd78's in the stream..
Second - even if there were, Cmd78's are NOP's on both the H and HU (as in they don't do anything)
Whomever started this rumor has no clue how to read a packet"
Who would start such a rumor? Well, it's really anyone's guess. If you see a web page that advertises blocker boards that protect against CMD78's, though, you might want to think twice before buying it
RAM9999 is one of the leading edge guys in DSS hacking. Whoever he is, he is an absolute genius in this area.
Skinar
Preliminary analysis is in. Here is a copy and paste of RAM9999's post:
"Preliminary findings:
The location of C9 Dynamic code was moved from 893C to 8924 (USW64)
The allowable length of a C9 was increased from 17 bytes to 21 allowing for longer, more complex C9 packets (USW65)
A bug in CmdEF which allowed for packets longer than the card could handle was fixed by USW66.
USW67 added a new hash routine at the old C9 location which accepts a starting address and a # of bytes and then stores the result of the XOR hash back in RAM.. This routine is presumably to be called by some new, upcoming C9's and can be used to implement easy, rotating, dynamic hashing of DPBB's and range-comparison ECMs"
From what RAM9999 is saying, this could potentially be the end of hacking with Bootloaders. In the past, it was possible to work around ECM's with the bootloaders by loading special 3Ms. Now, however, it is highly likely that DTV/NDS will use these new changes to randomly hash different bootloader areas and various other parts of the card.
In English, this means that if you are currently running a card inside a bootloader with some sort of code/hack on it, it will probably lose video in the days to come. These latest updates are just more "tools" for DTV/NDS to use against that particular type of hack, and they will undoubtedly pull them out of the shed in time.
Before a flood of people start to ask...YES: emulation setup's with AUX cards inside bootloaders should not be affected by this. This is not necessarily a "bootloader attack" but more properly a "bootloader outside of emulation attack."
Please note: all references to any sort of hashing, attacks, etc. are speculation on the part of several people (myself included). For the record, no harmful action has physically taken place yet, although the stage has been set.
Many people have been claiming to have received emails / warnings about a CMD78 in the stream. These "warnings" were in fact just false rumors intended to stir things up I guess, making newbies think there was some kind of ECM coming soon.
Here is a direct quote from RAM9999 as posted in ????????????.com:
"Man, this B.S. is everywhere... I suppose you heard something about "Cmd78's"??
First - there are no Cmd78's in the stream..
Second - even if there were, Cmd78's are NOP's on both the H and HU (as in they don't do anything)
Whomever started this rumor has no clue how to read a packet"
Who would start such a rumor? Well, it's really anyone's guess. If you see a web page that advertises blocker boards that protect against CMD78's, though, you might want to think twice before buying it
RAM9999 is one of the leading edge guys in DSS hacking. Whoever he is, he is an absolute genius in this area.
Skinar