How Webrip Works

how_webrip_works.md

Document 1 discloses a method where the second encryption key for a video slice is generated based on a portion of frame information contained in the target frames of the video slice to be encrypted, as well as the first encryption key corresponding to the video file to which the video slice belongs. This second encryption key is used as the initial key to encrypt the corresponding frame data of the video slice, resulting in encrypted data for the corresponding frame data of the video slice. This method involves replacing the corresponding frame data part of the video slice with the corresponding encrypted data, while retaining the metadata of each frame of the video slice and other unencrypted frame data, thus completing the encryption of the video slice. The unencrypted other frame data includes the portion of frame information in the target frame.

Document 2 discloses a signal decryption unit, used to generate decryption rules according to the rules provided by the decryption rule generation unit. This unit decrypts the digital image signal output by the video decoding unit, dividing it into several image blocks and rearranging them in a manner opposite to that of the signal encryption unit. The rearranged digital image signal is then output to the video encoding unit of the monitoring end. The decryption rule generation unit is used to generate decryption rules, which are the reverse operation of the encryption rules, based on the received decryption key and a predetermined decryption algorithm, and output these rules to the signal decryption unit. The video encoding unit at the monitoring end encodes the image signal output from the signal decryption unit and outputs the encoded video signal to the video output unit.

The differences between this disclosure and existing technology include: (1) Configuring keeper and sheller processes to load content decryption modules and set up the decryption environment through these processes. (2) Copying the hijacked DLL to a specified directory, hijacking the target function, and creating a CDM object.

Therefore, this technical solution has certain novelty and creativity, and it is recommended to apply for a patent. Outline for Disclosure Document of Computer-Related Invention Technology

A technology disclosure document serves as the basis for agents to draft patent application documents. It should clearly describe the theme of a particular invention or creation (hereinafter referred to as the invention), answering questions like: How do others do it? What are the flaws in their methods? What am I going to do? How am I going to do it? What are the key points of my method? What are the advantages of my method?

1. Title of the Invention
2. Background Technology Schemes
3. Deficiencies in the Background Technology
4. Objective of the Invention
5. Implementation Scheme of the Invention
6. Key Points of the Invention
7. Effects of the Invention
8. Comparative Diagrams of Background Technology and the Invention

1. Title of the Invention

• This section briefly reveals the theme of the invention, clearly stating the product name and/or method name of the invention, avoiding non-technical terms like personal names, corporate names, trademarks, codes, and models.

• "A Method and Apparatus for DRM Video Decryption via Hijacking"

2. Background Technology Schemes

• This section briefly explains how others do it. It should introduce the nature and usage of the technology and/or products related to the invention. It should then describe 1-2 background technologies closest to this invention, focusing on their functionality and implementation process.

• Digital video content is often protected by Digital Rights Management (DRM) technology to prevent unauthorized access and copying. DRM systems typically operate on end-user devices to decrypt and play protected video content. However, in some cases, users may need to decrypt video content legally for backup, format conversion, or other legitimate purposes.

• Existing digital video decryption methods often involve cracking DRM systems, which can pose legal risks and intellectual property infringement. Therefore, a safe, legal, and effective method for video decryption through hijacking is needed to balance digital rights and legitimate user interests.

3. Deficiencies in the Background Technology

• This section briefly explains the deficiencies in what others have done. It should objectively state the technical or performance shortcomings of each background technology, related to the reasons for these deficiencies.

• Inconvenient User Experience: DRM systems often require user authorization, registration, or login to access the decryption key or license. This can lead to a poor user experience and reduced convenience in watching video content.

• Restrictiveness: DRM systems often limit users' usage of digital video content, such as restrictions on playback devices, transcoding, backup, etc., limiting free use of digital videos.

• Vulnerabilities and Attacks: DRM systems are at risk of being attacked and cracked. Hackers and reverse engineers may attempt to crack DRM systems to obtain decryption keys or bypass protective measures, leading to copyright infringement and illegal distribution.

• Incompatibility of Different DRM Systems: Different content providers may use different DRM systems, leading to incompatibility issues. Users may need to install multiple DRM decryptors to watch protected video content on different platforms, increasing inconvenience.

4. Objective of the Invention

• This section briefly explains the invention's objective, related to overcoming the identified deficiencies or solving specific problems. The invention aims to propose a method that does not require obtaining a decryption key but instead hijacks to restore DRM-encrypted video data, thereby legally decrypting digital video content without accessing the decryption key directly.

5. Implementation Scheme of the Invention

• This section details how the invention is implemented. It should thoroughly explain the overall technical scheme of the invention, highlighting the technical principles, implementation process, technical measures, and technical improvement points. If the technical improvement involves changes in system (or hardware) structure, it is advisable to provide a system hardware structure diagram and explain the system's working principles and processes in conjunction with the diagram. If the improvement also involves data processing steps, it is beneficial to provide flowcharts or functional block diagrams, particularly for inventions with improved algorithms, and include the improved algorithmic formulas.

