No_PaRoLe
08-29-2007, 04:56 PM
C/P
Guys we have a wide scale problem with this update. you'll see once they activated it. this update turns on dynamic code like the old Dave USW63 did.
Basically BV is going to send 1024bit command07s that have the keyselect and provider ID morphed so loggers don't catch it right away. The code at 60DB demorphs this to the proper bytes.
But there is going to be dynamic code inside the command07 that gets decrypted and stored at 0100. this cod MUST GET EXECUTED. in order for it to come up with a good checksum/seed and then it passes on to SHA-1. All map calls are riddled on this new update except for sha-1.
Now for the fun part: the decryption of the dynamic code takes place using a 2 new IDEA Keys stored in dataspace. so instead of having 2 ideas keys, we are gonna have 4 now.
2 06 and 46 keys like before, and 2 NEW 07 46 and 0706 keys used to decrypt the dynamic code inside the command07.
Here is the bad news: this key will likely be passed to the cam using EMM-S on a subbed cam like the NFL keys were last year. that means that only paying sub bins will receive the new keyrolls for the 07xx keys. This isn't good as a public community.
The second part is the dynamic code buffer at 0100. they could sneak anything there. they could sneak in OTP checks for marks and stuff like Dave did for the BSH.
The OTP mark on BS h was used to get the control words, and you froze up if you used a BS H card. i expect b*v/d*sh to do the same with 3060/61.
Also in the 0100 buffer most likely is going to be new map calls for data manipulation of the seed required to fix up the control words. And they can xor against anything in eeprom. also they can xor against a known byte for a blocker, and loop the cam using the dynamic code.
You cant block the dynamic code, or you wont get video, you have to let it run. this is going to mean more looped cams like Dave.
This is not looking good folks. not at all. one last thing: they check 3054 for a proper provider mark. if not present, or invalid you get no video. So you'll have to mod the codespace for this little issue, but then again, they can send dynamic code down to "hash" or check for this mod, and if you modded it, you get no video because you don't get the right keys.
so here comes BACK the days of cloakers. and down every week with freezing/005 shit.
---------------------------------------------------
later...
Its not that I'm trying to scare you, actually I'm not trying to scare you. I'm only stating what me and the other coders are discussing/seeing.
More is still yet to be known. but as it unfolds, its going more and more like Dave's old tactics every day.
Meaning you'll have to have a valid subbed bin to get TV. like Dave.
you'll have to have cloakers. like dave.
Blockers will no longer have any meaning anymore. like Dave.
FTA is gonna be dead unless they emulate full SFR/Map and all registers/rom calls. because the dynamic code could change to anything at any point in time. its gonna be a up down up down event on FTA to say the least.
The only thing thats gonna stand a chance outside of plastic is the armulator. armulator is full blown emulation except for maps/SFRs. It emulates all opcodes, and emulates eeprom/rom and all of its addresses. It runs ST19 code as if it were native. so if you emulate the SFRs properly, and know enough about map, arm has a good chance to stand up, as you can run an arm blocker-less and set OTP however you like so the dynamic code don't bark at you.
As far as atmegas, and other boards, they ain't gonna stand a good chance at all, because the Atmega and the enigma/etc etc are partial emulators. They only emulate and handle commands. they don't run ST19 code native. at least not to my knowledge. so thats gonna make things really difficult for the Atmega until an ST19 core native emulator is coded.
And i also forgot, CEMU and the like will stand a chance, because they all use address/native code emulation like the armulator..
END C/P
Guys we have a wide scale problem with this update. you'll see once they activated it. this update turns on dynamic code like the old Dave USW63 did.
Basically BV is going to send 1024bit command07s that have the keyselect and provider ID morphed so loggers don't catch it right away. The code at 60DB demorphs this to the proper bytes.
But there is going to be dynamic code inside the command07 that gets decrypted and stored at 0100. this cod MUST GET EXECUTED. in order for it to come up with a good checksum/seed and then it passes on to SHA-1. All map calls are riddled on this new update except for sha-1.
Now for the fun part: the decryption of the dynamic code takes place using a 2 new IDEA Keys stored in dataspace. so instead of having 2 ideas keys, we are gonna have 4 now.
2 06 and 46 keys like before, and 2 NEW 07 46 and 0706 keys used to decrypt the dynamic code inside the command07.
Here is the bad news: this key will likely be passed to the cam using EMM-S on a subbed cam like the NFL keys were last year. that means that only paying sub bins will receive the new keyrolls for the 07xx keys. This isn't good as a public community.
The second part is the dynamic code buffer at 0100. they could sneak anything there. they could sneak in OTP checks for marks and stuff like Dave did for the BSH.
The OTP mark on BS h was used to get the control words, and you froze up if you used a BS H card. i expect b*v/d*sh to do the same with 3060/61.
Also in the 0100 buffer most likely is going to be new map calls for data manipulation of the seed required to fix up the control words. And they can xor against anything in eeprom. also they can xor against a known byte for a blocker, and loop the cam using the dynamic code.
You cant block the dynamic code, or you wont get video, you have to let it run. this is going to mean more looped cams like Dave.
This is not looking good folks. not at all. one last thing: they check 3054 for a proper provider mark. if not present, or invalid you get no video. So you'll have to mod the codespace for this little issue, but then again, they can send dynamic code down to "hash" or check for this mod, and if you modded it, you get no video because you don't get the right keys.
so here comes BACK the days of cloakers. and down every week with freezing/005 shit.
---------------------------------------------------
later...
Its not that I'm trying to scare you, actually I'm not trying to scare you. I'm only stating what me and the other coders are discussing/seeing.
More is still yet to be known. but as it unfolds, its going more and more like Dave's old tactics every day.
Meaning you'll have to have a valid subbed bin to get TV. like Dave.
you'll have to have cloakers. like dave.
Blockers will no longer have any meaning anymore. like Dave.
FTA is gonna be dead unless they emulate full SFR/Map and all registers/rom calls. because the dynamic code could change to anything at any point in time. its gonna be a up down up down event on FTA to say the least.
The only thing thats gonna stand a chance outside of plastic is the armulator. armulator is full blown emulation except for maps/SFRs. It emulates all opcodes, and emulates eeprom/rom and all of its addresses. It runs ST19 code as if it were native. so if you emulate the SFRs properly, and know enough about map, arm has a good chance to stand up, as you can run an arm blocker-less and set OTP however you like so the dynamic code don't bark at you.
As far as atmegas, and other boards, they ain't gonna stand a good chance at all, because the Atmega and the enigma/etc etc are partial emulators. They only emulate and handle commands. they don't run ST19 code native. at least not to my knowledge. so thats gonna make things really difficult for the Atmega until an ST19 core native emulator is coded.
And i also forgot, CEMU and the like will stand a chance, because they all use address/native code emulation like the armulator..
END C/P