QuiltMC/enigma

database of symbols

Opened this issue · 6 comments

Decencies commented

The enigma core should construct a database of symbols, and their references for the program.
This will (in theory) enable the projects to load faster once the database has been built.

The database should store symbols for:

  • Classes
  • Fields
  • Methods
  • Parameters / Locals

When a program is initially analyzed, the database is built.
Upon next launch, the program will load the symbol tree from the database into memory (lazily?)

This will cut down the unecassary computational costs when re-analyzing the program.

Some considerations for the file format:
We should use a constant-pool like approach, for example:
( denotes an 1 byte opcode)

<cls> java/lang/Object # entry 0
<name> equals # entry 1
<desc> (0)V # entry 2
<method> 0 1 2 # entry 3

This is done to save storage space when building the database, and it's also primarly how the JVM structures it's class-file constant pool.

ix0rai commented

on the implementation side I have a couple things:

  • we can associate jars with cache files based on hash
  • cache files should use the same directory as enigma's config
  • I think json is best
Decencies commented

on the implementation side I have a couple things:

  • we can associate jars with cache files based on hash

  • cache files should use the same directory as enigma's config

  • I think json is best

My idea was to rebuild the program entirely as a tree, which includes all class, field and method references. This will allow the database to be loaded even if the original JAR file is lost.

Another bonus of this is, if we were to use an efficient data storage algorithm, we could cut down 10-20mb input JARs in just a few hundred kilobytes, which is definitely a huge improvement.

ix0rai commented

that's an interesting idea!
I think we should implement this soon, since we'd be able to use the same format for both the cache and the eventual packet sending the full jar to the client in enigma-server

uniformization commented

… and the eventual packet sending the full jar to the client in enigma-server

There might be some potential legality issues regarding that

ix0rai commented

in theory, but I can't see anyone actually getting mad at us over it

Decencies commented

… and the eventual packet sending the full jar to the client in enigma-server

There might be some potential legality issues regarding that

It is up to the user to determine who can access their service, and subsequently who can access the JAR file served.