![]() |
Quote:
So, ue4 decrypt with key Code:
0xE01312D26CAD1529142D3ACA6DB25D4091C1AAFE0C91E5DC104C36A768DB1E50Devs were nasty and put videos inside the pak with compression and encryption. Sounds are also encrypted but you should just be able to patch the encrypted data out using QuickBMS + Unreal script to print a filelist which will give you the locations of the different sound banks. |
Quote:
zlib+ue4 Quote:
but i don't know, if use Diskpan GUI @cesar Code:
xtool:c32mb:mue4,k0xE01312D26CAD1529142D3ACA6DB25D4091C1AAFE0C91E5DC104C36A768DB1E50,zlib |
Sackboy: A Big Adventure
AES Key Quote:
|
Quote:
These X64.exe found from "cls_srep_v0.03b.rar" and "ISArcEx v0.4 + Test.rar" files. Two package contains X86 version EXE and not running from XP! Used bytepaching and its is OK! These DLL file, totally missing, some tools available various versions, (UltraArc, MC 20.xx, CIU3.0.x.x or more..) this different, not found the "d30b67ba" CRC-32 hashed copy. UPD: These versions cls filter, not fully stable from cancelling installation process, these X64 (ae1cd4f0) or patched X86 EXE crashing now, from process terminating. Original full EXE or Profrager's DLL its betterly stable. (except not supported compression methods in get decompression error.) Its probably incorrect CLS-SREP.dll file attached in the "ae1cd4f0" hashed X64 EXE file in some repacking tools archives. Checked my DVD's from any archived repacking tools, not found! The DLL its available in many recompressor package tools sets? |
Sackboy: A Big Adventure
*.pak - ue4d+xtool(zlib)+srep+lolz 53 > 54 gb > 41 gb > 22.6 gb *.mp4, *.avi - srep+lzma2 860 mb - 697 mb Rest files - srep+lolz Repack size - 23.3 gb Install time - ~10 min. (hdd>hdd) |
1 Attachment(s)
Quote:
Beware, the file is 300mb in size, so open it could take a while |
^^
You can use -f filter in quickbms so it will only list files that you want. e.g. Code:
QuickBMS -l -f *.pck <bms> <pak> >> filelist.txt |
Quote:
im not sure what or you did but i didnt get anywhere close to 30.8 GB my repack was 39.0 GB i used this method: ue4d:key=E01312D26CAD1529142D3ACA6DB25D4091C1AAFE0 C91E5DC104C36A768DB1E50+xtoolx+srep+lolz <- xtoolx in this cause was unreal.dll thanks ScOOt3r |
Quote:
|
Quote:
*.pak - ue4d+xtool(zlib)+srep+lolz |
Quote:
Code:
Compressed 20 files, 56,772,706,885 => 57,575,115,762 bytes. Ratio 101.41%Code:
xtool:c32mb:mzlib:d1:mue4,k0x27BCD9AE811EBB70D80F7B9098CCE4267CFFA18E14058BC2E59E8898E0E9AA9C |
Call of Duty Modern Warfare 2 Remastered
*.ff, *.fp, *.xsub -> kraken (use oo2core_8) |
American Truck Simulator [v.1.45.3.26s + All DLCs]
Code:
xzlib+srep+lolzUse -lm due to incredibly huge streams being decompressed. I have 64GB of memory so I used a 1024mb chunk size. 10.7GB ----> 6.1GB |
Divinity Original Sin 2 Definitive Edition
v27.09.2022, Nothing ripped, bonus contents are included (Artbook, Lorebook, Concept Art, Soundtrack) Code:
18:42:24 - Selected ARC/DS method for Data1a-01.bin was: xtool:mdos2de:mpreflate+srep_new:3+lzma_sdkHowever not all lz4 streams can be processed. To get a good amount of streams set --diff=20p in arc.ini (the sweatspot is somewhere between 15p and 20p, I used 20p. Above this you will get negative ratios on some files. The higher #p, the more negative ratio) and use xdelta3_dll.dll near xtool.exe Due to false detection by xtool use preflate, not reflate. If you use reflate you will get crc errors on extraction. For xtl creation use lspk.bms and in bms2xtl.ini set lz4=lz4hc:l9 Use liblz4 180 bpk information Code:
Data1c |
Quote:
srep+lolz = 6.6 gb Xtool(LZ4 + xtl db)+srep+lolz = 6.4 gb :D |
WRC Generations - The FIA WRC Official Game
lz4f,l10 CHUNK_1.PKG Code:
Compressed 1 file, 230,225,845 => 356,636,013 bytes. Ratio 154.91% |
The Entropy Centre
zlib. There is a key but however it seems you don't need it at all. |
Are you sure?:confused:
Code:
xtool:reflate:d1:ue4,k0x72463A7B70FA819E286295CF74C280AC7C928D0BCB349CF811CAF1AE27780A41 |
|
Maybe it's the xtool plugin. I will test with ue4d
|
Quote:
xtool(zlib)+srep+lolz - 7.83 GB ue4d+xtool(zlib)+srep+lolz - 7.92 GB Code:
zlib |
Sorry for that mix up and thanks for the corrections KaktoR and Waterlude :p
|
HARVESTELLA
kraken+zlib+ue4 key Quote:
Quote:
|
Sackboy: A Big Adventure (2nd repack)
*.pak - XTool v0.65 + unreal.dll + SREP + LOLZ Quote:
Quote:
|
Burnout Paradise Remastered
-mxzlib+srep+fl2 Code:
Compressed 8,468 files, 7,752,954,658 => 3,415,874,982 bytes. Ratio 44.06%Need For Speed Hot Pursuit Remastered -m0 Code:
UI\MOVIES-mxzlib+srep+fl2 Code:
Compressed 20,498 files, 15,721,041,999 => 3,315,144,330 bytes. Ratio 21.09%34.8 GB >> 23.2 GB w/ 4K videos 22,2 GB >> 10.7 GB w/o 4K videos |
DOOM Eternal
I made some tests but couldn't find the correct oodle library. Maybe someone find this usefull. gameresources_0_2.streamdb Code:
oo2core_4_win64_v3 712/1283 Ratio 126.48% |
1 Attachment(s)
Doom Eternal uses two libraries on this file however I'm not sure if this applies to the whole game.
oo2core_7_win64.dll -> 283 MB > 421 MB (691/1332) oo2core_8_win64.dll -> 283 MB > 479 MB (790/1332) For some reasons, streams that can be processed 7 cannot be processed by 8 and visa versa. However if you precompress the game using both libraries one after the other you get 283 MB > 421 MB > 614 MB The second pass using oo2core_8_win64.dll processed the remaining streams (640/640). This is part of the reason I added --oodle= parameter in xtool, to allow you to specify exactly what library you want to use. Code:
[External compressor:doom7]-mdoom7+doom8 |
1 Attachment(s)
HARVESTELLA
Code:
09:53:02 - Selected ARC/DS method for Data1a-01.bin was: xtool:mue4,k0xAA07B9EF2AD5A0F2C1299355B0760B2808F11038753D5959D5CA0923A6EE44A5:mkraken,l5:9+srep+4x4:lzmaPS: You can use reflate on pak file to get additional ~20mb inflation. |
Elden Ring is also one more game that uses 2 different oodle libraries to have 100% coverage of streams.
its best to create a massive batch to process combinations of libraries |
Quote:
|
Quote:
Code:
v2.8.14Code:
200 -> 355 -> 366Code:
v2.8.14 |
F.I.S.T.: Forged In Shadow Torch
Tests XZlib+Reflate (-d3 -c32mb) 21.2 gb > 39 gb unreal.dll+Xzlib+Reflate (-d3 c128mb) 21.2 gb > 65 gb AES Key Code:
0xEABBDBD5A27C73D8CDAE3179A36C9EB793C3C61188A5763FBC35ACD155D0C604 |
Halo Infinite
Winter Update (8th November 2022) Code:
14:02:46 - Selected ARC/DS method for Data1a-01.bin was: xtool:mkraken,l4,n64:8+srep+4x4:lzma |
ELDEN RING
v1.07 Code:
09:30:58 - Selected ARC/DS method for Data1a-01.bin was: xtool1+xtool2+srep+4x4:lzmaxtool options: l6,n64 |
Does anyone know how BMP detection under MSC works? Got a few titles I'm working on that mainly use BMP images for texture assets, however MSC seems to skip over the majority of files. I had a brief trawl through some posts here but searching with shorter search terms is a massive pain in the arse and didnt yield a lot of information.
|
Maybe the thread on Krinkels.org may help you?
|
Saints Row (2022)
v1.1.6.4392638 Code:
21:38:42 - Selected ARC/DS method for Data1a-01.bin was: xtool:mlz4f,l9:lz4_192+srep+4x4:lzma |
Wolfenstein II The New Colossus
Code:
15:56:42 - Selected ARC/DS method for Data1a-01.bin was: xtool:mkraken:5+srep+4x4:lzma- Majority of *.resources files using level 4, majority of *.texdb and *.cache using level 5. I was too lazy to sort them out properly so I didn't use the l# option for xtool. - On many files I didn't got all kraken streams, I checked with every library I have and even used different libraries with --oodle= option like with Elden Ring but to no avail. - *.pages files using lz4hc but most likely weak compression, but couldn't get all streams (overall about half of streams), so I decided to just compress them with srep+lzma. |
Somerville (Steam version)
*.wem, *.bnk - srep+razorMT 6.3 gb> 1.6 gb Rest files - srep+lolz 3.7 gb > 430 mb Install time - 1 min. |
Unlike it's original variant, paks in Crysis 3 Remastered are not encrypted. They are just standard zip files and can be precompressed with xtool:
Code:
Compressed Animations.pak, 144,174,121 => 229,174,364 bytes. Ratio 158.96% |
| All times are GMT -7. The time now is 08:57. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
FileForums @ https://fileforums.com