[File] Regression in Chrome extension detection

[Christos Zoulas]

Indeed, it is a lot better to to do >>20 pstring/l ... so that it gets printed only when the use entry matches.

Fixed, thanks,

christos

> On Jul 6, 2019, at 9:18 AM, Christoph Biedl <astron.com.bwoj at manchmal.in-ulm.de> wrote:
> 
> Hi there,
> 
> the logic in the second hunk of
> 
> | commit c2ef6d0e6226d10621e9e67999dd2c3ee35d79a0 (HEAD, refs/bisect/bad)
> | Author: Christos Zoulas <christos at zoulas.com>
> | Date:   Tue Apr 9 18:34:15 2019 +0000
> |
> |     PR/73: enkeli: Require the actual central directory record, not just the
> |     end of central directory for zip.
> |
> | @@ -53,7 +53,7 @@
> |  >>0    leshort         x               v?[%#x]
> |
> |  # Zip End Of Central Directory record
> | --22    string          PK\005\006      Zip archive data
> | +-22    string          PK\005\006
> |  #>4    leshort         >1              \b, %d disks
> |  #>6    leshort         >1              \b, central directory disk %d
> |  #>8    leshort         >1              \b, %d central directories on this disk
> 
> is not clear to me.
> 
> As a result, this block now is
> 
> | # Zip End Of Central Directory record
> | -22           string          PK\005\006
> | >(16.l)       use             zipcd
> | >20           pstring/l       >0              \b, %s
> 
> So if the first line matches, it file will happily print any
> non-empty ASCIIZ string starting at offset 20.
> 
> To make things worse, this change introduces a new strength line
> 
> | Strength =  71 at 63: , %s []
> 
> which defeats several other and betters rules. That's why for example
> the detection of Chrome extensions is now broken:
> 
> -Google Chrome extension, version 2
> +, \206H\206\367\015\001\001\001\005
> 
> Care to take a look?
> 
>    Christoph
> -- 
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file