Hi lads
Been a long time since my visit here and i must admit whilst googling for something else i have stumbled across this old topic....
Ok so first things first...
1- as we all know or most of us do know, there was some features added along the years on the kudos stuff
One of them was the chipset hardware key protection, it means that a new feature on the card and STB cpu side was enabled/activated this feature is mainly used for CW(control word protection) its basically a key stored inside the CPU decrypted that will do the last step decrypt process on the CW returned from the card. After stb side cw decryption with session key, the output cw instead of being forward to the a/v descrambler it still encrypted with 3DES and it needs to be decrypted with 3des key stored inside the CPU. which means the same 3des key stored inside the smartcard was used to encrypt de cw on card side also.
2- as you know there are several types of CPU and each core has its own functionality some old core and some new core..
Normally new core type cpus already contain a new block stored in the STB flash firmware also known as block 0097xxxxxxxxxxxxxxx this block contains the CPUID+cputype architecture+provider id+8 keys encrypted.
this 8 keys are the full key table that will be used on the cpu after decrypted ofcourse on the cpu, the output plain result of this keys will be used to decrypt the control words on the final stage.
3- but on older core versions like sti7105 and few others, there is no 0097block stored on the flash firmware so in this case the CA vendor and provider use a new CAID famously known as CAID 18FE this CAID broadcasts a smaller EMM that contains the encrypted 3DES key inside, this EMM contains the CPUID with bytes inverted ofcourse + encrypted key.
this encrypted keys are then sent to the CPU and decrypted with another Master ROOTKEY inside the CPU. and will output the final 3des CW key and store it on another area of the CPU and there it will be stored to be used on the next incoming ECM from the smartcard side..
as for the new generation with 0097block this keys are not sent via CAID 18FE , but at the CPU STB init the selected key from the block is sent to the CPU and also decrypted with the CPU rootkey, and also the same output decrypted result is then stored on another address of the CPU and will wait for the encrypted CW to be sent from the card also.
So the CAID 18FE is known in the real CAK lib terms as the OTA CSC "Over The Air Chipset Secure Core" and the 0097 block on the flash firmwrae is also known as the OTP CSC "One Time Programmable Chipset Secure Core"
But its allways good to remind of something aldo new core uses the 8 subkeys stored on the block, if provider wishes they can also update new key over OTA CSC meaning they will stop using the keys on the block and use newly update key over the air if they want.
So with that said we know that only options available are 2 options
1- glitch the card , and disassemble the actual code inside the card that generates this 3deskey based on the CPUID+extra data from provider ID stored inside the card
2- Glitch the CPU on the stb and access the CPU to read the plain 3DES key stored inside the CPU and then use it on the EMU side. but again if you do the second option it means u have no access to the card.
but if you are a real geek genious that know how to glitch the smartcard why bother spending time finding how the 3des key for cw overencryption is generation and not move straight into the full ECM , Decrypt keyset to decrypt CW directly on Emulation..
So we know now how to decrypt the 016c block , also how to invert swap bytes of some CPU types sh4 which people call block 9882 , its nothing more then a simple byteswapping BGA programmer machine dump reading.. on the flash which in the end will become also 016c and appply same IDEA algorithm decryption..
again for the 3DES key (nagra generates this key inside the smartcard on boot of the STB/CARD pairing process)thats why they send on new cmd$2a the cpuid of the STB that the card will be running...by receiving from the STB the cpuid on the cmd2a sent to the card.. +provider id and some extra data stored on the card side this will produce the correct plain 3des key.
on the CPU side this key is stored either on the flash block 0097 or sent via EMM but ofcourse this key is encrypted with another secured hw key inside the cpu. so this key will only be decrypted inside the correct CPU with the correct CPUID.
Maybe who knows if some have fully reversed all the map functions on the rom110 maybe... just maybe there could be some hints on how this 3DES key is generated on the RAM side of the smartcard.. and if we send to the card a different CPUID the card will generate a new 3des key on the smartcard RAM that will match the CPUID new sent....
so yeah basically thats what is happening the new secure Hardware chipset feature is nothing more then ......
1- on smartcard init there is some code + input data CPUID +Provider ID sent from STB side on cmd2a to generate the 3des key , this 3des key encrypts the CW extracted previously from the ECM
2- STB side it contains unique master key on each STB cpu that will decrypt the encrypted 3DES key matching to that STB cpuid number, and after decryption of the e3deskey the final result 3des key will be 100% macthing the same key generated on the smartcard side using the same CPUID sent from STB to the card.
ofcourse there is also a new system (not so new around 6 years old) called merlin
its a new complete pairing mechanism used on some providers with new ROM Cards. this does not involve IDEA session key neither IDEA session key instead uses another algorithms and alot more keysets for pairing structure , the ECM structure is also different and EMM also.
and if this was not enough they also applie the Chipset hardware pairing feature enabled which means after doing all new pairing card/stb init, they still have to deal with the same CW 3des key protection mechanism which works exactly the same way
so we have CAK6 and 6.3 aladin which uses normal cmd2a/2b cmd26/27 with idea session key + 3des cpu key pairing cw
and we have new CAK7 and CAK7.5 merlin pairing mechanism that also contains as extra features 3des cpu hw pairing, but one thing they can also share in common the same 016c block which contains extra keys not used on the cak6.3 but might be used on cak7
Hint => So going back to the main conversation of the topic, if you have 1 3deskey+paired cpuid decrypted for one specific provider, you can use this key for all other cards from the same provider companie. because the cards from same provider when u send the same CPUID on CMD2A for all the cards from the same provider this cards will generate the same 3des key inside of all the cards, this key will then encrypt the CW and forward the cw encrypted to the STB, so if the EMU software contains the same CPU+3deskey it will decrypt the cw sent from the card correctly on all the cards from the same provider with the Same CPUid sent on cmd$2a