How Do I Crack Satellite and Cable Pay TV?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 147 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/43867 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
00:00
Chief information officerDifferent (Kate Ryan album)EncryptionPay televisionStandard deviationInsertion lossHecke operatorComputer animationLecture/Conference
01:05
Physical systemConditional probabilityComputer wormGotcha <Informatik>Turbo-CodeVorwärtsfehlerkorrekturVideoconferencingFile formatStreaming mediaEncryptionDigital signalStandard deviationDigitizingHacker (term)Information securityComputing platformGame controllerPhysical systemOperator (mathematics)Set-top boxComputer hardwareDescriptive statisticsMereologyMultiplication signReverse engineering1 (number)Turbo-CodeVariety (linguistics)Single-precision floating-point formatInternet forumLecture/Conference
02:11
Turbo-CodeGotcha <Informatik>VorwärtsfehlerkorrekturStreaming mediaDigital signalStandard deviationVideoconferencingFile formatEncryptionDescriptive statisticsElectronic program guideStreaming mediaCuboidType theoryModule (mathematics)Tunis1 (number)Variety (linguistics)FirmwarePay televisionSoftwareFile formatComputer hardwareMusical ensembleInformationComputer programmingFrequencyDigital video recorderData managementState of matterLecture/ConferenceComputer animation
03:08
Computer wormTurbo-CodeVorwärtsfehlerkorrekturStreaming mediaDigital signalStandard deviationVideoconferencingFile formatEncryptionTable (information)Error correction modelElementary arithmeticInformationComputer programPrincipal ideal domainAssociative propertyConditional probabilityVideoconferencingStreaming mediaFile formatComputer hardwareSoftwareEncryptionPhysical systemStandard deviationTable (information)InformationPrincipal ideal domainType theoryLengthCyclic redundancy checkService (economics)Computer programmingAssociative propertyFehlererkennungDisk read-and-write headRadio-frequency identificationBitLevel (video gaming)Heat transferExtreme programmingHacker (term)Elementary arithmeticDifferential (mechanical device)Electronic mailing listDifferent (Kate Ryan album)Lecture/ConferenceComputer animation
04:12
Service (economics)InformationTable (information)Elementary arithmeticVideoconferencingAssociative propertyPrincipal ideal domainComputer programConditional probabilityError correction modelStreaming mediaAssociative propertyComputer programmingPhysical systemTable (information)Electronic mailing listPrincipal ideal domainStreaming mediaError correction modelType theoryLevel (video gaming)InformationGame controllerKey (cryptography)Message passingElementary arithmetic40 (number)Condition number1 (number)Pay televisionNumberSet (mathematics)Bit rateCuboidData managementComputer animationLecture/Conference
05:01
Table (information)Error correction modelInformationElementary arithmeticVideoconferencingComputer programAssociative propertyPrincipal ideal domainConditional probabilityStreaming mediaCase moddingInterface (computing)Principal ideal domainSet (mathematics)Data managementTable (information)Pay televisionBit rateProcess capability indexSet-top boxMessage passingComputer hardwareTurbo-CodeLink (knot theory)Device driverSlide ruleModule (mathematics)Patch (Unix)Asynchronous Transfer Mode
06:01
Interface (computing)Variety (linguistics)Adaptive behaviorInterface (computing)CuboidComputer hardwareTotal S.A.Pay televisionService (economics)InformationHeat transferStreaming mediaSystem programmingFunction (mathematics)Table (information)Lecture/ConferenceSource code
07:12
Service (economics)InformationMusical ensembleDigital signalTable (information)Standard deviationVirtual realityComputer networkElectronic program guideAssociative propertyEvent horizonEquivalence relationUncertainty principleFile formatElectronic program guidePhysical systemVirtualizationTable (information)InformationStandard deviationOcean currentComputer programmingSystem programmingMappingStreaming mediaNumberPlastikkarteSet-top boxCuboidSoftwareModule (mathematics)Interface (computing)Observational studyPrime idealComputer animationLecture/Conference
08:19
PlastikkarteFunction (mathematics)PlastikkarteModal logicSoftwarePrime idealInterface (computing)Software development kitLogikanalysatorLogicStreaming mediaRandomizationConnected spaceFunction (mathematics)Randomized algorithmStandard deviationElectronic program guideError messageCondition numberData managementInformationMessage passingBitLecture/Conference
09:21
SoftwareTelecommunicationSet-top boxAbelian categoryKey (cryptography)EncryptionFrame problemCountingComputer programGUI widgetError correction modelMessage passingProcess (computing)Electronic meeting systemAuthorizationData Encryption StandardEvent horizonData storage deviceKey (cryptography)BitSystem programming2 (number)Computer programmingEncryptionStreaming mediaExterior algebraCountingFrame problemCASE <Informatik>Data Encryption StandardResultantEvent horizonCategory of beingMessage passingSet-top boxInternet service provider40 (number)MathematicsComputer animationLecture/ConferenceSource codeProgram flowchart
10:27
Data Encryption StandardKey (cryptography)CountingFrame problemError correction modelComputer programElectronic meeting systemEvent horizonData storage deviceSet-top boxProcess (computing)GUI widgetStreaming mediaCategory of beingData Encryption StandardEvent horizonOperator (mathematics)Computer programmingKey (cryptography)Set-top boxSet (mathematics)Order (biology)Form (programming)Streaming mediaEncryptionChainMultiplication signMessage passingDegree (graph theory)CuboidBitDivisorRing (mathematics)Computer animation
11:28
Power (physics)Game controllerZugriffskontrolleCoprocessorComputer wormHeat transferGame controllerPhysical systemVideoconferencingStreaming mediaProcess (computing)Serial portConnectivity (graph theory)CuboidContent (media)Function (mathematics)Bus (computing)MicrocontrollerSet-top boxCAN busInternet service providerArithmetic meanMessage passingPlastikkarteInformation securityNetwork topologyPoint (geometry)TunisLecture/Conference
12:38
Set-top boxStreaming mediaMicrocontrollerGame controllerPower (physics)Arithmetic meanDigital photographyComputer programming2 (number)InformationMessage passingFlow separationMotherboardPhysical systemNon-volatile memoryFrequencyFirmwareElectronic program guideQuicksortCuboidHeat transferLecture/Conference
13:25
Computer wormoutputStreaming mediaSystem on a chipEncryptionInformation securityRevision controlDigital photographySet-top boxCuboidVoltmeterContent (media)Personal identification numberGame controllerTelecommunicationComputer animation
14:20
EmoticonStreaming mediaoutputStreaming mediaFunction (mathematics)Set-top boxContent (media)Game controllerPersonal identification numberEncryptionSerial portTelecommunicationoutputSoftwareImplementationBit ratePoint (geometry)BitHeat transferPeripheralObservational studyInsertion lossComputer programmingDigital electronicsArithmetic meanLimit (category theory)Message passingComputer animationDiagram
15:27
Raw image formatTablet computerGame controllerComputer wormPeripheralMountain passSet-top boxDependent and independent variablesInternet service providerAbelian categoryElectric currentEncryptionAsynchronous Transfer ModeAddress spaceExecution unitPay televisionComputing platformInterface (computing)Bit rateStreaming mediaFunction (mathematics)Computer programmingCuboidPoint (geometry)Control flowHeat transferOpen setWordFile viewerSet-top boxWhiteboardGame controllerBus (computing)MassSoftware developerArithmetic meanNumberoutputPay televisionInformationDirection (geometry)TelecommunicationMultitier architectureKey (cryptography)Address spaceExecution unitCategory of beingOcean currentMessage passingSerial portCASE <Informatik>Level (video gaming)Metropolitan area networkDreizehnTraffic reportingAuthorizationLecture/ConferenceComputer animation
17:41
Dependent and independent variablesInternet service providerAbelian categoryElectric currentAddress spacePay televisionObservational studyBus (computing)Category of beingSet-top boxKey (cryptography)Game controller10 (number)QuicksortProjective planeHypermedia
18:43
ACIDMereologyGoodness of fitProfil (magazine)Level (video gaming)Process (computing)UltrasoundCalculationLecture/Conference
19:47
Data structureMereologyMedical imagingGraphics tabletPlanningLogicGreatest elementSemiconductor memoryType theoryDigital photography
20:37
ACIDVaporMusical ensembleDirected graphMaxima and minimaConvex hullEmpennageDilution (equation)Product (business)LiquidResultantMereologyACIDSurfaceDigital photographyMultiplication signBitSound effectLecture/Conference
21:30
Sound effectPlanningBlock (periodic table)RectangleProcess (computing)LogicAreaRight angleMultiplication signBitDigital photographyAdditionPoint (geometry)Group actionProjective planeLecture/ConferenceComputer animation
22:53
Row (database)Medical imagingCoefficient of determinationRoundness (object)BitBilderkennungImage processingSoftwareMultiplicationDigital photographyProcess (computing)System callEntire functionPoint (geometry)Labour Party (Malta)CuboidError messageResultantLecture/ConferenceComputer animation
23:48
MereologyComputer wormCuboidError messageBitSoftwareResultantDigital photographyBlack boxRevision controlRepresentation (politics)RoboticsRow (database)Pattern languageGreatest elementPrice indexSemiconductor memoryInterrupt <Informatik>DreizehnMedical imagingAddress spaceTable (information)SpacetimeVector spaceCore dumpHexagonRight angleString (computer science)Bit rateSource codeComputer animation
25:05
SoftwareOrder (biology)BitCodierung <Programmierung>String (computer science)CASE <Informatik>CoprocessorCore dumpType theoryComputer architectureSoftwareContent (media)CodeRevision controlGame controllerMikroarchitekturPhysical systemVideoconferencingCartesian coordinate systemDeciphermentLecture/ConferenceProgram flowchart
26:04
Physical systemSimulationMaxima and minimaExecution unitInterior (topology)SoftwareAdditionSimulationDisassemblerMikroarchitekturComputer simulationComputer architectureSource codeBefehlsprozessorInformationCommodore VIC-20Physical systemComputer hardwarePeripheralComputerSystem on a chipLecture/ConferenceComputer animation
27:04
SoftwareAddress spaceVector graphicsAreaConditional probabilityFunction (mathematics)Key (cryptography)Self-organizationFactory (trading post)Set-top boxTask (computing)Interface (computing)Computer programTask (computing)Set-top boxCartesian coordinate systemNilpotente GruppeOperating systemMessage passingMultiplication signCryptographyProcess (computing)Key (cryptography)Factory (trading post)Address spaceInterface (computing)Asynchronous Transfer ModeElectric generatorExecution unit40 (number)Moment (mathematics)Information securityComputer programmingStreaming mediaEncryptionSoftwareDisassemblerComputer animation
28:05
Table (information)FlagError correction modelPrincipal ideal domainData bufferInternet service providerSoftwareDigital filterComputer hardwareStandard deviationData Encryption StandardAsynchronous Transfer ModeEncryptionStreaming mediaPeripheralSet-top boxStreaming mediaComputer hardwareFunction (mathematics)EncryptionTelecommunicationBitAsynchronous Transfer ModePhysical systemFilter <Stochastik>DisassemblerPeripheralBus (computing)CryptographyGame controllerSoftwareVideoconferencingInterface (computing)Message passingPrincipal ideal domainSerial portTask (computing)Heat transferError correction modelResultantKey (cryptography)outputTouchscreenAdditionComputer animation
29:21
Error correction modelAlgorithmStreaming mediaMessage passingFirmwareCore dumpEntire functionSoftwareSimulationKey (cryptography)Abelian categoryMathematical analysisSystem programmingComputer wormSequenceFrame problemCountingComputer programCryptographyInternet service providerEncryptionSubsetNumberValidity (statistics)Electric currentMultiplication signMessage passingInformationStreaming mediaMereologyBitPay televisionCountingKey (cryptography)EncryptionPoint (geometry)Operator (mathematics)Computer programmingSlide ruleFrame problemBus (computing)AuthorizationComputer hardware40 (number)Arithmetic meanCategory of being2 (number)FrequencyFreewareInternet service providerService (economics)Physical systemFocus (optics)Asynchronous Transfer ModeSet-top boxAlgorithmSoftwareContent (media)Game controllerEntire functionSelectivity (electronic)CryptographyError correction modelMathematicsSeries (mathematics)MultilaterationMultitier architectureComputer animation
32:25
MereologyExecution unitAddress spaceInternet service providerMereologyInformationResultantMessage passingCategory of beingAuthorizationSet-top boxPay televisionKey (cryptography)Address spaceExecution unitMathematicsLecture/ConferenceComputer animation
33:34
Internet service providerCryptographyAbelian categoryAddress spaceEncryptionExecution unitStreaming mediaPeg solitaireComputer programCategory of beingSystem programmingMusical ensembleMathematicsKey (cryptography)Different (Kate Ryan album)Level (video gaming)Factory (trading post)TrailOpticsBitProcess (computing)Computer hardwareHeat transferStreaming mediaDescriptive statisticsClosed setAlgorithmPeripheralPoint (geometry)Address spaceAsynchronous Transfer ModeArea40 (number)Mathematical analysisSoftwareImplementationBit error rateEncryptionSoftware bugSource codeComputer animation
34:59
Streaming mediaEncryptionData Encryption StandardComputer programProcess (computing)Error correction modelCryptographyStreaming mediaBitAddress spaceData Encryption StandardPeripheralDifferent (Kate Ryan album)Operator (mathematics)Condition numberSoftwareSemiconductor memoryComputer hardwareMultiplication signSource codeSoftware testingType theoryWhiteboardNormal operator40 (number)WebsiteSoftware developerRule of inferenceAnalogySeries (mathematics)Lecture/ConferenceComputer animation
35:52
Series (mathematics)Level (video gaming)Normal (geometry)Function (mathematics)Software developerNormal operatorWhiteboardInverter (logic gate)Dependent and independent variablesMultiplication signProcess (computing)Key (cryptography)MereologyModal logicoutputControl flowSoftware testingDifferent (Kate Ryan album)Point (geometry)Strategy gameSet-top boxOscillationLecture/Conference
36:57
Normal (geometry)Dependent and independent variablesDependent and independent variablesSound effectNormal operatorMultiplication signSign (mathematics)Level (video gaming)Point (geometry)LengthStrategy gameBefehlsprozessorCausalityComputer animation
37:51
Digital electronicsElement (mathematics)WhiteboardFunctional (mathematics)WordBitNegative numberSoftware developerSemiconductor memoryShared memoryAxiom of choiceSoftwareAddress spaceComputer architectureCodeMessage passingComputer wormHydraulic jumpInterface (computing)AreaWeb pageSoftware testingUsabilityGame controllerLecture/Conference
39:16
Computer wormLoop (music)Address spaceOpcodeMaxima and minimaComputer wormHydraulic jumpCodeMultiplicationRule of inferenceResultantMemory managementComputer programmingNeumann boundary conditionAddress spaceSingle-precision floating-point formatTask (computing)Process (computing)Computer architectureSource codeAdditionPoint (geometry)Multiplication signControl flowSemiconductor memoryLecture/Conference
40:37
Computer wormError correction modelOptical disc driveVideoconferencingIntrusion detection systemDisk read-and-write headRange (statistics)Cache (computing)IRIS-TBit rateCodeSpeicheradresseAddition2 (number)Semiconductor memoryComputer programmingKey (cryptography)Computer hardwareAddress spaceLengthCartesian coordinate systemAreaData Encryption StandardPoint (geometry)EncryptionComputer wormCollaborationismQuicksortFactory (trading post)Lecture/ConferenceComputer animation
41:46
Computer wormBit rateError messageSample (statistics)OpticsCore dumpTotal S.A.Key (cryptography)WhiteboardContent (media)Component-based software engineeringAbelian categorySet-top boxDigital electronicsSet-top boxConnectivity (graph theory)Digital electronicsOpticsCategory of beingSoftwareComputer programmingCore dumpError messageHookingSemiconductor memoryCondition numberForceExterior algebraReading (process)Row (database)Process (computing)Dependent and independent variablesContent (media)LinearizationAddress spaceInformation securityMereologyPersonal identification numberPoint (geometry)BitConnected spaceResultantBackdoor (computing)Computer wormBit error rateCodeKey (cryptography)Latent heatComputer animation
43:50
Shape (magazine)Computer wormPersonal identification numberSet-top boxPlanningCuboidEndliche ModelltheorieFluxComputer animationLecture/Conference
44:44
10 (number)Set-top boxKey (cryptography)FluxSoftwareDifferent (Kate Ryan album)Roundness (object)CodeCausalityMultiplication signDependent and independent variablesOscillationFunctional (mathematics)Time zoneControl flowComputer wormConfiguration spaceValidity (statistics)Personal identification numberProjective planePoint (geometry)CuboidContent (media)
45:39
Asynchronous Transfer ModeBlock (periodic table)EncryptionAlgorithmRoundingOracleData Encryption StandardHill differential equationKey (cryptography)Operations researchStreaming mediaSound effectCiphertextCategory of beingSet-top boxValidity (statistics)Key (cryptography)Content (media)AuthorizationReverse engineeringOpticsComputer hardwareStreaming mediaBlock (periodic table)OracleRoundness (object)Level (video gaming)NumberResultantWikiSoftware testingGoodness of fitMathematicsPoint (geometry)Asynchronous Transfer ModeCryptographyReal-time operating systemFunction (mathematics)Standard deviationTime zoneoutputWebsiteBitMultiplication signFunctional (mathematics)TheoryAreaHeat transferHydraulic motorDifferent (Kate Ryan album)CausalityWeb syndicationEncryptionSoftwareVulnerability (computing)EmailDifferential (mechanical device)CodePeripheralLecture/ConferenceComputer animation
48:35
Exclusive orData Encryption StandardComputer hardwareEncryptionBlock (periodic table)CryptographyMatching (graph theory)Sign (mathematics)SoftwareBitEvent horizonSoftwareBlock (periodic table)Maxima and minimaNumberKey (cryptography)Level (video gaming)FrequencyResultantMultiplication signTheoryModal logicComputer hardwareAuditory maskingForcing (mathematics)Single-precision floating-point formatLogic gateMathematics2 (number)Software testingSound effectEncryptionExclusive orSeries (mathematics)
49:25
Computer hardwareData Encryption StandardExclusive orBlock (periodic table)EncryptionMatching (graph theory)Sign (mathematics)Key (cryptography)Error correction modelStreaming mediaProcess (computing)ImplementationSoftwareModule (mathematics)Abelian categoryConditional probabilityComputer wormSoftwareBlock (periodic table)ResultantTheoryBit2 (number)Pattern languageAuditory maskingForcing (mathematics)Exclusive orLogic gateDescriptive statisticsOracleTrailRoutingSource codeStreaming mediaComputer hardwareAsynchronous Transfer ModeInformation securityKey (cryptography)Vector spaceComputer programmingPhysical systemEncryptionCategory of beingFunctional (mathematics)Copyright infringementPoint (geometry)Order (biology)CountingDivisorMathematicsNP-hardPosition operatorIdentifiabilityLecture/ConferenceComputer animation
51:22
SoftwareModule (mathematics)EncryptionStreaming mediaVideoconferencingImplementationTable (information)View (database)Universal product codeNeumann boundary conditionArchitectureMathematical analysisCodeComputer hardwareCryptographyData Encryption StandardKey (cryptography)PermanentBackdoor (computing)Address spaceLinear mapBackupExecution unitMaß <Mathematik>Local GroupKolmogorov complexityRoundingComputer hardwareKey (cryptography)MathematicsConditional-access moduleSystem programmingAlgorithmTouchscreenBroadcasting (networking)View (database)Event horizonSet-top boxCategory of beingLevel (video gaming)AuthorizationInternet service providerPhysical systemBackdoor (computing)LinearizationCodeAddress spaceMechanism designVulnerability (computing)EncryptionDynamical systemField (computer science)LogicGame controllerReal-time operating systemPlastikkarteAreaComputer architectureLoop (music)Shared memoryCryptographySoftwareSemiconductor memoryMathematical analysisReading (process)Reverse engineeringBit rateMultiplication signProjective planeExterior algebraComputer animationLecture/Conference
54:19
Data Encryption StandardKey (cryptography)SoftwareEncryptionPermanentCodeBackdoor (computing)Linear mapAddress spaceBackupLocal GroupExecution unitMaß <Mathematik>RoundingKolmogorov complexitySet-top boxExecution unitAddress spaceKey (cryptography)Category of beingPhysical systemSoftwareSoftware bugMetropolitan area networkCuboidMultiplication signOrder (biology)Rule of inferenceGroup actionPay televisionLecture/ConferenceComputer animation
55:12
Key (cryptography)Data Encryption StandardEncryptionPermanentCodeBackdoor (computing)Address spaceLinear mapBackupMaß <Mathematik>Local GroupExecution unitSoftwareRoundingKolmogorov complexityProgrammable read-only memoryDressing (medical)Computer programmingKey (cryptography)Heat transferStreaming mediaMereologyEncryptionMultiplicationRoundness (object)Category of beingData Encryption StandardError correction modelCuboidProjective planeRevision controlVariety (linguistics)Information securityFunctional (mathematics)Computer animationLecture/Conference
56:09
View (database)Functional (mathematics)Set-top boxInformation securityMessage passingPoint (geometry)Goodness of fitCopyright infringementInternetworkingCuboidComputer virusLecture/ConferenceComputer animation
57:11
Set-top boxCuboidSingle-precision floating-point formatProcess (computing)Shift operatorRoundness (object)Point (geometry)Key (cryptography)Lecture/Conference
57:59
Projective planeMultiplication signControl flowFrequencyWordData Encryption StandardEncryptionCybersexInternetworkingGroup actionPhysical systemMereologyContent (media)Network topologySpacetimeStandard deviationDirection (geometry)System programmingLecture/Conference
59:03
InternetworkingSpacetimeCybersexClient (computing)Reverse engineeringResultantMultiplication signFrequencyLecture/Conference
59:53
Reverse engineeringInternetworkingSoftwareMedical imagingAlgorithmImage processingDampingPhysical systemRule of inferenceCuboidLecture/Conference
01:00:43
CuboidKey (cryptography)AuthorizationMultiplication signProcess (computing)Internet service providerLatent heatCodeFrequencyPhysical lawProper mapLecture/Conference
01:02:01
MedianHypermediaCartesian closed categoryLecture/ConferenceJSON
Transcript: English(auto-generated)
00:13
So coming over to our next talk. Tonight, if you switch off your deck phone
00:25
and if you're full of different impressions, full of different impressions of this day, you maybe want to watch TV. But it would be cool to have pay TV, unencrypted pay TV.
00:41
So Chris Galinsky asks himself the same and how to achieve unencrypted pay TV, but the heck away. So Chris reverse engineered nothing less than the signal and the encryption for a standard that remains unencrypted since the late 90s. Please welcome with an anniversary edition applause,
01:03
Chris Galinsky.
01:24
Hello everyone. My name is Chris Galinsky. I am a hacker from Canada and I'm here today to talk about how I cracked digital cable and satellite TV security. I studied an access control platform that's widely used across Canada and the USA. It's one of the two common platforms
01:41
that's used in cable TV. And it's also used in satellite TV by one of the two Canadian satellite TV operators. As far as I know, the system has remained secure since it was introduced in the 1990s. And I was curious if I could understand the system based on the older set-top boxes. Some of them are 15 years old and they're still in use.
02:01
So these devices haven't received upgraded security hardware in that time. And I started looking at how the system works. Before I get into the reverse engineering, I'll start with a brief description of how digital television is sent over satellite or cable. Satellite and cable digital television are pretty similar for the most part.
02:21
There are a variety of signal modulations used. The relevant ones here are QPSK at about 27 megabits and 8PSK TurboFec at about 38 megabits for satellite and QAM256 at about 38 megabits for cable. There's also an out-of-band channel used by cable,
02:41
which is QPSK modulated at two megabits. This out-of-band channel carries the subscription management, program guide information, firmware upgrades, et cetera. And while you change channels and the cable box tunes to different frequencies, this out-of-band channel remains tuned so that the box continuously receives this data no matter what TV channel you're attuned to.
03:01
In the satellite TV, this type of data is included within the main transport stream instead of in a secondary out-of-band transport stream. The video is sent as MPEG-2 or H.264 transport stream. This is a standard format for carrying video streams. So it can be played by any hardware video decoder or a software decoder, for example, VLC.
03:22
And the encryption system used here is called DigiCypher2, which does not follow the DVB standards that are used in the rest of the world. The MPEG transport stream is made up of packets of 188 bytes. Each packet has a PID. This is used to differentiate different types of data.
03:42
PIDs range from zero to hex 1FF. Each PID carries an MPEG-packetized elementary stream that's a video or audio stream, or the PID may carry one or more service information tables. The service information tables have an eight-bit table ID and a length of up to 1,024 bytes,
04:01
including a CRC32 for error detection. And this table ID identifies the type of data that you can expect within the table. Table zero is the program association table containing a list of programs carried in this transport stream and the PMT PID for each program. The program association table is always on PID zero.
04:22
Table two is the program map table, which contains the list of packetized elementary streams and the PID for each, as well as an ECM PID. There's a program map table for each MPEG program or TV channel that's found in the stream. The ECM PID is where entitlement control messages are sent containing information that's used to generate
04:42
the key that decrypts the packetized elementary streams. This system uses two types of ECM. Table 40, I call ECM 40, and table 41, I call ECM 41. On PID one, there may be one or more conditional access tables, table ID number one.
05:01
These tables identify a PID that carries EMMs, entitlement management messages. These messages are used to set access rates for individual set-top boxes. The subscription information, like what channels are available, is carried inside of EMMs. This is a hardware interface to receive satellite data,
05:22
Genpix Skywalker one. The DC2 QPSK modulation isn't widely supported in the USB or PCI DVBS devices, and the 8PSK TurboFec modulation support is even less common. And one of the devices that does support these signals is this Genpix device, which is using
05:41
a Broadcom BCM-4500 demodulator, and it supports both the DC2 QPSK and the 8PSK modulations. It works well. The Linux drivers need to be recompiled to include the support for these modes, and patches for this were published by Update.ly. There's a link on the slide.
06:03
For cable, there's a variety of adapters supporting QAM-25060 modulation. I used a USB HVR-950Q tuner. Unfortunately, to tune the out-of-band channel is generally not supported by the off-the-shelf interfaces. Inside the cable box, it's handled
06:21
within the integrated chipset, and for the clear QAM consumer devices, such as USB interfaces, access to the out-of-band data isn't actually required, and so they don't include it inside of the hardware. This out-of-band data is used only for pay-TV services.
06:40
With the satellite and cable interfaces, DVB snoop can be used to view a lot of information about the transport stream. It's enough information to be quite overwhelming. So the trick to using it is to being able to sift through the output for the relevant information. DVB snoop also doesn't recognize all of the DigiCypher2 tables, because it's a non-standard system,
07:00
and DVB snoop is targeted towards the standard systems. So DVB snoop may not be able to tell you everything about the transport stream, but it was still a very useful tool for all the information that it can provide. DVB snoop and most other tools and documentation
07:20
are designed for the DVB standard, or other recognized standards, such as ATSC. DigiCypher cable and satellite systems use a lot of non-standard tables to carry the system information. For cable TV, some of these tables are standardized by the document SCTE 65. There is no BAT or SDT, as you'd expect in DVB.
07:42
Instead, there is a virtual channel table that maps the transport streams and programs to channel numbers. The electronic program guide is also not DVB standard, so you don't even get the current and next program information in any kind of a standard format. Another cable TV adapter is the HD HomeRun Prime.
08:00
This one is a network-connected three-tuner device with cable card support. The set-top boxes I studied predate the cable cards, although the newer boxes do use the cable cards and they support the DigiCypher2. But cable card support does also mean that this HD HomeRun Prime includes the tuner and QPSK demodulator for the out-of-van channel,
08:22
so it is able to pass this data to the cable card as necessary. However, even the HD HomeRun doesn't make this out-of-van data available other than the cable card interface. So to access the demodulated out-of-van data, I tapped into the HD HomeRun Prime with the cable card inserted and connected a logic analyzer
08:41
to the data and clock signals. I wrote software using the Selea SDK to capture the QPSK demodulated data. Then in software, I performed deinterleaving, derandomization into the forward error connection, and the output is an MPEG transport stream.
09:00
So using an HD HomeRun Prime connected to the logic analyzer, connected to the PC, running the software, the output finally is a two-megabit transport stream, and this transport stream looks like a standard transport stream, and inside are the conditional access management messages, program guide information, and et cetera, everything that was missing from the main QAM transport stream.
09:26
Two bits in each packet will indicate if the packet is scrambled with the even key, odd key, or not scrambled at all. The keys change at short intervals. DVB systems typically would change every five to 30 seconds,
09:43
DC2 every 133 milliseconds, or one second. The key used for decryption alternates between even and odd. The odd key is in use while the even key is updated, and then the even key is in use while the odd key is updated. An encrypted transport stream is sent via the cable or satellite,
10:00
and it's passed through the descrambler in the ACP, and the result is a decrypted transport stream that is played by the MPEG decoder. The descrambler uses a working key. This is a 56-bit DES key that changes every 133 milliseconds, or in some cases they have it slowed down to changing every one second. This working key is generated by encrypting the frame count
10:23
from ECM40 packets with the program key. The program key, again DES, comes from the ECM41 message, and is encrypted with a category key. The program key is unique to each channel, and it changes daily or for every pay-per-view event. The category key, also DES,
10:41
is shared by all the set-top boxes that are authorized for any channel from this provider. The category key is sent to each set-top box individually inside the EMM95 message, and this category key typically changes monthly, but many cable operators change keys much less frequently, some of them using the same key for years at a time.
11:02
To decrypt the EMM, in order to get the category key, seed keys are used. Each set-top box has a set of 56-bit DES seed keys inside of battery-backed RAM. These are initialized during manufacturing. For the lifetime of the set-top box, these keys are used to secure EMMs.
11:20
So this forms a chain from the seed keys initialized during manufacturing and never changing, to the decryption of the MPEG transport stream. Inside a satellite set-top box, we can see the main components of the system. The signal enters the tuner, and is passed through the demodulator, which outputs a serial transport stream.
11:42
This transport stream passes through the ACP, access control processor, and is then sent to the MPEG decoder to output a video signal to the TV. A 68K microcontroller acts as the set-top box main controller. It communicates with the MPEG decoder as well as with the ACP via an SPI bus.
12:00
A battery provides backup power to the ACP, so it will retain RAM contents even when the set-top box is unplugged. There's a TV pass slot near the power supply. This is an upgrade slot with a card edge connector to allow for security upgrades. The system stayed secure, so the TV pass slot was never used, and the newer set-top boxes don't actually include a TV pass slot inside.
12:23
So at this point, it seems quite unlikely that this TV pass card will ever actually be used. Inside a cable set-top box, it's very similar to a satellite set-top box, but the cable boxes tend to be more tightly integrated. Signal enters the tuner and passes through a Broadcom chip
12:41
that handles demodulation, and the same chip will also handle MPEG decoding after the transport stream has been decrypted by the ACP. A 68K microcontroller acts as the set-top box main controller, again talking to the ACP via SPI. And a battery provides backup power to the ACP and also to the non-volatile RAM
13:01
used by the main controller. A TV pass slot is underneath the main board. It's not visible in this photo. The cable set-top boxes include a second tuner that's used to receive the out-of-band data. This out-of-band tuner operates independently of the main tuner and on a separate frequency range, and it's used to provide a transport stream
13:20
containing the system information with the program guide, firmware updates, EMMs, et cetera. Here we see the ACP chip. It's a 100-pin TQFP package. From the markings, we can see it's a custom system on chip made for General Instrument Corporation, GIC. All the decryption is performed by the ACP,
13:42
and all decryption keys are kept only within this chip. The newer set-top boxes use newer versions of the ACP. I studied the original ACP chip that's seen in this photo. As long as the set-top boxes using this chip are actively used, it remains a relevant target. Whether the newer ACPs include
14:01
more advanced security features, or if they exist only for cost savings due to shrinking the die size, I don't really know. Some of the interesting pins on the ACP are labeled here. Pin one is marked at the top left corner of the chip. There's an SPI slave controller on pins one to five
14:21
used for communication with the set-top box main controller. There's a battery backup pin that's connected to a three-volt battery to keep the RAM contents of the ACP intact at all times. There's a serial transport stream input on pins 88 to 92, which receives the data from the demodulator. And there's a serial transport stream output on pins 28 to 33,
14:42
which sends the decrypted transport stream from the MPEG to the MPEG decoder to be output to the TV. At one point, I had written software for an AVR32 device, not the one that's shown here, that has a synchronous serial peripheral that supports sending and receiving data
15:01
at the 27-megabit rate of the transport stream. My AVR32 implementation turned out a bit ugly, but rather than cleaning it up, I was able to use it as it was. It had some limitations, like only accepting 64 kilobytes of data for replay and logging, which was just barely good enough for my studies. What the transport stream logging insert did show me
15:22
was that the transport stream passes through the ACP with selected pins being decrypted, and then the output is the full transport stream, but a selected program has been decrypted. The AVR32 logging interface had rather limited use for me. Later on, when I did more thorough research,
15:40
I did so using an ACP that I'd removed from the box, and I put on a breakout board, and then I could control the clock, and at that point, it was much easier to use an Xmega AVR platform to send and receive the transport stream through the ACP at a much slower bit rate. Shown here is the Xmega platform I settled on using for SPI and also the transport stream interfacing.
16:04
To monitor the data passed between the set-top box main controller and the ACP on the SPI bus, I used the Xmega development board. Two SPI ports acted as slave, with the master out slave in signal connected to one and master in slave out signal connected to the master out slave in
16:21
input of the second port. So from one port, bytes sent by the set-top box controller are received. From the other port, it receives bytes from the ACP. In case I want to talk directly to the ACP or the set-top box main controller, it's only necessary to connect both the Mozi and MISO signals on one of the SPI interfaces.
16:40
By holding the main controller and reset, my Xmega was able to act as the SPI master and then talk to the ACP. So this set-top works for passively monitoring the SPI communications in the set-top box and can also act as the SPI master for interrogating the chip directly. By logging the SPI bus
17:01
between the main controller and the ACP, we see that information about the current access levels is sent from the ACP. The ACP also receives EMMs via the SPI bus. EMMs have been filtered by the unit address number or the set-top box serial number. So the ACP only receives messages that are intended for that specific unit.
17:22
Command 04 includes the current category key epochs and key selects in use. Command 05 includes the unit address number. Command 13 returns the authorized subscription tiers for this unit. Command 7 and 87 provide information about the channel being currently decrypted.
17:40
Additionally, via the SPI interface, the set-top box main controller tells the ACP which PIDs to decrypt and which is the ECM PID. The ACP doesn't send any keys on the bus and it only receives category keys that are encrypted within EMMs via the SPI. So all of the really interesting data is contained within the ACP chip itself
18:00
and it's never sent out on any kind of a bus. So next I started an invasive study of the chip, studying it under a microscope. The cost of microscopes can range from hundreds of dollars to tens of thousands of dollars or even higher for things like electron microscopes or other specialized equipment. So I have a couple of microscopes that I use.
18:22
This one is the Mitutoyo FS70 microscope. These Mitutoyo are often used for micro probing but you can also use it for other uses. For this project, I didn't do any micro probing but I used this microscope because it was what I had. For studying this kind of technology, you could use even more basic equipment but of course if you have the higher end equipment,
18:41
it's a lot nicer to work with. Another microscope I use is the Zeiss Axiotron. This microscope is designed for inspecting wafers and has really good optical quality. I said that more basic equipment could be used and it's true but when you get into this kind of thing, you might find yourself again and again investing in more equipment.
19:00
I have about $10,000 in this setup including the microscope and the camera and the scanning stage and other parts. To look at the chip under the microscope, the chip is decapsulated. Fuming nitric acid is used for this. The chip is immersed in heated red fuming nitric acid which reacts with the plastic packaging and removes it.
19:23
The chip is then rinsed in acetone and cleaned with isopropyl alcohol in an ultrasonic bath which leaves the dye bare and clean. The nitric acid is quite aggressive and it's important to handle it carefully but the process is really straightforward. Most people probably wouldn't want to do this in their home
19:40
so you should go out to the garage and use your fume hood there. After the decapsulation, the bare chips are left with bonding wires attached to them so these wires will be plucked off using tweezers to get them out of the way. Already in this photo, we can see some of the larger structures on the chip. Half of it's covered with a metal plane
20:01
and the other half shows some kind of visible circuitry. This is an image of the chip under the microscope. It's been stitched together from several smaller images to give an overview of the chip. Looking at the decapsulated chip, we see the bond pads around the outside,
20:21
a metal plane covering the top part of the chip and wires on the bottom of the chip, the spaghetti logic running all over the place with a couple of structures that look like they could be a type of memory. There's a lot still hidden from us. To see more of the chip, it will be necessary to de-layer it. To de-layer the chip, I used hydrofluoric acid
20:42
to perform a wet etch. I used the Wink Rust Stain Remover product. It's available in hardware stores all over the USA. It's a dilute HF solution that works really well for de-layering ICs. I put a small amount of the Wink liquid in a beaker and heat it on the hot plate, then I drop the de-capsulated dye in.
21:01
Using a pipette, I agitate the liquid to disturb the bubbles that form on the surface of the chip so the acid can etch the chip more evenly. The etching result isn't perfect. Some parts of the chip will be etched deeper than other parts, but I've gotten quite useful results using this technique. You really don't want to breathe in these fumes, so do this in the fume hood in your garage also.
21:26
After a short time immersed in the heated Wink solution, the chip was rinsed and put back under the microscope. Now the top metal plane has been removed so we can see what's below. There are some visual effects that we start to see in the photo from the etching being a little bit uneven, but overall the de-layered chip looks quite good
21:42
and is able to start studying it. At the top left, the tall rectangles are round, the four blocks at the top right are ROM, and then there's logic that tie these into the logic area below. I was interested in finding how the bits were encoded in ROM, so I continued de-layering the chip.
22:02
This was another dip in the Wink and another metal layer has been removed. Bits in the ROM were not visible yet, so I continued the de-layering process. At this point, we're starting to see more of the visual effects from the uneven etching, but it's still not too bad. After a third dip in the Wink, more metal has been removed.
22:21
At this point, the de-layering is becoming more and more uneven. We can see the ROM blocks have been half-etched to a lower layer, while half of the upper layer is still remaining. The wet etching process can be quite difficult to perform completely consistently without adding additional steps such as polishing, and at the time I did this project,
22:40
I didn't have the polisher available, so I was relying only on the wet etch. Some of the areas of the ROM are now showing visible bits. The other areas haven't been etched deeply enough, so I continued to etch further to try and get a clean ROM. We can see the ROM bits quite clearly now. They're arranged in rows and columns, and in this image, if a black dot is visible,
23:01
that indicates that the bit is a one. Image quality is important. The better the photographs, the more consistently the bits will be visible, but it doesn't have to be really perfect. You can do some image processing on it. You can even repeat the process on multiple chips, de-layer them and photograph them, and at some point, you'll be able to have the entire ROM clean and consistently visible.
23:24
With the visible bits exposed and photographs taken, the bits can be extracted using a software image analysis tool, or the bits could be extracted manually. The ROM here is 32 kilobytes, or over 260,000 bits, so manual extraction would be a bit labor-intensive,
23:41
but it isn't impossible. A software tool is more efficient. So I wrote some software to analyze the images and identify the one in zero bits. There are bits marked with a yellow box for zero bits, or a blue box for one bits. I use the software to analyze the image, and then I can quickly review the results manually and identify any errors that I can see.
24:04
After extracting the bits from the photographs, I have a binary version of the ROM data. This is a visual representation of the bits extracted from this piece of ROM. The black boxes signify one bits, and the white boxes signify zero bits. In this image, I've overlaid the extracted
24:20
bottom 13 rows of bits over the photograph. You can see some visual patterns inside this also, and these visual patterns are a good indicator that this ROM is probably not scrambled. This image shows the end of the ROM, where you can see a pattern covering most of the image due to a repeated pattern of filler bytes
24:40
that occupy unused space at the end of the ROM. At the very end of ROM, the pattern is interrupted. This is where the vectors table exists at the top end of memory, indicating the reset address and the addresses of interrupt handlers. The ROM has unused space, the filler bytes at the end, and the vectors table at address is FFF6 through FFFF.
25:02
After extracting the bits and decoding them into bytes, the hex dump can be studied. There is a copyright 1997 CHCC ASCII string in ROM, which is helpful to identify when the ROM has been decoded correctly. If you can read the ASCII text, then surely the bits are in the correct order. The decoding in this case is just a matter
25:20
of organizing the bits into bytes. It's quite straightforward. There was no scrambling or anything else that was complex. With the ROM contents extracted, the software can be disassembled and analyzed. The first step was to identify the CPU architecture. Studying the binary dump, it appeared to be an eight-bit CPU, but wasn't 8051 or 6805
25:41
or any of the processor types I tried first. Eventually, I tried disassembling in 6502 and the code made sense. Later, I had remembered that I had looked at a previous version of the access controller from the same manufacturer, which was used in another system, VideoCypher 2+, an ancestor of DigiCypher. On the older chip was a copyright notice from WDC,
26:02
who licenses the 6502 core IP. It was visible directly on the chipped die under the microscope. So this would have been a great clue for the CPU architecture if I'd actually noticed it earlier. For disassembly, I used IDA. It supports 6502 and is, of course, a very powerful disassembler.
26:22
In addition to disassembly, I used 6502 simulation software to study the software in a virtual CPU. The simulation is really helpful when disassembling the software. It provides a lot of insight into what's going on. Since 6502 is a very well-known architecture, it was not at all difficult to find an existing simulator, even free with source code.
26:42
The 6502 was used in eight-bit computers, like the Apple II and Commodore 64. So there's really a lot of enthusiasts and a great deal of information about this architecture. As I gained understanding of the system on chip through disassembling the software, I began adding some of the features into the simulator to emulate some of the hardware peripherals
27:00
that were found inside the ACP device itself. One of the first things I saw in the disassembly was that there are two operating modes. During startup, values in RAM are checked, and if the ACP hasn't been initialized, it enters a personalization mode used during manufacturing to assign the unit address and seed keys.
27:22
In normal conditions, after the set-top box has left the factory, this personalization software is bypassed and the ACP will always run its main application. The next thing I found was the application wasn't very simple. This 6502 actually runs a task-switching operating system. Eight tasks are run, supporting decryption
27:41
of up to two channels at the same time. There are two tasks to handle processing of ECM40 messages and generation of the working keys used to decrypt the transport stream, and two tasks to handle processing of ECM41 messages to generate the program keys that are used to process the ECM40. One task for handling EMM processing,
28:02
and there is also a task to communicate with the TV pass interface for security upgrades with another task to handle the messages that are coming in over the SPI interface. Since the ACP is a custom system on chip, there is no documentation available describing the hardware capabilities,
28:21
so the disassembly was studied and the input-output registers had to be guessed based on the software usage. There is an SPI slave peripheral for communication with the main controller. The SPI peripheral sends and receives data directly to RAM and then a signal is set indicating that a transfer has been completed. There's a desk crypto peripheral.
28:41
Key, data, and operating mode are set in registers and when the decryption has been complete, the result can be read from additional registers. There's a transport stream descrambler. The working key is set in hardware registers and the descrambler will then output decrypted transport stream on the serial transport stream interface.
29:00
There are PID filters set by the set-top box main controller over the SPI bus. These filters select which video and audio streams to descramble and which ECM packets should be received by the ACP. The received ECMs are placed in RAM and the 6502 is notified of a new ECM via a register bit.
29:23
So at this point, I am starting to get an idea of how the system works. I've studied the MPEG transport stream and logged ECM and EMM data. I've logged the SPI bus and understand messages between the set-top box main controller and the ACP. I was able to extract the entire ROM contents optically and I've disassembled the software
29:40
and run it in simulation. There are some keys that are found in ROM, fixed keys, which never change and are used when a channel has a free preview weekend or something of the sort. Any set-top box that has ever had any kind of authorization in the past is allowed to decrypt channels that are encrypted using the fixed key mode. So now the focus is on understanding the ECM
30:01
and EMM algorithms within the ROM software. At this point, I'm still missing some important information from the ACP. All the seed keys, category keys and program keys exist only within RAM. So to decrypt any of the channels not in free preview isn't possible yet at this point.
30:20
The ECM 40 message is used to generate the working key used to descramble the MPEG streams. There's a service ID used to identify each channel and a frame count that's used with the program key to calculate the working key. The crypt mode identifies if the channel's operating unencrypted with a fixed key or with a normal secure keys, which are typically used.
30:42
The frame count is simply a 24-bit counter that increments each time the working key changes. There's a byte I've labeled hardware that has one bit set in it. This selects a special decryption mode that I'll come back to a little bit later. The ECM 41 contains encrypted program key that's needed to correctly decrypt the ECM 40.
31:04
There's a provider ID that indicates which TV operator subscribers this ECM should be processed by and there is the same service ID that will be found within the ECM 40 messages. The category epoch identifies which category key is in use. There's also information about how long
31:21
this program key will be valid for. ECM 41 contains one or more subscription tiers that must be found within the customer's ACP to allow this message to be processed. The subscription tiers are written to the ACP when the EMM containing authorization details is received. There is again a hardware crypto select byte that I will get back to.
31:44
This slide shows what a half of a second of ECM 40 and ECM 41 activity might look like. To be able to descramble the program, the ACP must process a current ECM 41 to get the program key and then process an ECM 40 to get the working key. The working key is then used by the descrambler
32:01
to decrypt MPEG stream. Until the ACP receives the ECM 41 with the current key as well as an ECM 40 with the frame count, it's not yet possible to decrypt the transport stream. The working keys have a short lifetime, only 133 milliseconds. The series of ECMs shown here all would happen
32:21
within a period of a half of a second. The EMM's are split into four parts. Each part contains a portion of the subscription information for this set-top box. A category key is calculated from each of the four parts and the key that is calculated for each part has to match the others or the EMM will be rejected
32:41
and all authorization and category key will be wiped from this ACP. When the first EMM, part zero, is received, the authorization data inside the ACP is reset and will be replaced with authorization data from the EMM. When the next part, part one, is received, the existing authorization data within the ACP from part zero
33:02
is hashed along with the data in part one. If the result is correct, then the authorization from part one is copied into the ACP alongside the existing data from part zero. If the result is incorrect, then the ACP's authorization is erased. In this way, the four EMM messages are linked together and if anything is modified within any of the EMM messages,
33:23
the authorization will fail. This is an example of an EMM. Each of the four EMM parts contains some common information like the unit address and which category epoch this EMM contains information for. The EMM can contain two category keys, one for the current epoch and also for the next
33:42
so that when there is the change of the category key, the ACP already has the next key available. To decrypt the category key from the EMM, the seed keys contained in the ACP are used. The seed keys are unique to each ACP and are assigned during manufacturing. EMMs are transmitted out of band for cable systems,
34:03
but they're passed to the ACP in the same ways for satellite systems. So at the ACP level, there's no difference between the satellite and the cable systems. At this point, it should be possible to decrypt channels that are using a fixed key mode. Analysis of the ROM has shown the algorithms used to process the ECMs and generate a working key.
34:22
The fixed keys are known because they're contained in ROM. There could have been some question about the possibility of bit errors from the optical ROM extraction process, but the fixed keys can be confirmed as correct because the ROM software performs a checksum of this 256 byte area that contains the keys. Successfully running the checksum on the extracted ROM data indicates
34:41
that the extracted keys seem to be correct. But when I attempted to decrypt a fixed key channel, there was a problem. It did not work. Whether it was a bug in my decryption implementation or something else was unclear. However, I had noticed the bit in ECM 40 was set that causes a bit within the ACP hardware peripherals to be set.
35:01
The purpose of the bit was unclear, but its address was suspiciously close to the transport stream descrambler key. So I start to suspect that there might be some encryption other than just standard DES. To be able to learn more about the ACP, I started to look at glitching the chip. If I can succeed to glitch the chip, I may be able to find a way to read
35:21
and even write memory, and possibly a way to run my own software directly on the chip. This would allow me to control the hardware peripherals and be able to observe the chip's operation under different conditions. Timing tests of the ACP suggest that the 6502 is running from an internal clock source. So this ruled out a clock glitch attack. A VCC glitch makes sense.
35:41
And with the age of this chip, it seemed reasonable to expect that it would be susceptible to VCC glitches. The stronger protections against this type of attack are relatively recent. My glitcher design is quite simple. It's based on an Xmega development board and breadboard. I use the Xmega to communicate with the ACP over SPI and to control the glitch.
36:02
A 74 series 4053 analog switch is used to quickly switch the ACP VCC between two voltages, a normal operating voltage and a lower glitch voltage. I use a bench top DC power supply and two outputs so I can easily adjust both the normal VCC and glitch VCC levels.
36:21
Other parts on the breadboard are an oscillator to provide some clock inputs necessary for the ACP to operate and an inverter and NAND gate to cut out the clock during the time of the glitch. To simplify the test setup as much as possible, the ACP was removed from the set-top box and soldered to a breakout board. So in this process, the battery-backed RAM
36:40
was disconnected and all the keys were lost. But for the purpose of developing working glitch, this was okay. This simple breadboard-based glitcher is quite flexible. The breadboard can be modified to test different ideas and reconfigure quickly. More complex and advanced glitcher wasn't necessary. To test the glitcher to find out if it will work
37:01
and what voltage levels are successful, we can send a command to the ACP, then glitch, and then see the response from the ACP. The general strategy is to lower the voltage just to the point where the chip sometimes resets due to the glitch. By adjusting voltage levels and glitch length and timing when the glitch will land, I succeeded to cause ACP responses to be altered.
37:24
The checksum on SPI packets is very convenient. When unusual data is received from the ACP chip with a valid checksum, it's a pretty good sign that the glitch caused the temporary fault within the CPU but that normal operation was resumed. Depending when the glitch is delivered, different effects are seen.
37:40
We can see that generally, as the glitch is moved later, it's the later bytes of the response packets that change. So at this point, it looks like the glitcher works and is able to cause a brief fault. Since I had an effective glitch, I took the circuit from the breadboard and etched a simple PCB that could plug directly onto the Xmega development board.
38:01
This performs exactly the same function as the breadboard glitcher, but I'm a bit less likely to accidentally unplug a wire from the breadboard and have to repair things. The circuit was simple enough that I could create a one-sided PCB so it was very easy for myself to etch at home. Now my goal is to have the ACP execute the code of my choice.
38:22
Because the 6502 is a von Neumann architecture, all code and data memory share the same address space. From software disassembly, I saw that there didn't appear to be any paging or MMU features. The software in ROM is fully self-contained. There is no EPROM and RAM is never used to hold executable code.
38:41
So there aren't jumps into these areas to exploit. And in fact, it wasn't clear if there's anything preventing code execution outside of ROM. I decided to take a chance and test if RAM is executable. So I send a message via SPI, knowing that this message will be stored in RAM. The message contains 6502 executable code that will copy itself to an unused area of RAM,
39:02
execute from this area, and send an ACK indicating it was successful. Because I studied the use of the SPI interface and the ROM code, I'm able to create this executable payload that will continue to receive commands via SPI after it's taken control of the ACP. To try to maximize chances of success, I looked through the ROM code for multibyte instructions,
39:22
which have broken up, would have contained within them a jump opcode with a destination that should lead to where my executable payload was placed in RAM. Since the ACP has a single address space, this gives a lot of opportunities for glitching to cause execution to reach the payload. There are multiple scenarios possible
39:41
in addition to my selected glitch target. Stack corruption is a possibility, and really any abnormal program flow has some possibility that it could eventually land in my code. The Von Neumann architecture, without strong memory management, is a very fertile ground for glitching. Anything in RAM potentially could be executed. So at this point, there are several uncertainties,
40:02
but so far, nothing totally rules out the possibility of success. The ACP operates from an internal clock source, and the interrupt-driven task switching does add some further timing uncertainty. So I will send the code payload, delay, then glitch, and see the result. When it's unsuccessful, I change the delay and I try again.
40:21
I try to aim for the instruction that I've identified as possibly corruptible into a jump, but there are a lot of unknowns, so really the process is like fishing, throw it a line and hope. I have a target, but no way to know if I can really hit it or if it will have the expected result. But sometimes fishing is good.
40:41
Relatively quickly, the ACP returns an ACK, indicating a successful glitch. The first successful glitch took some hours to find, and then after this, it was possible to make it work repeatedly in a matter of minutes or even seconds. So now I have my code executing in RAM. I'm able to send the ACP additional pieces of code to be executed. This allows me to read any memory address,
41:00
write any memory address, and perform any other operations possible with a 6502. I wrote a simple application to perform glitch searches and then to interact with the code payload back door installed in RAM. This program allows me to enter an address and length and have data returned or write to memory, et cetera. There's also support for setting the key in data
41:22
and performing DES encrypt or decrypt using the DES hardware that's inside the ACP. A few things I noticed at this point. There is a two kilobyte area of ROM that if I attempted to read it, caused the chip to reset. This area of ROM contains the personalization routines that are never normally used after the device leaves the factory.
41:41
There's also protection against modifying the seed keys in RAM. Trying to store a value to these memory locations appeared to do nothing. There are specific addresses within RAM that can't be read or the chip will lock up. These are clever traps put in place as a security measure. The seven byte, 56 bit keys stored in RAM straddle these dead addresses.
42:02
So a potential exploit that could cause a linear dump of memory will be stopped before a complete key is ever read. When the chip is reset, it means having to glitch in again because my code payload exists only in RAM and there is no way to hook in a permanent backdoor. Since we can execute code on the ACP
42:21
and receive a response, we can read the ROM to have its contents without any of the errors that were introduced during the optical extraction process. Comparing the results of the optical ROM extraction with a proper dump, we can see how many errors were in the optical extraction. Overall, the optical extraction was quite good. It was after all good enough to understand the software and get us to this point.
42:41
There's only one byte with more than a single incorrectly flipped bit. Many of the errors that existed were quite obvious when disassembling the software. If an instruction is out of place, but flipping a single bit would make it sensible, then it was probably a bit error. I didn't keep detailed records, but I think I probably caught about half of the ROM errors during the disassembly process before I started glitching.
43:05
The interesting keys in the ACP are all stored in RAM only. This includes working, program, category, and seed keys. The RAM is battery-backed. If the seed keys are ever lost for RAM, this ACP can no longer process EMM's and so is useless.
43:21
It's possible to glitch the ACP and read memory, but the glitcher works on an ACP moved from this set-top box. When the ACP is in circuit, the connections to other components and 16 VCC-connected pins pose a problem. To glitch the ACP in circuit will require some modifications to the set-top box, disconnecting the ACP from other parts.
43:41
Or another alternative is to remove the ACP from the set-top box and place it on a breakout board without losing the battery power and wiping RAM. Rather than modify the set-top box, where each of several different models would have required unique modifications, I decided to try to remove the ACP with a battery still attached.
44:00
The plan is to carefully lift the battery and ground pins while the set-top box is powered on, providing VCC. I use a small tool I made from a razor blade using a Dremel tool, then attached to the handle of a screwdriver. This tool can be wedged under a pin, then with some hot air, the solder will melt and a single pin can be lifted straight up without damaging any of the other pins.
44:24
With the pins lifted, an external battery can be attached. After attaching an external battery, after attaching an external battery, the set-top box is unplugged
44:41
and the ACP can be removed from the set-top box using hot air. The ACP can be removed from the set-top box, glitched and can even be placed back in the set-top box if desired. To do this, I just use hot air and a lot of flux. Additionally, once the interesting keys have been extracted, it might not even be necessary to replace the ACP in the set-top box.
45:02
The ACP is now placed on a breakout board and connected to the glitcher. Not all of the pins need to be connected, only a handful of pins are actually used by the glitcher. You can also see at this point, the glitcher is in a project box. The aesthetics greatly improved since the breadboard-based glitcher, but the functionality is identical.
45:21
The timing of ACP responses is different on a chip with valid RAM compared to the previous chips that I'd glitched before. I didn't confirm whether the cause of the timing difference was due to a different oscillator configuration or just a different software path, but by adjusting the timing of the glitches, the executable code payload runs as it did on the previous chips.
45:40
So now we can read the RAM contents of a valid ACP, including the category keys, if the set-top box had current authorization, as well as the seed keys that are used by this ACP to decrypt EMM's. With a valid category key, ECM's can be decrypted and a correct working key can be calculated for any channel.
46:02
Now with the capability of running my own code in the ACP, it's time to look at the transport stream descrambling. There's a hardware register bit that's set or cleared based on a byte in the ECM 40. When this bit is clear, standard desk decryption is used. When the bit is set, the transport stream descrambler acts differently. Additionally, there's an eight-bit hardware register
46:21
in the desk peripheral area. When it's zero, the peripheral operates the standard desk. For any other value, the peripheral acts differently. At this point, I started to think I might be looking at doing a gate-level reverse engineering of the chip to understand this functionality. The chip's using technology that's older, so reverse engineering should be feasible, but if possible, I'd like to avoid all this extra work.
46:41
It would be quite time-consuming and might give imperfect results similar to the optical ROM extraction. So I start with trying to characterize the scrambling modes. The transport stream packet is made up of a four-byte header and 23 blocks of eight bytes each. The desk operates on these eight-byte, 64-bit blocks. By flipping one bit in encrypted input, ECB, CBC, or OFB modes can be differentiated.
47:03
Flipping one bit causes an eight-byte block to be corrected and the corresponding bit in the following block to be flipped. This indicates CBC mode is in use. Timing of the input compared to the decrypted output was measured with the descrambler and standard desk and in the custom hardware mode, no timing difference was seen. This suggests the internal properties of desks
47:21
haven't changed, which makes sense because the decryption has to be done in real time. So this suggests that crypto customizations are not affecting some desk internals like the number of rounds. Also by using an ACP as a decryption oracle, I determined that the customization affects each of the 23 blocks of the transport stream differently.
47:41
Next, I tested the software using desk weak keys. These are certain keys not recommended for use with desks because their properties weaken the cryptographic strength. A key of all zero or all one bits will cause desk decryption and encryption to be identical. That is, running the same data through encrypt or decrypt will give the same result. I can test this on an ACP configured
48:02
for standard desk decryption and see the expected weak key behavior. When tested with the descrambler in custom mode, the weak key behavior changes. Using a key of all zero or all one didn't produce the same results in encrypt and decrypt modes. Looking at the other hardware register, testing the desk peripheral with different values in the eight bit register and using weak keys
48:22
shows that the standard desk weak key behavior still exists. So my hunch at this point is that one customization affects the key and the other customization affects the data. At this point, I can't be certain but I have a good feeling about the theory so I continue to investigate. Based on the idea that the hardware customization affects only the key and decryption is static,
48:42
I thought the simplest customization would be an XOR mask that's applied to the key before it's used for desk decryption. XOR requires only a single gate and series with the desk engine so it fits the requirements of fast and very simple to implement in hardware. A change of even a single bit in the key could cause the observed effects. Flipping more than 28 bits would be pointless.
49:00
That's the same as inverting a key and flipping fewer bits. More flip bits means more gates necessary for the customization so it makes sense to flip a minimal number of bits. So I wrote this wonderful four loop, nested 16 levels deep to test decryption results after flipping one bit of the key, then flipping two bits, then three bits and so on up to 16 bits. To test all the possible keys will take a long time
49:21
but if only a few bits are flipped then it might be possible to run in a shorter period of time. And promising results did come quickly. It turns out the theory held up and some of the blocks have as few as three bits flipped. This takes only seconds for the software to identify. After verifying that these work for XOR masks for these blocks, the software then was left running
49:40
to find all 23 masks. The simple brute force method worked. It ran for a couple of days to identify all the 23 masks. By more carefully analyzing which bits are being flipped in the early results, a pattern can actually be found so the search could have been more limited. Using this technique, the software tracker could have completed it in under a second.
50:02
After successfully solving the first hardware customization, the theory that the second customization is a data XOR looks promising. It makes sense that one or more XOR gate is enabled by each bit of the 8-bit hardware register. Using the ACP as a decryption oracle, a known key and data were decrypted with all values of the 8-bit register.
50:21
Software attack of this function was successful and 255 XOR masks were identified, behavior matching what was expected. I haven't actually seen this customization in actual use. Presumably they're saving it to be used as a countermeasure against pirate devices when necessary, but it hasn't been necessary since the system never had a security breach.
50:52
In order to implement a soft cam, a software implementation of the descrambler, a few cryptographic details need to be identified, but at this point I have all the tools to do so.
51:01
The initialization vector used for CBC mode can be found through a simple XOR and the handling of short blocks, those less than the 64-bit desk block size can be identified likewise. With all these details, a software implementation of the EMM decryption of category key and ECM decryption of program key and working keys can be made and the transport stream descrambler can also be implemented in software.
51:22
The rapid key changes and use of desks with hardware customizations makes it a bit different to implement compared to a soft cam for typical DVB systems, but overall the concept is the same. And now it's all working. I was able to test it and it's fully working on both the satellite and cable systems. This is a screen that's broadcast
51:40
before a pay-per-view event goes live. The pay-per-view, like all other channels, can be decrypted with a soft cam using the algorithms learned in these keys that were extracted. With the ECM and EMM algorithms and seed keys for a set-top box with any level of authorization, the category key can be decrypted and then used to decrypt any and all of the channels
52:00
that are broadcast by this provider. A few of the weaknesses that I identified in this system were that the ACP I studied is relatively old technology, almost 20 years old.
52:22
So this makes it a lot easier for invasive analysis today than when it was brand new. The TQFP100 package is quite easy to deal with compared to modern alternatives. The chip is susceptible to the voltage glitching. It's a von Neumann architecture without strong MMU protection preventing code to be executed from RAM.
52:43
They didn't leave any possibility for code update or dynamic code execution for countermeasure purposes. The software for the ACP is contained entirely in ROM with no mechanism for software updates in the field. The hardware customizations to the crypto are quite simple and required no reverse engineering of the chip logic.
53:02
I was basically able to guess the hardware customizations. I was impressed with the design of the system. It was actually stronger than I anticipated when I started the project. All the key handling and decryption is contained within a single chip which makes it impossible to do key sharing that's being done with some of the smart card systems.
53:23
The fast working key change interval, only 133 milliseconds, also makes key sharing more difficult and the short lifetime of the key makes cracking it in real time quite unrealistic. The lack of code in any rewritable memory means there's nowhere to write code for a permanent backdoor to disable the access
53:40
or to disable the access controls. I listed this also as a weakness but in fact this is a strength as it limits the attacker's capability to install any kind of persistent backdoor. The chip operates on an internal clock eliminating clock glitch attack and making timing a voltage glitch a lot more difficult. These dead addresses in the middle of desk keys
54:02
prevent linear readout of keys. If one were to cause a loop reading data to go out of bounds and reach the area of RAM where keys are stored, the chip will reset before an entire key is read. After the first couple of bytes, a dead address will be accessed that causes the chip to reset. The personalization ROM appears to be inaccessible
54:21
so it can't easily be used to modify the keys and unit address within the ACP. The seed keys aren't easily changed so the set top boxes can't easily be cloned. The keys exist only in RAM so you have to maintain a battery backup at all times. This rules out a lot of invasive attacks to retrieve the keys.
54:41
There are no group keys used for EMMs. All unit addressing is to individual units so you have to pull keys from an actively subscribed box in order to get active keys. That said, if you have keys from a box that is subscribed to any channel, you will receive an EMM containing the category key which is capable of decrypting all channels.
55:00
So you don't need to have a subscription to all channels you want to decrypt as long as you're authorized for at least one channel on the system. The software is generally well designed and written. I didn't notice any glaring bugs within it. Although DES is used, the EMM decryption requires using three DES keys and multiple rounds are performed
55:21
when decrypting EMM and ECMs. So this part isn't as simple as cracking a single 56-bit key. Brute forcing starting from the encrypted transport stream requires cracking working key, then program key, then category key, and finally the three seed keys.
55:43
You might wonder how many set top boxes it took for me to complete this project. The truth is I only needed the one truckload.
56:02
Some of the boxes had different versions of the ACP chip. Many of the boxes had different PCB layouts so it was interesting to be able to look at a variety of boxes. The cost of used set top boxes was low, around $20, and for this research I was focusing on the signal security and didn't need the PVR functionality or any of the advanced features from the expensive set top boxes.
56:24
So at this point I have a brief anti-piracy message. I don't recommend you pirate cable or satellite TV. There's never anything good on. It doesn't matter how many channels you can decrypt. Believe me, I looked. It's not worth the effort.
56:51
Do we have questions from the room? Questions. Please use the microphones. I know there is one question from the interwebs.
57:06
Okay, hello. This is working? Good. So the first question from the internet is how many chips did you destroy or make unusable and how did you get all those set up boxes?
57:20
Because the cost of the used set top boxes was quite low, I wasn't afraid to destroy several chips in the process. It didn't take as many as I would have expected in the beginning. Two or three chips were used for the decapsulation and the de-layering process. I ended up extracting the ROM from a single chip.
57:42
And then when it came to glitching, there were three or four chips that I removed and erased the RAM from to develop the glitch. When I finally got to the point where I was extracting keys from a valid chip, the very first chip that I tried worked. So there were a few casualties involved. Thank you.
58:01
Microphone three was the first one, please. How many years did this project take you? I would work for a few weeks at a time and then get burnt out and take a break and then come back to it. Most of the work for the project was completed over about a two year period.
58:22
Thank you. And microphone two, please. Hi, thank you for a great lecture. How come the content encryption was DES and not a DVB CSA? Because we used to use that content is encrypted with DVB CSA in these DVB systems. In North America, we don't believe in standards.
58:48
The timing was also a part of it. The system was being developed at the same time as DVB was being standardized. So general instrument, rather than going along with the standards group and waiting for the standardization, they went with DES directly.
59:02
Thank you. And another one from CyberCyber. Space cyber. Okay. Another question from the internet is, you have all this fancy like lab equipment and stuff. How were you able to afford that? I've been quite interested in this for a long time. So I've collected this equipment over a period of years
59:22
and I do some work professionally in reverse engineering. So whenever possible, I use a client's money to buy another piece of equipment for the lab. To do this actual work though, you could even use more basic equipment because of the age of the chip. You could use a microscope that you could find easily
59:42
for 1000 or $2,000 or even less and have quite good results. So it's not trivial, but it's not a huge amount of money for lab equipment. Not that huge. Microphone two, please. What do you do for a living besides reverse engineering? Reverse engineering.
01:00:03
Thank you. And the internet, again. Okay, next question is, somebody wants to know which software did you use for the automated image analyzing and is it available somewhere? Like everybody else that I've known that's done optical extraction, I developed it myself.
01:00:26
Everybody seems to develop their own tools from scratch for that. The image processing I use was really quite simple, so it didn't take a lot of advanced algorithms or anything like that. So yeah, I'm using some software I developed personally and hasn't been released.
01:00:44
Microphone 2, please. And how did you keep the boxes subscribed? So did you call them every week, oh my box broke down, I got another one, or how is this done? For most of the research that I did, I didn't need an active box. I did all the research just on previously activated boxes that had lost their authorization.
01:01:03
And by the time I had the process figured out that I knew how to extract keys from a valid box, I only needed the one box. And had you heard back from the cable provider about this? No. Okay, thank you. Microphone 3, please. Hello, thanks very much for the lecture and well done on all the work.
01:01:22
My question is how does the glitching work, the glitching attack? For the glitcher, it was quite simple. I dropped the voltage for a very brief period of time. And it's enough time that it causes at least one instruction to not execute properly.
01:01:42
But it's too short of a time to cause the chip to reset. So essentially I'm corrupting one instruction. As far as the specific target that I hit that led to my code in RAM, I'm not actually sure. I found that if I glitch it this time, then the code ends up executing my code. Good enough for me.
01:02:01
Okay, thank you, Chris. Please, dear audience, give an anniversary edition applause to Chris Galinski.