enigma icon indicating copy to clipboard operation
enigma copied to clipboard

database of symbols

Open Decencies opened this issue 2 years ago • 6 comments

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: (

<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.

Decencies avatar Jul 15 '23 23:07 Decencies

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

ix0rai avatar Jul 16 '23 00:07 ix0rai

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.

Decencies avatar Jul 16 '23 10:07 Decencies

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

ix0rai avatar Jul 16 '23 15:07 ix0rai

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

There might be some potential legality issues regarding that

uniformization avatar Sep 02 '23 18:09 uniformization

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

ix0rai avatar Sep 03 '23 22:09 ix0rai

… 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.

Decencies avatar Sep 04 '23 07:09 Decencies