search

Squiblydoo / debloat

A GUI and CLI tool for removing bloat from executables
BSD 3-Clause "New" or "Revised" License
301 stars 25 forks source link

Reports results, new uses, more efficiency #30

Closed Squiblydoo closed 3 months ago

Squiblydoo commented 3 months ago

This version prints report codes indicating which inflation tactic is identified. This version can now handle instances where no pattern exists within the junk data, or the pattern is disrupted by a few characters. This version uses the trimming method from binary refinery in two cases that were found to be more efficient. A performance testing script has been included.

The new updates hand a few edge use-cases that were not solvable before and fixes one bug. Bug: If debloat was unable to trim a inflated section, it would tell you it could and then exit telling you that it could not.

New use-case solved: This solves the use-case where there a pattern exists in the overlay, but additional bytes have been added to disrupt the pattern. As much as 1 byte is enough to disrupt the pattern. This is not a problem anymore.

Squiblydoo commented 3 months ago

Comparisons of versions, whereas 1.5.4 will be the new version number for this build and 1.5.3.4 was the previous build.

Success - No change
1.5.3.4 Success tactic-1 738.980MB 740.680MB [0.0, 0.0, 0.0]
1.5.4 Success 1 tactic-1 738.980MB 740.680MB [0.0, 0.0, 0.0]

Success - Slightly slower
1.5.3.4 Success tactic-2 762.939MB 794.594MB [2.21, 2.46, 2.21]
1.5.4 Success 2 tactic-2 762.939MB 794.630MB [3.04, 2.97, 3.63]

Success - Slight improvement
1.5.3.4 Success tactic-3 726.000MB 728.950MB [4.34, 4.22, 4.29]
1.5.4 Success 3 tactic-3 726.000MB 781.341MB [3.7, 3.49, 3.64]

Success - Substantial improvement
1.5.3.4 Success tactic-4 439.726MB 444.953MB [9.2, 7.14, 6.63]
1.5.4 Success 4 tactic-4 439.726MB 525.523MB [3.14, 3.31, 3.0]

Success - No change
1.5.3.4 tactic 5, not pictured
1.5.4 tactic 5, not pictured

Success - Slightly slower
1.5.3.4 Success tactic-6 300.348MB 308.890MB [4.4, 4.43, 4.63]
1.5.4 Success 6 tactic-6 300.348MB 308.957MB [4.62, 4.74, 4.9]

Success - No change
1.5.3.4 Success tactic-7 1.264GB 1.265GB [13.65, 14.19, 14.12]
1.5.4 Success 7 tactic-7 1.264GB 1.287GB [15.38, 13.44, 13.97]

Failure - No change
1.5.3.4 Fail tactic-8 307.925MB 308.269MB [2.65, 2.41, 2.59]
1.5.4 Fail 0 tactic-8 307.925MB 308.269MB [2.65, 2.5, 2.47]

Failure - Slightly Slower 
1.5.3.4 Fail tactic-9 734.451MB 734.546MB [0.05, 0.05, 0.05]
1.5.4 Fail 0 tactic-9 734.451MB 735.796MB [0.11, 0.1, 0.11]

Success - Now succeeds quickly
1.5.3.4 Fail tactic-10 762.939MB 763.020MB [0.05, 0.05, 0.05]
1.5.4 Success 3 tactic-10 762.939MB 771.622MB [3.76, 3.7, 3.53]

Failure - Slightly Slower failure
1.5.3.4 Fail tactic-11 4.938MB 4.980MB [0.03, 0.03, 0.03]
1.5.4 Fail 0 tactic-11 4.938MB 5.261MB [0.13, 0.12, 0.11]

The slower speeds on some instances is caused by a compression check. This check is performed because it easily predicts whether dynamic_trim or refinery_trim will work. If they won't, it won't try them. Without the check, a low compression/high entropy sample can run 23 seconds before determining that no compression method will work.