内部からのモバイルデバイス。 ファイルシステムを含むパーティションのイメージ構造。 パート1

パート2

3.2._sparsechunkファイル。

4. datファイルの作成。

5.情報​​源。

ファイルシステムを含むパーティションのイメージ構造。

1.はじめに

ext4ファイルシステム（FS）を含むモバイルデバイス（MU）のパーティションイメージは大きく、たとえば、システムパーティションイメージのサイズは数GBに達する可能性があり、ユーザーデータパーティションイメージのサイズはすでに数十GBです。



これらの機能を使用するには、ファームウェア開発者がMUファームウェアの初期ロードまたはアップデートのインストールの操作を実行するときに「トリック」を使用する必要があります。 パーティションのイメージのサイズは、MUのRAMの容量に比例するだけでなく、それを大きく超えます。



ストック（工場）ファームウェアの開発者がパーティションイメージのサイズを縮小するには、現在次の方法を使用します。

• 画像の部分（チャンク）への分割（切り取り）;
• 画像全体の圧縮;
• datファイルの使用。

最初の方法は、画像をチャンクと呼ばれる複数の部分に分割することで画像のサイズを縮小することに基づいており、各ピースのサイズは事前に選択された許容値を超えてはなりません。 これにより、1つのセッションでMUに送信される情報の一部のサイズを削減できます。



2番目の方法は、スパースファイルであるFSイメージのプロパティを使用します[1]。 これにより、データを失うことなくコーディングを適用できます。これにより、ゼロまたは重複データを含む「空の」ブロックのボリュームが削減され、パーティションイメージ全体のサイズが削減されます。



3番目の方法の特徴は、エンコード後にすべての「空の」ブロックがイメージから削除される（ファームウェアのインストール時）か、イメージの変更のみが転送される（更新の実行時）ことです。



さらなるトレーニングとして、カスタムファームウェア開発者は、このタイプのイメージの内部構造に精通し、それらと連携するいくつかの側面を明確にすることに興味があると思います...

2.細かく切る（塊）

この方法は、ext4形式の元の画像がborderと呼ばれる所定の値以下の部分に分割されることを意味します。 ほとんどの場合、 境界の値は128または256 MBです。 同時に、逆回復のために、元のイメージ内のこれらの部分の場所を記述するいわゆる配置ファイルが追加で作成されます。



パーティションイメージをパーツに分割するプロセスは、次のアルゴリズムで説明できます。

1. 次の基準を満たす必要がある境界値が選択されます。
   
   
   
   
   • FSブロックサイズの倍数。
   • OTA更新またはfastbootモードでのダウンロード中に転送するための許容ファイルサイズを超えないでください。
2. セクションの画像はRAW形式で表示され、 境界を超えないサイズの部分に分割されます。
3. 出力ピース（チャンク）は、特別な規則に従って各パーツから形成されます。
   
   
   
   
   • 問題のピースにほとんどゼロ以外のデータが含まれている場合、出力ピース（タイプ1チャンク）に完全にコピーされます。
   • 問題のピースにゼロのデータのみが含まれる場合、出力ピースのサイズはゼロで構成される1ブロックのサイズになります（タイプ2チャンク）。
   • 問題の断片に少しの情報と多数のゼロデータが含まれている場合、出力断片には情報部分（タイプ3チャンク）のみが含まれます。
   • 任意のタイプのピースのサイズは、常にブロックのサイズの倍数です。
4. 切断プロセス全体がファイルの場所に書き込まれます。 ピースの名前、ファームウェアのオフセット、および作成されたピースに対応する元の入力ピースのサイズが属性として保存されます。

パーティションイメージのこのようなパーティション分割の後、ゼロデータのクリッピングにより、ピースの長さの合計が大幅に減少します。 出力ファイルの合計サイズ。



回復プロセスは非常に簡単で、次のアルゴリズムに従って実行されます。

• 元のサイズの新しい空の画像が作成されます。
• 次に、ロケーションファイルからの情報に従って、ピースが順番に読み取られて配置されます。

たとえば、rawprogram0.xml配置ファイルを含むQualcomm MSM8916プロセッサー[2]に基づくLenovo s90のファームウェアを使用して、元のパーティションイメージを復元するプロセスを見てみましょう。 また、部品の「境界線」に、クアルコムは128 MBの値を採用しました。



rawprogram0.xml配置ファイルはxmlファイルであり、引用元は以下のとおりです。