[This part would further elaborate on the specific technical details of the DRM video decryption method via hijacking, including the system architecture, algorithmic approaches, and any novel features distinguishing it from existing technologies.] Figure 1 illustrates a DRM video decryption function via hijacking. The scheme includes the following steps:

S10: Configure Electron for Playing Netflix Videos

• Install Electron: Set up a Git SSH key and install the required 32-bit version of Electron. Open the main window of the Netflix website in the entry file. Once the application is ready, it creates a window and loads the URL of the Netflix website. Then, the project is packaged and signed with EVS (Electron Verification Service): You install castLabs EVS, register an EV account, and use it to sign the packaged application, ensuring it can play Netflix videos.

S20: Hook Method to Obtain Netflix Download Manifest Information

1. In the main process, create a new browser window (render process window) and load the Netflix website. After the DOM of the render process window is fully loaded, read the content of the hook code and inject it into the render process using executeJavaScript, thus achieving a hook into the Netflix webpage.
2. In the hook code, rewrite the JSON.parse and JSON.stringify functions to intercept the parsing and serialization of JSON data on the Netflix webpage, which includes the video URL.
3. Send the intercepted JSON data to the main process and organize it to obtain video URL, audio URL, and subtitle URL.

S30: Copy the Hijacked DLL to the Specified Directory

• Configure and launch the Electron application, copy the hijacked DLL, widevinecdm.dll, to <userData>\\WidevineCdm\\4.10.2557.0\\_platform_specific\\win_x86 or <userData>\\WidevineCdm\\4.10.2557.0\\_platform_specific\\win_x86, replacing the hijacked widevinecdm.dll.

S40: Configure Keeper and Sheller Processes to Load the Content Decryption Module (Keeper Acts as the Hijacking Process)

1. Use the LoadLibrary function to load the widevinecdm.dll file (this is the hijacked DLL file), which is a crucial operation as it is the primary library file for the Content Decryption Module (CDM).
2. Use the GetProcAddress function to get the addresses of some functions in widevinecdm.dll, including VerifyCdmHost_0, InitializeCdmModule_4, CreateCdmInstance, DeinitializeCdmModule, and GetCdmVersion. These functions are used for initializing and operating the CDM, and they are stored in _VerifyCdmHost_0, _InitializeCdmModule_4, _CreateCdmInstance, _DeinitializeCdmModule, and _GetCdmVersion.
3. Finally, validate the CDM host by calling the _VerifyCdmHost_0 function.

S50: Hijack the Target Function and Create a CDM Object

1. Create the VerifyCdmHost_0, InitializeCdmModule_4, CreateCdmInstance, DeinitializeCdmModule, and GetCdmVersion functions, export them, and call _VerifyCdmHost_0, _InitializeCdmModule_4, _DeinitializeCdmModule, and _GetCdmVersion.
2. CreateCdmInstance function: This function creates a CDM instance, accepting parameters like interface version number (interface_version), key system information (key_system), key system information length (key_system_len), host_function, etc. It first logs creation information, then calls _CreateCdmInstance to create the CDM instance. If the instance is not successfully created, it returns nullptr. Otherwise, it checks if the interface version number is 10. If yes, it creates a MyContentDecryptionModuleProxy object as a proxy for the CDM instance and returns the proxy object.
3. A custom HostFunction is used in _CreateCdmInstance. In HostFunction, the function creates a CDMHost object, which contains control and management over the CDM. It calls host_function to obtain the original CDMHost object, then creates a custom cdmHost object as a proxy for the original CDMHost object, and returns the CDMHost object.

S60: Configure the Decryption Environment

• The decryption environment is configured through the interaction between the keeper process (hijacking process) and the sheller process.
• Keeper Process:
  1. SetServerCertificate: When the browser calls this function, the keeper process converts server_certificate_data into Base64 and saves it.
  2. CreateSessionAndGenerateRequest: Similarly, when the browser calls this function, the keeper process converts init_data (usually PSSH data) into Base64 and saves it.
  3. OnSessionMessage: When the browser calls this function, the keeper process sends server_certificate_data and PSSH data to the sheller process to generate a licenseRequest. It then waits for the sheller process to generate the license and sends it to the browser.
  4. UpdateSession: When the browser calls this function and provides a license, the keeper process converts the license into Base64 and sends it to the sheller process.
• Sheller Process:
  1. Upon receiving cert and pssh from keeper, it calls CreateCdmInstance to create a MyContentDecryptionModuleProxy* object, calls Initialize for initialization, calls SetServerCertificate to set cert, and calls CreateSessionAndGenerateRequest to set pssh and generate licenseRequest.
  2. In OnSessionMessage, the sheller process sends the generated licenseRequest to sheller and waits for the sheller process to send the license.
  3. Once the license is obtained, UpdateSession is called to set the license, completing the configuration of the decryption environment.

S70: Initialize the Decoder

• After downloading the decrypted video, in the sheller process, based on the video's encoding type, quality, resolution, and encryption protocol (which can be obtained using bento4, an MP4 analysis library), MyContentDecryptionModuleProxy::InitializeVideoDecoder is called to properly initialize the configuration of the video decoder. This ensures that, before decryption begins, the video decoder is ready to receive and decode the protected video content. A successful initialization returns 0, indicating success.

