LST: Difference between revisions

Latest revision as of 08:13, 2 August 2014

Common File names:

lcsebody.lst
SoundPackSE.lst

Note: This file is just the index for a separate file by the same name, excluding extensions, that has the file data.

Structure

Header
Size	Content	Description
4Bytes	Number of Files
Index
Size	Content	Description
4Bytes	Offset
4bytes	File size
64Bytes	Filename	Some may be padding.
4Bytes	Unknown

Research

Before window title is updated, it is set to 'LC-ScriptEngine ver1.0'.

Each element in index is XOR'd with 0x01010101 so it is applied to 4bytes for int's and 1 byte for char's with the exception of the last element in an index entry which is a 4 byte number.

Need to run more tests to check if decoding is working properly. Last few index entries look off. Need to make memory dump of index list after game decodes it in memory and compare with my results. However... Seems like I could just subtract 0x01 from each byte and that'll work too...Well, for one way decoding.

Update: Extracting data from memory shows a 1:1 match for index data after it is processed. Seems the last few entries are encoded in shift-JIS which will make things a little bit annoying since to extract, first convert to something the OS understands and then when building it, convert that to shift-jis. I may create a temp measure by just making the name be in hex format by testing if char is between 0x81 and 0xFC (Shift-jis takes up 2 bytes per character)

@@ Line 1: / Line 1: @@
 [[Category:Archives]]
+This is a [[LC-ScriptEngine]] format.
-Used in the following game(s):
-* Conquering the Queen
-* Cosplay Alien
-* Edelweiss
-* Guilty ~The SiN~
-* Harem Party
-* Harukoi Otome
-* Koihime Musou
-* Magical Teacher
-* Sandwiched by my Wife and her Sister
-* Sex Slave is a Classmate, My
-* Shera, My Witch
-* Slave Witch April
-* Suck my dick or die!
 Common File names:
-lcsebody
+* lcsebody.lst
-SoundPackSE
+* SoundPackSE.lst
-Most likely is index data for the extension-less file that accompanies this file with the same name. Index data, at the very least, looks obstructed....is that the right word? O.o I've been using that a lot but I feel like I have the wrong word.... Something like that word but with an F in it that means it hides, or masks the code? Obfuscation? :O
+Note: This file is just the index for a separate file by the same name, excluding extensions, that has the file data.
 == Structure ==
@@ Line 26: / Line 12: @@
 !colspan="15"|Header
 |-
-| 4Bytes || Number of Files
+! Size !! Content !! Description
+|-
+| 4Bytes || Number of Files ||
 |-
 !colspan="15"|Index
 |-
-! Size !! Content
+! Size !! Content !! Description
+|-
+| 4Bytes || Offset ||
+|-
+|4bytes || File size ||
+|-
+| 64Bytes || Filename || Some may be padding.
 |-
-| 76Bytes || Unknown
+| 4Bytes || Unknown ||
 |}
 == Research ==
-Using the game 'Conquering the Queen' for research.
+Before window title is updated, it is set to 'LC-ScriptEngine ver1.0'.
-File names found.
-lcsebody -> NECEMEM.SNI (game engine complained about that when I couldn't find the *.LST file)
-Engine details.
-LC-ScriptEngine ver1.0
-From watching file access to 'lcsebody.lst', it first reads from offset 0 with a length of 4. Then it reads the rest of the file in 76 byte chunks. This could suggest the first 4 bytes are file count and then the rest is file entries which would mean there is 598 files inside this games lcsebody. I do remember seeing 256 in one of the registers during the read loop so...Yup. Comparing a 4 byte int of 598 to the first 4 bytes in the file shows each byte has a 0x01 byte difference. Just something random... XD
-Okay. Number of files.
+Each element in index is XOR'd with 0x01010101 so it is applied to 4bytes for int's and 1 byte for char's with the exception of the last element in an index entry which is a 4 byte number.
-* Moves the 4 bytes that were just read into EAX register.
-* xor it by 01010101
-* Puts it back in same memory location it first pulled it from
-Index
+Need to run more tests to check if decoding is working properly. Last few index entries look off. Need to make memory dump of index list after game decodes it in memory and compare with my results. However... Seems like I could just subtract 0x01 from each byte and that'll work too...Well, for one way decoding.
-* Still working on this... a lot of things to keep track of and interpreting the assembly instructions. But it seems it treats the numbers and characters different as in it loads a 4 byte number into a register then xor it with something, then puts it back. For the characters, it loads it one at a time a xor an 8-bit value then returns it. What it xor the value by may be different each time and chained together so it takes the last value to generate the next. Is this encryption? o.O Well, whatever it loads, it may just XOR by it 01010101 so either 1 byte for char, 4 bytes for a number. Need to check how it can tell if it is last char in string. Might just be 0x00.
-Data
+Update: Extracting data from memory shows a 1:1 match for index data after it is processed. Seems the last few entries are encoded in shift-JIS which will make things a little bit annoying since to extract, first convert to something the OS understands and then when building it, convert that to shift-jis. I may create a temp measure by just making the name be in hex format by testing if char is between 0x81 and 0xFC (Shift-jis takes up 2 bytes per character)
-* Haven't checked yet. Could be protected as well by with a different method. Just noticed lots of 0x02's in it so that's a possibility unless that's just how the data is for that specific file. Sound archive though looks unprotected due to obvious OGG header seen so maybe I'm overthinking it and it's just the index that is protected...though it would make sense to have data archive protected and not sound archive... Hmm.

LST: Difference between revisions

Latest revision as of 08:13, 2 August 2014

Structure

Research

Navigation menu

Search