<?xml version="1.0" ?> <data> <!--NOTE: This is an ** Autogenerated file **--> <!--NOTE: Sector size is 512bytes--> ... <program ... filename="cache_1.img" label="cache" ... start_sector="6193152" /> <program ... filename="cache_2.img" label="cache" ... start_sector="6455296" /> <program ... filename="cache_3.img" label="cache" ... start_sector="6455496" /> <program ... filename="cache_4.img" label="cache" ... start_sector="6717440" /> ... </data>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

厳密に言えば、これはQualcommチップメモリ​​レイアウト記述ファイルです。 このファイルのすべてのパラメーターについては説明しません。 必要なものは次のとおりです。

• filename-ファイル名。
• label-セクションラベル。
• start_sector-メモリ内のファイルオフセット。512バイトのセクターで表されます。

filenameパラメーターは、画像またはその一部を含むファイルの名前を指定し、そのラベルはlabelパラメーターで表されます。



start_sectorパラメーターには、MUのメモリ内のファイルの先頭のABSOLUTEオフセットが含まれます。



なぜなら パーツファイルをメモリにフラッシュせず、セクションイメージファイル全体を収集するだけです。このイメージファイル内の各パーツの配置には、相対オフセットを使用する必要があります。 ベースは、特定のセクションの画像の始まりです。 MUのメモリ内の画像オフセット。 計算は、次の式に従って実行されます。

相対オフセット= Abs.partition_partitionオフセット-Abs.partition_partition_offset

ファームウェア本体には、ext4ファイルシステムを含むいくつかのファイルが含まれています。

• 4つの部分で構成されるcache.img （cache_1.img-cache_4.img）;
• 6つの部分で構成されるpreload.img （preload_1.img-preload_6.img）;
• system.imgは 、29の部分で構成されています（system_1.img-system_29.img）。

キャッシュパーティションイメージの構築を試みましょう。 部品cache_1.img-cache_4.imgから、1つのcache.imgファイルを収集します。 具体的には、上記のrawprogram0.xml配置ファイルから次の値を選択します。

• キャッシュセクションの開始の絶対オフセット-6193152。
• キャッシュイメージの最初の部分の先頭にはそれぞれ6193152の絶対オフセットがあり、相対オフセットはゼロです。
• 2番目の部分6455296の開始、それぞれ相対オフセット262144。
• 第3部分6455496の開始、それぞれ相対オフセット262344。
• 第４部分６７１７４４０の始まり、それぞれ、相対オフセット５２４２８８。

復元するには、次の手順を実行します。

• 16進エディターで最初の部分を開きます。 ファイルcache_1.imgおよびアドレス0x0404のuint32型の値を読み取ります。これは、ブロックで表されるキャッシュセクションのext4型のFSイメージのサイズです。 図1では、赤でマークされています。
  
  
  
  
  
  図1。 キャッシュパーティションのイメージサイズ
  
  
• タイプext4、サイズ0x010600ブロックのFSを含む新しい空のファイルを作成します。 0x010600 * 0x1000 = 0x010600000（274 726 912バイトまたは262MB）、cache.imgと呼びます;
• 最初の部分の内容全体をコピーして、上記で計算した相対オフセットから始まる新しいファイルに貼り付けます。 0x0000;
• ファイルの次の部分を含むファイルを開きますcache_2.img。
• この部分の内容全体をコピーして、上記で計算した2番目の部分（262144）の相対オフセットからも作成したファイルに貼り付けます。
• cache.imgファイルの他のすべての部分について、優先順位を指定して前の2つの手順を繰り返します。

すべての手順を完了すると、サイズが262MBのファイルcache.imgを受け取ります。これには、FSタイプext4の形式のキャッシュパーティションのイメージが含まれています。

3.画像の圧縮

パーツに分割すると、開発者の問題が部分的に解決され、ファームウェアまたはアップデート中の転送セッション中に転送される1つのパーツのサイズが小さくなります。 ただし、ファイルの合計サイズは変わりません。



画像のサイズを縮小する問題は、圧縮（エンコード）することで解決できます。 これを行うには、次の方法を使用します。

• Raw形式のファイルをスパースファイルに変換します。
• Raw形式ファイルを_sparsechunkファイルに変換します。

たとえば、LenovoのMoto Gデバイスではスパースファイルが積極的に使用され、 Moto Zでは_sparsechunkファイルが使用されます。

3.1。スパースファイル

