[FR] Extend rules database layout: support i18n and version detection

[nitram84]

Checklist / 检查清单

• No one has submitted a similar or identical feature request before. / 之前没有人提交过类似或相同的功能请求。
• This suggestion does not depart from the original intention of LibChecker. / 这个建议不会背离 LibChecker 的初衷。

Enhancement propose / 改进目的

In my opinion two extensions for the current rules database layout would help LibChecker to get a greater audience and to support more features:

1. Introduce a column e.g. "description_en" make this database translatable. Descriptions in rules like in

https://github.com/LibChecker/LibChecker-Rules/blob/master/native-libs/libfb.so.json

are incomprehensible for most people living in countries with latin character based languages. A possibility to translate the LibChecker database to english would help a lot.

2. The LibChecker database could also store information to identify specific versions of libraries. I'm thinking of a table with following attributes:

• foreign key to rules table
• sha1 hash of the native library
• group id
• artifact id (group and artifact id may be different between different versions of the same library)
• min version
• max version (The version is a range since the native lib may be used unchanged in different versions of a library)

For most known open source libraries with native libs in the LibChecker database these information could be aggregated by scraping maven central. If those version data would be available in LibChecker database the app could identify specific versions by calculating and comparing hashes of native libs. Together with OWASP dependency check database LibChecker could even spot security issues in apps.

Another use case are decompilers: I recently used LibChecker rules database in a decompiler skylot/jadx#2040 (see sample script in issue)
Having dependency information with version numbers would make new ways possible to break code obfuscation.

The more uses cases exist for LibChecker rules database, the more people will contribute to this project.

Solution / 解决方案

No response

Additional info / 额外信息

No response

[qhy040404]

Internationalizing the description is a good idea, but at present, the database is manually maintained and is not integrated into ci. This will be a lot of work.
Secondly, it is not realistic to maintain the version information. Not all libraries will be published in maven central, and some libraries will be released separately through aar or jar. These content published on the open platform may not be available to the public, and applying for relevant permissions is also part of the overhead.
If the database is revised in the future, I will prefer to design a back-end, because at present, a large number of jsons correspond to the same description.
At present, LibChecker does not involve profit, and it is not necessarily in the future. It may be unrealistic to maintain a back-end. The current solution may be relatively cost-effective.