Need help altering an existing BMS script (Breakers)

[phoutem]

I've some interest in datamining a game, and I had good luck using a BMS script to do so for an Android Beta test.
Originally a request was made here: viewtopic.php?f=9&t=7294&hilit=breakers and the resulting functional bms was kindly provided by aluigi here: http://aluigi.org/bms/breakers_sxr.bms

Seeing as this game became available in the switch e-shop as f2p, and upon extracting the archives, the .sxr files are all there, minus a "sakana.proj" file which initially existed on the android version. In it's place are some other new files, also .sxr, but essentially most of the files are the same upon comparison in a hex editor. To my knowledge, both android and switch have the same architecture, so I figured i might try to edit a bit of the script, maybe it was as simple as finding the starting offset, but I have had no luck with it so far with my limited knowledge of deflating archives.

I have all the new .sxr files here https://drive.google.com/open?id=1de-_W ... TO9oYA6HCa in the romfs folder. I'm already aware that the files are numbered and unnamed, the only thing the archive specifies for are path folders, but that is unnecessary to me. I'd appreciate any advice or help on this, as I want to datamine the extracted files for the purpose of creating a fleshed out wikipedia with the finer details of the current release.

Thanks for your input, anyone, if you are able to assist.

[aluigi]

I suspect the files are encrypted since both data and files information are garbage, while the header is valid.

[phoutem]

Thanks for the quick reply aluigi, I really appreciate it!

Ok, so I know I did the legwork in extracting the files from the encrypted nsa file, so now you are telling me the actual scala archive files (the .sxr) are either further encrypted or have a compression scheme in place?

If so, since the header is valid, there should exist within it some byte code stating what kind of encryption or compression scheme is used, correct? Something like AES/DES?

Amateur at work, but having fun trying. Thanks, man!

[aluigi]

It depends if it's a known algorithm or a custom obfuscation but yes reverse engineering the executable will give you the answer.

[phoutem]

Okay, so, revisiting the topic here, I'm trying to extract some files from this game.
I've been balls deep in HxD parsing the actual .sxr file (2-0108.sxr in particular) and I know what I need to get done with QBMS, but damned if I know how to actually code it.

There are roughly 5 filetypes in this archive.
.cpp (self-explanatory, byte stream prefaced with zlib deflate default non-dict [79 9C], your offset program thingy did decompress it fine.)

.smdl (SMDL magic number, a model binary data file, seems to have file length around the end of the first 0x13 bytes) unnecessary to me,
.smot (SMOT magic number, model texture file, very small, calls relevant png data via custom ampedscript) unnecessary to me,

.png (%PNG magic number, standard png, I can tediously do the calculation with 0x08 offset to copy->paste new via HxD)
.webp (RIFF magic number constant for grep, 4 byte address + 0x8h offset)

The latter two formats are what I actually want.

The .sxr files have mostly the same format as before, just minus the file pointer table at the end as in the beta version. I admit to not knowing how, but can't quickbms be configured via script at least to grep and dump files by file header info? This file seems more and more like a tarball with some spotty raw zlib deflated streams within it. It would be good enough to just have files named as offset number, perfection is not required.

The archive reports like 600 or 800 or so (.cpp) files that get deflated, which is consistent with the 2-0107.sxr file from the beta that the other bms script extracted with no problem. The rest aren't encoded or encrypted any extra that I can honestly detect.

Is it enough to help with, having this information at all?

[aluigi]

The table with the information is encrypted so you can't extract the files.
Data is ok, alternatively you can use offzip -a to dump the compressed files.