パーティションイメージの数が90％に達する可能性のある「空の」値を削除するには、イメージ自体を[3]で説明されているスパースタイプのファイルに変換（圧縮）します。 この場合、ソースファイルは4バイトの数値を表す要素の配列と見なされ、配列はブロックごとに表示されます。 4096バイトまたはそれぞれ1024要素。



コンテンツに応じて、ブロックは次のタイプに分類されます。

• 繰り返し要素を持つブロック、つまり ゼロまたは同じ（繰り返し）要素を含む、つまり ブロックを埋めます。
• 情報要素を持つブロック、つまり ブロック全体に異なるデータを含む、つまり 生ブロック。

3.1.1スパースファイルの構造

スパースファイルへの変換後のFSパーティションのスパースイメージは、 Raw 型とFill型の断片のシーケンス（リスト）であり、それらは散在しています。 逆変換（イメージリカバリ）を識別して保証するために、これらすべてにヘッダーが追加されます。



したがって、 スパースファイルは以下で構成されます。

• ファイルヘッダー。
• データ領域 ピースのリスト。

Raw形式の画像をsparseに変換する場合、2種類の断片のみが使用されるという事実にもかかわらず、4種類の断片の断片があります。これについては以下で説明します。

スパースファイルヘッダー

ヘッダーの構造は次のとおりです。





図2。 スパースファイルヘッダー



すべてのヘッダーフィールドについて簡単に検討します。



4バイトの長さのMagicフィールドには署名（数字0xed26ff3a）が含まれ、 スパースファイルをファイルタイプとして識別するために使用されます。



メジャーバージョンとマイナーバージョンのフィールドは2バイト長で、 スパースファイル形式のバージョン番号が含まれています。 現在、バージョン1.0です。



FileHeaderSizeフィールドの長さ2バイトには、 スパースファイルヘッダーのサイズがバイト単位で含まれています。 現在、ヘッダーには2つのバージョンがあり、サイズのみが異なります：0x1C（28）バイトと0x20（32）バイト。 したがって、このフィールドには数値または0x1C、または0x20も含まれます。



2バイトのChunkHeaderSizeフィールドには、 スパースファイルの断片のヘッダーのサイズが含まれています。 ピースのタイプに関係なく、番号0x0C（12）が含まれます。



4バイト長のBlock_Sizeフィールドには、 スパースファイルのブロックサイズが含まれています。 ext2-ext4タイプのFSイメージをスパースファイルに圧縮するには、このフィールドの値は0x1000（4096）です。



4バイト長のTotal_Blkフィールドには、ソースファイル（img）のサイズがブロック単位で含まれています。



4バイト長のTotal_Chunksフィールドには、ソース（入力）ファイルが分割された部分の数が含まれています。 同じ数の断片が出力ファイルに含まれています（ スパース ）。



Image_Checksumフィールドには、ファイル全体（ヘッダー+データ）に対してCrc32アルゴリズムによって計算された出力ファイルデータ（スパース）のチェックサムが含まれます。

スパースファイルピースのデータ領域の構造

ヘッダーに続くのは、 スパースファイルの断片のリストで構成されるデータ領域です。



各ピースには、ピースヘッダーとピースデータがあります。



スパースファイルヘッダーのChunkHeaderSizeフィールドに示されているように、ヘッダーの長さは0x0C（12）バイトで、次のフィールドが含まれています。





図3。 ピースヘッダー構造



2バイトのChunk_Typeフィールドにはピースの識別子が含まれ、次の値を取ることができます。

• 0xCAC1-繰り返しのないデータを保存するために設計されたRaw型のピース。 チャンクサイズは、バイト単位のデータ量+チャンクヘッダーのサイズに等しくなります。
• 0xCAC2-タイプFillは、入力データの繰り返し部分を記述し、エンコードされた形式でゼロまたは繰り返しデータを含みます。 チャンクサイズは、ヘッダーのサイズ+プレースホルダーあたり4バイトに等しくなります。
• 0xCAC3-タイプDontCareの一部にはデータがまったく含まれていません。 チャンクのサイズは、チャンクヘッダーのサイズです。 12バイト。
• 0xCAC4-タイプCrcには、Crc32アルゴリズムに従って計算されたファイルのチェックサムが含まれます。 チャンクのサイズは、ヘッダーのサイズ+チェックサム値ごとの4バイトです。

2バイト長の予約フィールドは使用されず、常にゼロです。



