Does anybody recognize this encryption/compression?

[AKAAkira]

I got a few files, some of which contain Japanese text and some of which contain names of other files, after an initial XOR step but I couldn't make heads or tails of whatever the next step should be. It should be some kind of compression, since it squeezes some of the intended dialogue a few bytes down from what they otherwise would be in UTF-8, but at other times it replaces a number of bytes from the dialogue with the same number of bytes, which I don't see the point of if it's intended to be compression.

I'd be grateful if somebody could tell me what this compression method might be.

(Included the original files before the XOR step, in case the compression happened there - though I doubt it, personally - as well as some of the text the two files should contain, and an initial attempt from me to compare the differences in bytes that didn't really go anywhere.)

[LolHacksRule]

What game? Always give the game name...

[AKAAkira]

It's from an online gacha game from nijiyome called アムドガル戦記　迷宮のセリア零 (Record of Amudgar: Labyrinth of Seria Zero) (NSFW). It kinda went offline yesterday though, and I wasn't sure it mattered too much what specific game it was.

[aluigi]

Do you have details about the xor there?
No idea about the compression since words like "Character" and "localization" don't appear in the decompressed outputs I tested.

[AKAAkira]

It just uses the key "InputOriginalKey" for the XOR, except for the bytes that either are null in the original file or would result in null after the XOR. So a file that starts with 00 3B 70 06 11 3B would result in the byte array 00 55 70 73 65 74 (null-U-p-s-e-t), for example. Unlike the files I provided, the JPGs and PNGs encrypted like this apparently don't get further compressed, and are properly viewed, so I can verify that this should be the correct decryption method.

(The actual key to be used was probably intended to be changed for each individual game, but wasn't, out of laziness or a lack of understanding. That was the case for both games I've seen using utage so far.)

Still, I can't see how the compression could've happened before the XOR - if it did, I doubt the alignment of the key to the file would have matched up so much, and the padding at the end of files like character002_0.tsv shouldn't be so regular.

One last thing I just noticed - the first four bytes of the XOR-decoded file might possibly be the intended file size after decompression. Looking through my other files I don't yet see a case where those first four bytes denote a number smaller than the file they're contained in, but if they are true it would mean some files are supposed to be 2x~4x times bigger than they are. I get the feeling I should've attached more to my initial pack to provide a better body of samples, so, uh, I'll just do that.