View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000498 | file | General | public | 2024-01-17 16:04 | 2024-01-30 21:46 |
| Reporter | jsummers | Assigned To | christos | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | assigned | Resolution | open | ||
| Product Version | 5.45 | ||||
| Summary | 0000498: PKLITE-compressed executable files | ||||
| Description | Hi, I'd like to discuss whether PKLITE-compressed (MS-DOS) executable files could or should be identified by 'file', and what it would take to do it. There are EXE and COM-based formats, which could be considered separately. I've done some work on this. The main rules I'm working on are at https://github.com/jsummers/myfilecmdmagic in the "pklite" subdirectory. Some alternatives are in the "pklite_simple" and "pklite_hdronly" subdirectories. Side note: I've written a script: pkla.py - https://github.com/jsummers/pkla - that analyzes and fingerprints such files. PKLITE-compressed files contain a signature-like copyright string, but if you ask me, it shouldn't be relied upon. This was a very hacked-on format, and the copyright string was often modified. Even without the copyright string, identifying PKLITE files is doable. But I guess it may be tricky to integrate it into the existing EXE rules without breaking something. Also note that many self-extracting ZIP archives have the executable part PKLITE-compressed. Such files ought to be identified as Self-Extracting ZIP, or, preferably, both PKLITE-compressed and Self-Extracting ZIP. | ||||
| Tags | No tags attached. | ||||