4バイト長のChunk_Sizeフィールドには、入力ファイル（img）内のソースチャンクのサイズがブロック単位で含まれています。



4バイト長のTotal_Sizeフィールドには、出力スパースファイルの受信ピースのサイズがバイト単位で含まれています。 計算時には、ヘッダーの長さとピースデータの長さの両方が考慮されます。



ヘッダーに続くデータは、ピースのタイプによって異なるデータです。



なぜなら rawタイプは、繰り返しのないデータを保存することを目的としています。ピースのデータは、入力ファイルの対応する部分のデータと完全に一致します。 以来最大のサイズを持っています データの量は、選択された境界の値に達する可能性があります。



Fill as dataには、入力ファイルの対応する部分で繰り返される1つの4バイト数（4バイトのプレースホルダー）のみが含まれます。 これらの重複データが占める領域全体を、それらをリストせずに置き換えます。これにより、圧縮が行われます。



データとしてのタイプCrcのピースには、ピースのすべてのデータのCrc32アルゴリズムに従って計算されたピースのチェックサムが含まれます。



例外はタイプDontCareの一部で 、これにはデータがまったく含まれていませんが、 Chunk_Sizeフィールドにはまだデータが入力されています。 入力ファイル内の次のデータの先頭へのポインター（オフセット）です。

3.1.2スパースファイルアルゴリズム

スパースファイルを操作する場合、「生の」imgファイルのスパースファイルへのエンコードと、 スパースファイルのソースファイルへのデコードが実行されます。



スパース形式セクションの入力Raw画像のエンコードは、次のアルゴリズムに従って実行されます。

1. セクションの入力画像はブロックごとに表示され、各ブロックのタイプが決定されます。
2. 同じタイプの実行中のブロックはグループ化されます。 現在のグループは、ブロックタイプの変更が発生して新しいグループが開始されると終了します。
   
   
   
   契約実行中のFillブロックは、 Fillグループに結合されます。 これは、同じグループ内で同じでなければならない繰り返し値を考慮します。 次に来るFillブロックに別の繰り返し値がある場合、新しいFillグループが作成されます。
   
   
   
   Rawブロックになる契約は、 Rawグループに結合されます。
3. 受信したすべてのグループは、 スパース形式ファイルのチャンクに変換されます。 この場合、非反復データを含むRawグループは、変更なしでRawピースのデータ領域に完全にコピーされます。 また、 Fill- group全体がFillタイプの1つのピースに置き換えられ、このピースのデータ領域に1つの繰り返し要素が含まれます。
4. スパースファイルのヘッダーが読み込まれます。

スパースファイルの元の画像へのデコードは、次のアルゴリズムに従って実行されます。

1. 新しい空のファイルが作成され、そのサイズはスパースファイルヘッダーのTotal_Blkフィールドから取得されます。
2. スパースファイルのデータ領域からのリストの各部分は、アドレス0x0000で始まる出力ファイルを順番に埋めて、順次デコードされます。 この場合、作品のタイトルが読み取られ、次に：
   
   
   • 生のチャンクデータは、入力ファイルから出力に完全にコピーされます。
     
     この場合、入力ファイルの読み取りポインターと出力ファイルの書き込みポインターは、コピーされたバイト数だけ移動します。
   • タイプがFillの場合、フィラー要素はTotal_Sizeにコピーされ、4で割られます。
     
     この場合、入力ファイルの読み取りポインターは4バイトのプレースホルダーに移動します。 出力ファイルの書き込みポインターは、プレースホルダーが占有するバイト数に移動します。
   • タイプDontCareのチャンクの場合、入力ファイルの読み取りポインターは移動せず、出力ファイルでは、書き込みポインターはチャンクのChunk_Sizeフィールドで指定されたバイトブロックの数に移動します。

3.1.3スパースファイルの使用例

スパースファイルを使用する場合、次の2つの質問がよく発生します。

• スパースファイルから元のイメージを復元する方法
• ソースイメージをスパースファイルに変換する方法

入場に従ってそれらを検討してください...

スパースファイルから元のイメージを復元する方法

例として、Lenovo Moto Z MUのスパースファイルからoemパーティションイメージを復元するプロセスを検討します[4]。 すべてのアクションは、WinHexなどの16進エディターを使用して実行されます。



圧縮されたoemパーティションイメージを含むoem.imgソースファイルのサイズは69MBです。 タイトルを見てみましょう：





