pcmhacking.net

has anyone had luck figuring out what kind of encryption/compression is used on the newer vbf formats? short of disassembling IDA im running out of leads on where to find answers.

Got any examples? I've got a few 2.4 files but they're not encrypted or compressed. They're for 2017-ish.

here is a 2.4 version

Check this out.

I have a command line tool I've been using, and while it extracted your file, it looked like gibberish. Block sizes were weird and there was high entropy. Just like you said. Compressed and/or encrypted.

So I did a little digging and found this. https://github.com/smartgauges/qvbf
Direct link to exe: https://github.com/smartgauges/qvbf/raw ... 2/qvbf.exe

It's Russian, so take it with a grain of salt. But it seems to work. The program output explicitly says it uncompressed the block. The resulting block I extracted is a more normal size (16384 instead of 12979), and I can see plain text data in the boot block referencing SHA1 hashes.

GOOD FIND! it looks like there's lzss decompression going on. ill give it a look and compare against some files i already have for accuracy and report back.

good news it works and seems to match up. bad news the output format is terrible at best. trying to patch together 100+ blocks on some files sounds like a terrible time.

I thought doing 30 on my 2.7 EcoBoost was bad. 100 would be super annoying.

Check out the attachment. I used the Linux cat command to merge them. Took all of 5 minutes, including pre-processing the file list into a text string.

https://stackoverflow.com/questions/103 ... nux-system

I'd recommend spot checking it to make sure I didn't get something out of order. I just used the default order that qvbf spit them out in, so that could be wrong too. I think the overall concept is sound though.

That's a good method, that's how I make stacked bins for other purposes too.