Binary DB

Once a base model's binary has been analyzed, its information can be saved in the Binary DB. This enables automatic analysis of similar binaries in other models.


How to Automate Binary Analysis

  • After uploading the binary analysis result (FOSSLight Report) and clicking the Save button, the FOSSLight Hub compares it with the Binary DB and automatically fills in OSS Name, License, and other information for identical or similar binaries.
    • Applicable menus
      • Project > Identification > BIN, BIN(Android|Yocto) tab
      • 3rd Party > Identification > 3rd party tab
    • When using FOSSLight Binary Scanner version above v4.1.30, TLSH and checksum values can be found in the Binary Sheet of the FOSSLight Report, so there is no need to attach the binary.txt file.
      binarytxt
  • Below the Binary Name field, a warning message will appear indicating whether the binary is identical or similar to a binary that exists in the Binary DB.
  • How to check for a match in Binary DB
    • Whether a binary matches one in the Binary DB is determined using the following data.
      1. If the binary name and checksum value match, it is considered identical.
      2. Or, if the binary names are the same and the TLSH (Trend Micro Locality Sensitive Hash) distance between the binaries is 120 or below, they are considered similar.



Data Insertion into Binary DB

  • During the ‘Confirm' step of the Identification in 3rd Party or Project, binary information listed in Identification > BIN, BIN(Android|Yocto), or 3rd Party is inserted into the Binary DB.
Details of Data Insertion
  • If the OSS Name is empty, it is saved as a hyphen "-".
  • If the TLSH value is empty, it is saved as 0.
  • If the Binary Name includes Path information, only the file name is saved as the Binary Name, and the path is ignored.
  • This only works when a binary analysis result (binary.txt or result.txt) has been uploaded.
    (Applicable only for FOSSLight Binary Scanner version 4.1.30 or below)
  • If the binary is identical but the OSS information is different, the existing information is deleted and replaced with the new information.
  • If the binary is similar, the existing OSS information is retained, and the new OSS information is additionally updated.
Detailed Behavior
No Case Action Description
1 If no binary with the same Binary Name exists in the Binary DB Save as new Binary The binary is saved as a new Binary.
2 If a Binary with the same Binary Name and identical checksum exists in the Binary DB Update with latest Binary information Delete the existing Binary information in the Binary DB and save the latest Binary information.
If multiple OSS are used in a single Binary If multiple OSS are used in the same Binary within a single Project, all OSS information is saved.
3 If a Binary with the same Binary Name exists in the Binary DB, but the checksum does not match If TLSH distance <= 120,
the action depends on OSS information
  1. If OSS Name and OSS Version are the same
    ∘ Save as a new Binary. The existing Binary information can only be used when checksum matches, so set TLSH distance to 0.
  2. If OSS Name is the same but OSS Version is different
    ∘ Save as a new Binary.
  3. If OSS Name is different
    ∘ Save as a new Binary. The existing Binary information can only be used when checksum matches, so set TLSH distance to 0.
If TLSH distance > 120,
save as new Binary 		If the TLSH distance is greater than 120, it is considered a different Binary and saved as a new one.




View Binary DB

  • You can view the current status of binaries registered in the Binary DB through the Binary DB menu. binarytxt