図4 Moto Zヘッダー



アドレス0x0000から、ファイルがスパースファイルタイプであり、断片で構成されていることを示すファイル署名があります。 署名は青色でマークされています。



次に、スパースファイルバージョン（1.0）を含むフィールドが緑色で強調表示されます。



次に、 FileHeaderSizeフィールドとChunkHeaderSizeフィールドが赤で強調表示され、それぞれファイルヘッダーのサイズ（0x001C）とピースヘッダーのサイズ（0x000C）が含まれます。



オフセット0x000Cには、スパースファイルのブロックサイズを示すBlock_Sizeフィールドがあります。 ブロックサイズの値は0x00001000です。



オフセット0x0010には、 Total_Blkフィールドがあり 、ブロック単位のソースファイルのサイズが含まれています。 黄色で強調表示され、値は0x0000021です。



オフセット0x0014に、 Total_Chunksフィールドがあり 、スパースファイルに含まれるピースの数が含まれています。 紫色で強調表示され、値は0x0000001Fです。



オフセット0x0018には、スパースファイルのチェックサムを含むImage_Checksumフィールドがあります。 このフィールドには0が含まれます。つまり、CSが計算されず、このファイルをMUのメモリにロードするときに考慮されません。



アドレス0x001Cから開始して、スパースファイルの最初の部分のヘッダーがあります。





図5。 作品タイトルCAC1



Chunk_Typeフィールドには、青で強調表示された値0xCAC1が含まれていることがわかります。 次の2バイトは空で、 Chunk_Sizeフィールドは赤でマークされ、ピースにエンコードされた入力ファイルのブロック数（0x00000001）が含まれています。



次はTotal_Sizeフィールドで、ピースの長さとヘッダーをバイト単位（0x0000100C）で表示します。 緑色で強調表示されます。 ヘッダーのないサイズが常に必要なので、データのみの長さは0x100C-0x000C = 0x1000です。



アドレス0x0028から始まるヘッダーの直後に、ピースデータの配列があります。



したがって、元のイメージを復元するには、次の手順を実行します。

• 16進エディタでソーススパースファイルoem.imgを開きます。
• ファイルヘッダーからフィールド値を選択し、サイズの新しい空のファイルを作成します
  
  

   Total_Blk * Block_Size = 0x000C021 * 0x1000 = 00C021000  (192)
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  oem_ext4.imgなどの名前で保存します。
• 最初のピースの処理に進みます。
• そのタイプはCAC1なので、データ配列（サイズ0x1000のオフセット0x0028から開始）をコピーし、生成された出力ファイルに貼り付けます。
• 次の作品に進みます。 そのタイプはそれぞれCAC2、プレースホルダーは0xFFFFFFFF、プレースホルダーの数は0x1Dブロックです。
  
  
  
  
  
  図6。 CAC2の2番目の部分
  
  
  
  作成されたファイルにプレースホルダーを挿入します
  
  

   0x001D * 0x1000 = 0x01D000  118784 
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

• 等 説明した手順を実行して、ソースファイルの最後までピースをデコードします。

結果は、タイプext4、サイズ192MBのファイルシステムを含むファイルです。

ソースイメージをスパースファイルに変換する方法

簡単にするために、新しく取得したoem_ext4.imgイメージを取得し、 スパースファイルに変換しようとします。 この場合、サイズ0x001C（28）バイトの新しいファイルを作成し、 スパースファイルのヘッダーをその中に配置してから、ソースファイルを順番に表示し、断片に分割してエンコードし、作成されたすべてのスパースバイトを新しいファイルに配置する必要があります。 そしてもちろん、たとえばoem_sparse.imgという名前で新しいファイルを保存します。



ファイルヘッダーを入力するには、最初の4バイトにスパースファイルの署名を入力します。





図7。 スパースファイルヘッダー



次に、値を書き留めます。

• スパースファイルのバージョン番号（4バイト必要）：
  
  
  
  
  
  図8スパースファイルのバージョン番号
  
  
• スパースファイルヘッダーサイズ（2バイト）：
  
  
  
  
  
  図9スパースファイルヘッダーサイズ
  
  
• ピースヘッダーサイズ（2バイト）：
  
  
  
  
  
  図10タイトルのサイズ
  
  
• バイト単位のブロックサイズ（4バイト）：
  
  
  
  
  
  図11ブロックサイズ
  
  

残りのフィールドは無料のままにします それらの値は、出力ファイルの最終作成後にのみ表示されます。



