View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000615 | file | General | public | 2025-01-14 23:09 | 2025-01-14 23:09 |
| Reporter | fridtjof | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Product Version | 5.46 | ||||
| Summary | 0000615: Some ASAR archives are not detected reliably | ||||
| Description | Some ASAR archives I've encountered seem to have one less closing brace at the end of their header. The current magic detection in magic/archive seems to be based on the assumption that the header always ends with four closing braces. With an archive created by the 'asar' CLI utility, this generally applies (see the attached dir.json I carved out of the also attached dir.asar): every file/directory listed here has an extra 'integrity' key which is another object (thus four closing braces - integrity < file < top level "files" key < top level object). Depending on nesting, this yields at least four closing braces because the 'integrity' field always seems to come last. This was implemented with asar 3.1.0 released in September 2021 (https://github.com/electron/asar/releases/tag/v3.1.0). However, e.g. Discord ships ASAR files without this integrity information for some reason (maybe they're still using an old version of asar, or explicitly decided to omit it). Their .asar also contains a single 'package.json' at the top level which is listed last, producing an edge case where the header ends with only three closing braces. The solution seems simple to me: Reduce the match from "string }}}}" to "string }}}" and adjust the offset accordingly (from ">>(12.l+12)" to ">>(12.l+13)"). | ||||
| Steps To Reproduce | curl -LO https://dl.discordapp.net/apps/linux/0.0.79/discord-0.0.79.tar.gz tar xf discord-0.0.79.tar.gz Discord/resources/app.asar file Discord/resources/app.asar # this just shows 'data' | ||||
| Tags | No tags attached. | ||||
