Guest User

Untitled

a guest
Nov 6th, 2013
566
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. The sbtoc (superbundle/table of contents) format has a new way of handling patched cascat files.
  2. Previously, the sbtoc did not contain any patch specific info. The most sensible approach was to
  3. check if the archives were located in the Update folder and use the patched cascat in that case.
  4. Now however the sbtoc contains metadata to handle a rather wide range of different types of patches.
  5.  
  6. Unchanged from the previous format is the cas flag (found in the toc) which states that all bundles
  7. inside the sb corresponding to the toc have their assets stored in the cascat archives.
  8. If the flag does not exist or is set to false, the assets are instead directly stored in the sb file.
  9.  
  10. For a cas-enabled sbtoc, the toc does now give additional metadata for every single bundle.
  11. Each patched bundle may have either a base or delta flag.
  12.  
  13. If the base flag is set (for the bundle), then the entire bundle does not require any patching. Note that the game
  14. apparently relies on the patched files only, which then make references back to the unpatched files.
  15. The sbtoc in the Update folder contain all the necessary info to retrieve files from the unpatched archives.
  16.  
  17. If the delta flag is set (for the bundle), then a casPatchType is specified for each
  18. file within the bundle, which may take one of three values:
  19. casPatchType 0 has the sha1 in the unpatched cat.
  20. casPatchType 1 may have the sha1 in either the unpatched or the patched cat.
  21. casPatchType 2 has the base in the unpatched cat and the delta in the patched cat.
  22.  
  23. If the type is not specified, assume type 0.
  24.  
  25. casPatchType 2 defines two more variables, baseSha1 and deltaSha1, which specify the
  26. sha1s of the unpatched (base) file in the unpatched cascat and of the delta file
  27. in the patched cascat. The delta file contains the info to patch the base file.
  28.  
  29. Note that an ordinary (third) sha1 is still specified. That sha1 belongs to the compressed
  30. patched file. This is rather odd because the patching process is applied to the
  31. decompressed file. As both the base sha1 and delta sha1 are given though, there is
  32. no way to bypass file integrity checks (assuming there are any).
  33.  
  34.  
  35. casPatchType 2 in detail:
  36. The operations described in the delta file rely on the individual LZ77 blocks.
  37. It is not possible to decompress the base completely and then apply the patch,
  38. nor is it possible to apply the patch to the compressed base file.
  39.  
  40. A typical delta file contains several blocks with no global header.
  41. The file is in big endian.
  42.  
  43. Each block starts with:
  44. 0.5 bytes deltaType
  45. 3.5 bytes deltaBlockSize/blockCount
  46.  
  47. The 3.5 bytes specify a blockCount for all deltaTypes except type 2 (which is the most common type).
  48. I've sorted the types by frequency of occurence.
  49.  
  50. deltaType 2:
  51. (This type contains information about lots of small changes, usually less than ff bytes,
  52. which are applied to the base block to obtain the patched block.)
  53.  
  54. In the base file, decompress a single block. Hereafter, when talking about
  55. the base block I mean the decompressed base block. The compression is of no importance.
  56.  
  57. In the delta file, read 2 bytes: The expected size of the resulting patched block.
  58. Add 1 to obtain the actual size, so e.g. ffff becomes 10000.
  59.  
  60. In the delta file, read all operations belonging to this delta block.
  61. Its size is given by deltaBlockSize (note that the previous bytes do not count towards the size).
  62. Each operation has this structure:
  63. First come 4 bytes:
  64. 2 bytes offset
  65. 1 byte skipCount
  66. 1 byte addCount
  67.  
  68. Write parts of the base block to the patched file until
  69. the offset given above is reached in the base block.
  70.  
  71. In the base block, proceed the position by skipCount bytes.
  72. Those bytes must not appear in the patched file.
  73.  
  74. Read addCount bytes from the delta file and add them to the patched file.
  75.  
  76. Finally, read as many bytes necessary from the base block
  77. until the patched file size equals the expected size (as read from the delta file).
  78.  
  79. deltaType 1:
  80. (This type is contains information about larger changes made to the file.
  81. The delta itself contains LZ77 blocks which are decompressed and used to
  82. substitute large chunks of the base block.)
  83.  
  84. In the base file, decompress a single block.
  85.  
  86. Iterate blockCount times doing the following:
  87. Read 4 bytes from the delta file:
  88. 2 bytes offset
  89. 2 bytes skipCount
  90.  
  91. Write parts of the base block to the patched file until
  92. the offset given above is reached in the base block.
  93.  
  94. Read one LZ77 block in the delta file and add it to the patched file.
  95.  
  96. In the base file, proceed the position by skipCount bytes.
  97. Those bytes must not appear in the patched file.
  98.  
  99. Finally, add all remaining bytes of the base block to the patched file.
  100.  
  101. deltaType 0:
  102. In the base file, decompress a number of blocks (given by blockCount)
  103. and add them to the patched file directly.
  104.  
  105. deltaType 3:
  106. In the delta file, read a number of LZ77 blocks (given by blockCount) and add them to the patched file.
  107. This is the only operation which does not depend on the base file at all.
  108.  
  109. deltaType 4:
  110. In the base file, skip this number of blocks entirely, i.e. move past them
  111. but do not add them to the patched file.
RAW Paste Data