それでは、コーディングの方法、つまり さまざまな種類のピースを作成します。

あらゆるタイプのピースにはヘッダーがあります。 したがって、まず最初に作成します。16進エディターでサイズが12バイトのファイルを作成します。





図12ブランクピースのタイトル



次に、どのように、何をピースに記入するかを検討します。



生スライス

ヘッダーの最初の2バイトに、そのタイプ（CAC1）を記述します。





図13ピースCAC1のタイプ



次に、ブロック単位で表されるデータサイズ（0x00000001）を挿入します。





図14ブロック単位のサイズ



そして最後に、バイト単位のピースのサイズ（0x0000100C）、つまり ヘッダー長+データ長：





図15ピースサイズ1



ヘッダーの後に、データを挿入します。 ソースファイルの0x1000（4096）バイト：





図16個のデータ1



次の作品の作成に移りましょう。



フィルタイプピース

ヘッダーの最初の2バイトに、そのタイプ（CAC2）を記述します。





図17ピースCAC2のタイプ



ブロックで表されるピースデータのサイズ（0x001D）を挿入します。





図18ブロック単位のサイズ2



ピースのサイズをバイト単位（0x0010）で挿入します。 ヘッダー長+データ長：





図19ピースサイズ2



ピースデータを追加します。 CAC2の場合、これはプレースホルダー（0xFFFFFFFF）です。





図20ピース2のデータ



次の作品の作成に移りましょう。



DontCareスライス

ヘッダーの最初の2バイトに、そのタイプ（CAC3）を記述します。





図21ピースCAC3のタイプ



ヘッダーのアドレス0x0004で、ブロックで表された次のピース（0xxxxx）にオフセット値を挿入します。



ピースのサイズをバイト単位（0x000C）で挿入します。 ヘッダーの長さだけ このデータ型の一部には、アドレス0x0008にヘッダーがありません。





図22ピースサイズ3



次の作品の作成に移りましょう。



Crcタイプスライス



ヘッダーの最初の2バイトに、そのタイプ（CAC4）を記述します。





図23ピースCAC4のタイプ



ブロックで表されるピースデータのサイズ（0x001D）を挿入します。





図24ブロックのサイズ4



ピースのサイズをバイト単位（0x0010）で挿入します。 ヘッダー長+データ長：





図25ピースサイズ4



ピースデータを追加します。 CAC4の場合、これはCRC32アルゴリズムを使用して計算されたチャンクチェックサムです。





図26ピース4のデータ



実際、すべてをボーンでソートしています。 スパース -cusのヘッダーを作成してください。 そしてその直後に必要なデータを追加します。



ソースファイルをスパースファイルにエンコードするプロセスは次のとおりです。

• 16進エディタで0x001Cバイトの出力ファイルを作成し、上記のようにスパースファイルのヘッダーフィールドに入力します。
• 16進エディタでソースファイルを開きます。
• 4096バイト（1ブロック）を調べて、ピースのタイプを判別します。
• 出力ファイルに1型のピースを作成します。
• 次の4096バイト（1ブロック）を見て、ピースのタイプを判別します。
• 出力ファイルに2型のピースを作成します。
• ソースファイルを最後までブロックごとに表示します。 すべてのブロックを断片にエンコードし、出力ファイルに追加します。
• 出力ファイルを調べて、直列に配置された1つのタイプの断片を1つのグループに結合し、別のタイプの断片を別のグループに結合します。 グループには、最初のピースから1つの見出しが残り、2つのフィールドの値が調整されます。
  
  
  • Chunk_Size-入力ファイル（img）のソースピースのグループの合計サイズ。ブロックで表されます。
  • Total_Size-出力スパースファイルの受信グループのサイズ（バイト単位）。
• ソースファイルのサイズをブロックのヘッダーのTotal_Blkフィールドに追加し、ピースの数をファイルヘッダーのTotal_Chunksフィールドに追加します 。

継続するには...

3.2._sparsechunkファイル

4. datファイルの作成

5.情報​​源

1. 「スパースファイル」 。

2. 「s90-a_row_s125_141114_pc_qpst-ファームウェア」 。

3.system / core / libsparse / sparse_format.h

4. 「Lenovo Moto Zのファームウェア」 。

5. Victara_Retail_China_XT1085_5.1_LPE23.32-53_CFC.xml.zip-Lenovo Moto Xデバイスのファームウェア。