You've already forked linux-packaging-mono
Rewrite with hard-coded offsets into the PE file format to discern if a binary is PE32 or PE32+, and then to determine if it contains a "CLR Data Directory" entry that looks valid. Tested with PE32 and PE32+ compiled Mono binaries, PE32 and PE32+ native binaries, and a random assortment of garbage files. Former-commit-id: 9e7ac86ec84f653a2f79b87183efd5b0ebda001b
OID information is generated via a series of perl scripts. In order, the full
list of commands to run are:
perl objects.pl objects.txt obj_mac.num ../../include/openssl/nid.h
perl obj_dat.pl ../../include/openssl/nid.h obj_dat.h
perl obj_xref.pl obj_mac.num obj_xref.txt > obj_xref.h
objects.txt contains the list of all built-in OIDs. It is processed by
objects.pl to output obj_mac.num and nid.h. obj_mac.num is the list of NID
values for each OID. This is an input/output parameter so NID values are stable
across regenerations. nid.h is the header which defines macros for all the
built-in OIDs in C.
nid.h is read by obj_dat.pl to generate obj_dat.h. obj_dat.h contains the
ASN1_OBJECTs corresponding to built-in OIDs themselves along with lookup tables
for search by short name, OID, etc.
obj_mac.num and obj_xref.txt are read by obj_xref.pl to generate
obj_xref.h. obj_xref.txt links signature OIDs to corresponding public key
algorithms and digests. obj_xref.h contains lookup tables for querying this
information in both directions.
Dependency graph:
objects.txt
|
V
[objects.pl] <--+
/ \ |
V V |
nid.h obj_mac.num obj_xref.txt
| \ /
V V V
[obj_dat.pl] [obj_xref.pl]
| |
V V
obj_dat.h obj_xref.h