This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=342

flipperbw, posted Tue Nov 04, 2014 6:19 pm (1488)

---

Hi there! I messaged you on twitter a while ago about the headers on some of these files being just slightly off. For every file I extract, I have to go in and manually change anywhere from 10-40 header bits to get the file to work correctly. Here is an example of what I'm talking about:

Starting with file SAMPLE.unity3d, I run

Code:

./quickbms unity_old.bms SAMPLE.unity3d

Where unity_old.bms is http://aluigi.altervista.org/papers/bms ... player.bms. This produces one file, since it seems to just be a wrapper: SAMPLE.unity3d_unpacked/CAB-SAMPLE.

I inspected that file, which is the *actual* unity bundle, and it is perfectly fine header-wise. There is no issue there. The problem comes in the next step, where I try to get the actual file:

Code:

quickbms -Y -o -f "{}EXAMPLE_OGG_FILE{}" unity_norm.bms SAMPLE.unity3d_unpacked/CAB-SAMPLE

Where unity_norm.bs is the file located here: http://aluigi.altervista.org/papers/bms/unity.bms. This gives me the proper file like this: TYPE_83/EXAMPLE_OGG_FILE

This is all fine and dandy, but that file is just *slightly* off from what I know it should be. Extracting that exact file with a different program (Disunity), the headers are almost, but not quite, the same:

QuickBMS File:

Code:

00000000  02 00 00 00 0E 00 00 00 01 00 00 00 01 00 00 00  ................
00000010  A5 3B 01 00 4F 67 67 53 00 02 00 00 00 00 00 00  ?;..OggS........
00000020  00 00 17 0F 00 00 00 00 00 00 BF BA 80 C2 01 1E  ..........???A..
00000030  01 76 6F 72 62 69 73 00 00 00 00 01 80 BB 00 00  .vorbis.....?>..
00000040  FF FF FF FF 00 F4 01 00 FF FF FF FF B8 01 4F 67  yyyy.o..yyyy?.Og
00000050  67 53 00 00 00 00 00 00 00 00 00 00 17 0F 00 00  gS..............
00000060  01 00 00 00 EB FB 80 09 0F 4E FF FF FF FF FF FF  ....eu?..Nyyyyyy
00000070  FF FF FF FF FF FF FF E8 03 76 6F 72 62 69 73 2D  yyyyyyye.vorbis-
00000080  00 00 00 58 69 70 68 2E 4F 72 67 20 6C 69 62 56  ...Xiph.Org libV
...

Correct File:

Code:

00000000  4F 67 67 53 00 02 00 00 00 00 00 00 00 00 30 7E  OggS..........0~
00000010  00 00 00 00 00 00 18 AD EF 14 01 1E 01 76 6F 72  ........i....vor
00000020  62 69 73 00 00 00 00 01 80 BB 00 00 FF FF FF FF  bis.....?>..yyyy
00000030  00 F4 01 00 FF FF FF FF B8 01 4F 67 67 53 00 00  .o..yyyy?.OggS..
00000040  00 00 00 00 00 00 00 00 30 7E 00 00 01 00 00 00  ........0~......
00000050  D3 DC 03 10 0F 4E FF FF FF FF FF FF FF FF FF FF  OU...Nyyyyyyyyyy
00000060  FF FF FF E8 03 76 6F 72 62 69 73 2D 00 00 00 58  yyye.vorbis-...X
00000070  69 70 68 2E 4F 72 67 20 6C 69 62 56 6F 72 62 69  iph.Org libV
...

Everything after that point is exactly the same. The difference is literally just those initial bytes: 02 00 00 00 0E 00 00 00 01 00 00 00 01 00 00 00 A5 3B 01 00. If I delete them, the OGG file works perfectly fine.

Other types of files have similar issues. Here is an example of a DDS file I attempted to extract:

QuickBMS:

Code:

00000000  00 04 00 00 00 04 00 00 00 00 10 00 0C 00 00 00  ................
00000010  00 00 01 00 01 00 00 00 02 00 00 00 01 00 00 00  ................
00000020  01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000030  01 00 00 00 00 00 10 00 00 00 00 00 00 00 00 00  ................
00000040  46 21 25 21 FF FF FF FF 00 00 00 00 00 00 00 00  F!%!yyyy........
00000050  46 21 25 21 FF FF FF FF 00 00 00 00 00 00 00 00  F!%!yyyy........
...

Correct:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  44 44 53 20 7C 00 00 00 07 10 08 00 00 04 00 00  DDS |...........
00000010  00 04 00 00 00 00 10 00 00 00 00 00 00 00 00 00  ................
00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000040  00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 00  ............ ...
00000050  04 00 00 00 44 58 54 35 00 00 00 00 00 00 00 00  ....DXT5........
00000060  00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00  ................
00000070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000080  00 00 00 00 00 00 00 00 46 21 25 21 FF FF FF FF  ........F!%!yyyy
00000090  00 00 00 00 00 00 00 00 46 21 25 21 FF FF FF FF  ........F!%!yyyy
000000A0  00 00 00 00 00 00 00 00 46 21 25 21 FF FF FF FF  .......
...

This time, it's actually missing the correct header (rather than including more bits as in example 1). When I add the DDS/DXT5 portion, it works fine.

Any ideas here? Thanks so much. It's really annoying to have to edit every single file manually before I can use them, and then convert them back before I can reimport.

aluigi, posted Tue Nov 04, 2014 7:39 pm (1490)

---

The behaviour of the script is correct because what you have in an Unity asset is not a file (or the original file) but you have a resource, so a value that specifies what type of resource and a container or directly the raw data.
In the example of the Ogg file you have a container that probably has information about the channels and similar stuff, while the DDS is headerless.

Probably you want to check Unity Assets Explorer:
viewtopic.php?f=9&t=36

It should give you better access to the resources.

flipperbw, posted Tue Nov 04, 2014 9:15 pm (1493)

---

Mmm, how is DisUnity able to do it then? Those files come out perfectly, with the exception of not being able to inject them back in.

UAE actually doesn't work for me. It hangs forever on the files and misinterprets the length of the data everytime.

aluigi, posted Wed Nov 05, 2014 12:11 pm (1506)

---

Disunity parses the resources, my script simply dumps them.

Regarding UAE post the issue in the thread, Haoose will fix it for sure.

flipperbw, posted Sun Jan 25, 2015 11:24 pm (2911)

---

aluigi wrote:

Disunity parses the resources, my script simply dumps them.

Regarding UAE post the issue in the thread, Haoose will fix it for sure.

Thanks for the help, but I can't seem to get an answer in that thread (been a few months now). Any ideas on who to contact?

aluigi, posted Mon Jan 26, 2015 8:27 am (2915)

---

The authors are AlphaTwentyThree, Haoose and OLEGator84.
Maybe they are busy at the moment.
Anyway upload that CAB file in that thread so that we can take a look at it.
Maybe it's not a sharedasset file and so the program can't read it.

A sample is ever the best way to receive answers, otherwise it's easy to get ignored.