I hope you all are doing well and staying safe.

I am in the process of trying to understand how SuperScape stored data in their .VCA/LCA format, so I can extract the original SHAP and PAL data from the Lego Creator Knights Kingdom game using Python and Noesis.

Actions I have done so far:

  • Downloaded an older version of the program (5.60 VRT) via archive . org
  • Installed onto a Win 7 32-Bit VM
  • Went through the documentation to glean any insight which they used for reference material
  • Used the default objects in the program and edited via Shape Editor then compared differences in Hex Editor
  • Consulted other forums for insight
  • Also consulted ChatGPT/Copilot/Bing Chat (which have been surprisingly useful)
  • Used APITrace which gleaned some results, but nothing related to model rendering.

From here I was able to better understand their structure, and how they store the data in the files, but not necessarily how they retrieve it.

Game Structure:

SuperScape uses three things for Lego KK:

  1. LegoKK.exe (executable which launches main program)
  2. SSWATCH.exe (plugin used for interacting with ActiveX-IE)
  3. SS3DLEGO2000.EXE (application which views and interacts with 3D models/actions)

If you run ProcessExplorer by Microsoft, you can see that LegoKK.exe explicitly calls SSWATCH.exe with some plugin number

"C:\Program Files (x86)\LEGO Media\Constructive\LEGO Creator Knights Kingdom\3D Control/SSWatch.exe" 263466

And SSWATCH.exe calls lego3d2000.exe with a dynamic plugin number as well as parameters

"C:\Program Files (x86)\LEGO Media\Constructive\LEGO Creator Knights Kingdom\3D Control\SS3DLEGO2000.EXE" /plugin:5769736 /BackgroundPalette /HideFrame /HideMovementBar /idle C:\Users\amoebame\AppData\Local\Temp\vis2.xvr

File Structure:

Each .LCA file contains a minimum of four (4) files within it:

  • .VRT (holds the file headers: NOTNAMED.SHP, NOTNAMED.PAL, NOTNAMED.WLD, etc.)
  • .SHP (Shape file contains points/lines/facets/associated colors/animated colors/etc.)
  • .PAL (Palette file contains colors)
  • .WLD (Unsure how this exactly fits in, but probably contains animation data)
  • It can also contain .SPRT, which I believe holds animation commands. (example below)

Taking a look at the differences in target vs source I could tell how the data was being stored.

Target vs Source

Using reference material, I was able to understand the context of the SHAP files and the calculations used.

Reference Material

Which can be seen more clearly in this example below.

Generic Structure

I had asked around, and was graciously given help by others as a stepping stone to further glean from. They had noticed that the offset from .VRT (10C in this case)

VRT File

Could be used to subtract from where the SHAP/PAL/WRLD are located to find the HEX values which is is after the NONAMED.SHP/PAL/WLD. (0144, 05AD, 11B7).




I am not sure if anyone has seen/experienced any file type similar to this before. But my major problem really is trying to make sense of the data, how the script knows what is a point versus line, and what type of point/etc. it is. I am guessing this information is stored at the end of the SHP file somehow.

I noticed that after .VRT, there are exactly 10 bytes between text which as stated earlier, holds address data.

  • .VRT.........
  • NOTNAMED.SHP..........
  • NOTNAMED.PAL..........
  • NOTNAMED.WLD..........

I also noticed the pattern ...'...'...' correlates to &... TEXT . below which if you look at the script, is what pulls the title for each group and object name.

Group Header information

If anyone has any insight as to where I can go from here, I would be extremely grateful. I have tried alternative means to extract the model information, but does not accurately retrieve 3D information, just DirectDraws onto a 2D plane. From what I had asked around, at the time was an efficient way to do optimize the code (though 3D data still exists) for game performance.

Thank you in advance!


I have started using Ghidra/x32dbg for dynamic and static analysis. The ss3dlego2000.exe imports functions from dlls and activex controllers (.ocx/.vis/.dev). I am currently looking into DLL Injection and seeing if that will bear any fruit. Because the program uses ActiveX, and has way too many imported files, trying to make sense of what goes where is extremely mind-numbing. But my goal is to get this obtained by end of year. If you all have any resources which I could use for starting off small with print statements, would kindly appreciate it!

  • Looks like you can find the original software written by New Dimension International Ltd. on archive.org over at: archive.org/details/superscape-do3d-v510-1998 (This has some examples of the format) or archive.org/details/Do3D510 (I haven't looked at this one). It's so old, it probably wouldn't be too hard to reverse. Also, their website is archived at do3d.com, but the latest snapshot is in the late 90s. Some examples of how to use it can be found at utweb.utaipei.edu.tw/~lai/bcc/Do/Do.html Commented Dec 12, 2023 at 18:39
  • Hello @AliRizvi-Santiago, thank you for the reply! If you look at the comparison photos above, I installed Win-7 32bit VM and have their VRT, Do3D and other programs from Archive installed. :) That is how I was able to capture the reference file and knowing where point addresses/etc. were stored. I am trying to figure out how to get the 3D data, which they had a script used in the VRT 5.60 suite, but not in LegoKK. I will update my post, as I have since used Ghidra/x32dbg. Do you think DLL injector would work for getting model data? Any other advice? I do appreciate your reply! :)
    – amoebame
    Commented Dec 14, 2023 at 4:27
  • Typically the only time you need to instrument code with injectiion is if you need to change something or want performance. Since there isn't any code that you've identified in those binaries yet, I would start with cross-referencing those strings that you see in the file to identify the code that either reads/writes that specific format. Once you find the part of the binary that decodes the data from the file, you can then consider a debugger to step through the implementation. Try to use a sample file that you're familiar with and would immediately recognize being processed in your debugger. Commented Dec 14, 2023 at 15:37
  • This is helpful, thank you for the reply I greatly appreciate it! Do you have any resources which are good for ghidra/x32dbg that I could use for reference material? I have looked on Youtube/Google/etc. but only found guidedhacking stuff and nothing too beginner friendly. Also, most of their stuff is pre-found which kind of defeats the purpose of reverse engineering guides haha
    – amoebame
    Commented Dec 16, 2023 at 1:47
  • No idea. But when you reverse, you want to think like a dever. For your situation, a file is being read. So, you'd want to enumerate all the places the file can be used (like fopen, fread, fwrite, fseek and fclose which are related), set a breakpoint on candidates, and then use the app to figure out which candidate opens the file you want. After finding it, fread will be used for reading, fseek will be used to seek around, etc. Use those known characteristics to identify the part of the file you're looking for, and then use breakpoints and hw breakpoints to see how it gets used. Commented Dec 16, 2023 at 17:34


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.