S80: Decryption and Decoding

• Use MyContentDecryptionModuleProxy::DecryptAndDecodeFrame(const InputBuffer_2* encrypted_buffer, VideoFrame* video_frame) for decryption and decoding. Here is an analysis of its parameters:
  • InputBuffer_2 Structure:
    • const uint8_t* data and uint32_t data_size: These fields represent the input data of the video frame, including data pointer and data size. This is the raw data of the video frame to be decrypted and decoded.
    • EncryptionScheme encryption_scheme: Indicates the encryption protocol of the video frame, which can be kUnencrypted, kCenc (AES-CTR encryption), or kCbcs (AES-CBC encryption).
    • const uint8_t* key_id and uint32_t key_id_size: Identify the decryption key's key ID and its size. This is the key identifier used to decrypt the protected video frame.
    • const uint8_t* iv and uint32_t iv_size: The Initialization Vector (IV) and its size. The IV is used in some encryption modes to decrypt the video frame.
    • const struct SubsampleEntry* subsamples and uint32_t num_subsamples: These fields are used to specify the number of bytes and encrypted bytes in different subsamples of the video frame. Encryption is often done at the sample level, and these fields describe the encrypted and unencrypted parts of each subsample.
    • Pattern pattern: This is a structure containing information about how to treat blocks of bytes in the video frame, including encrypted blocks and skip blocks.
    • int64_t timestamp: Represents the display timestamp of the video frame in microseconds. This helps to display the video frames in the correct order.
  • All the above data can be obtained through bento4.
  • video_frame is used to receive the decoded data.

S90: Re-encoding the Decrypted Data

1. Create Video Stream: Use avformat_new_stream to create a video stream (videoStream).
2. Open Encoder: Responsible for opening the video encoder and setting its parameters. Find the H.264 encoder using avcodec_find_encoder, then allocate and set an AVCodecContext for the encoder. It's advised to check the return values of avcodec_find_encoder and avcodec_alloc_context3 to ensure the encoder is correctly initialized. Additionally, consider setting other encoding parameters, such as bitrate and framerate, as needed.
3. Write File Header: Use avformat_write_header to write the file header information to the output file. This step is essential, but check the return value to ensure the file header is written correctly.
4. Decode Frames and Format Conversion: Receive the decoded video frames (video_frame) from the decoder and convert their format. Implement two format conversions, YUV420P and YUV420P10LE. Determine whether the raw stream encoding in the video is YUV420P or YUV420P10LE using bento4, then convert YUV420P10LE to YUV420P, as H.264 only supports YUV420P.
5. Encode and Write to Output Stream: Send the converted frame data to the encoder for encoding, with the encoded data stored in an AVPacket. Send frames to the encoder using avcodec_send_frame, then get the encoded data using avcodec_receive_packet and write it to the output file.
6. Write File Tail: Finally, use av_write_trailer to write the file tail information and release related contexts and memory.

With these steps, the video decryption is complete.

VI. Key Points of the Invention

• This section highlights the invention's inventive or "bright spots" to help the patent agent understand the novelty aspects of the technical scheme, facilitating the correct direction while drafting patent application documents.

The invention's key points lie in its ability to decrypt DRM-protected videos through a series of innovative steps:

1. Configuring Electron and employing a hook method to obtain Netflix's download manifest information.
2. Hijacking target functions to create a Content Decryption Module (CDM) object.
3. Setting up a decryption environment that facilitates interaction between the Keeper (hijacking) process and the Sheller process.
4. Initializing the decoder, followed by the decryption and decoding of the video.
5. Re-encoding the decrypted data, making it a comprehensive solution for DRM video decryption.

VII. Effects of the Invention

• This section details the advantages and effects achieved by the invention. It should compare the invention's results with the existing technologies, potentially using experimental data or theoretical deductions.

The invention offers significant advantages in the field of digital rights management, particularly in decrypting DRM-protected videos:

1. The method eliminates the need for a decryption key, allowing direct decryption and decoding of DRM-encrypted videos.
2. It provides a safe, legal, and effective method for video decryption, maintaining a balance between digital rights and legitimate user interests.
3. Compared to existing technologies, this approach offers enhanced data security and resource conservation in computer-related inventions, demonstrating marked improvements in areas like data processing speed, accuracy, and manufacturing costs.

By employing this invention, users can access DRM-protected content more conveniently and legally, ensuring the protection of digital content while respecting the rights of all stakeholders.

VIII. Comparative Diagrams of Background Technology and the Invention

• This section assists the rest of the document by providing clear diagrams and explanations of the process flows and product structures related to both the background technology and the invention. The inclusion of diagrams is optional and can range from one to several.

For a computer technology invention, these diagrams mainly include system architecture diagrams, data flow diagrams, and functional block diagrams. Each diagram should clearly illustrate the name and the significance of each component, with detailed annotations where necessary. For instance, in this invention, diagrams might illustrate the system setup for Electron, the process flow for the hook method and decryption environment setup, and the functional components involved in the decryption and decoding stages.