* Added pattern file for Apple’s binary property list format (bplist)
* renamed some stuff and improved error messages
* added error handling for object size special case (0x0F)
* patterns/jpeg: exclude EOI marker from SOS image data
* patterns/jpeg: use type::Magic for magic numbers
* patterns/jpeg: add RGB component IDs
* patterns/jpeg: add struct for APP14 marker
* patterns/jpeg: add definition for COM marker
* patterns/jpeg: add some format_read() for better legibility
* Working on new Version
* Needs testing
* Updated CrashLvl script to support version 0.94c
* Update README.md
* Added TestData and author to script
* Delete tests/patterns/test_data/CrashLvl.hexpat.bin
* Add files via upload
* Update README.md
Added nes.hexpat to list of hex patterns
* Fix indenting of hex patterns list
Moved nes.hexpat below NE.hexpat
* Update README.md
Fixed indenting of PP pattern file's description being wrong
* Added x-msdownload MIME type to PE description
* Made indenting & code of ips.hexpat better
* Improvements to gb.hexpat
* Urgent fix to ips.hexpat
* Urgent fix to gb.hexpat
patterns/zip: add parsing local file header, and another adjustmenst
Add missing parsing for local file headers
Add compression method
Minor adjustments: removed black colors, marked magic ids
DICOM files specify a "transfer syntax" which defines the image
compression format, the encoding rules for the entire file, and any
special-case encoding rules for particular fields. Many transfer syntaxes
have common design features, but a transfer syntax is allowed to use
completely custom encoding rules, and need not be publicly documented.
Explicitly reject transfer syntaxes we know we don't support: implicit VR
(uncommon), explicit VR big-endian (deprecated), deflate-compressed.
In all other cases, follow some general rules and hope it works out.
The large lookup functions were generated by a script, but I haven't
included the code here, since its input is hand-massaged data copied from
HTML tables.
Add a JPEG WSI test case from the WG26 2021 hackathon (CC0 license) and a
synthetic LE Explicit VLP case produced with img2dcm.
* patterns/tiff: show TIFF tag name/number in DirectoryEntry array
Don't require unfolding the array entry to see what tag it contains.
* patterns/tiff: show IFD number in IFD list
* patterns/tiff: add JPEGTables tag; correct name of ICC Profile tag
* patterns/tiff: add TIFFRational type
Rationals, uniquely, are primitives with two fields. Add a struct to
represent this, rather than inlining them.
* patterns/tiff: use correct types for fields smaller than 4 bytes
Small fields are always left-aligned in the 4-byte Value Offset. On
little-endian TIFFs we currently cheat this by declaring a 32-bit value
and letting little-endianness handle the semantics. However, this adds
some extra conditionals, and misrepresents the resulting field as 32 bits.
Drop the cheat.
* patterns/tiff: add ValueOffset abstraction
We were using the field type to make assumptions about whether the Value
Offset is a Value or an Offset, which is incorrect. If the Count
multiplied by the field size is larger than 4, the field is an Offset;
otherwise it's a Value.
Add display sugar for single-element arrays to avoid extra nesting.
* patterns/tiff: drop dead code
get_ifds_offsets() and BIG/LITTLE aren't used at all. get_total_IFDs()
is only used for declaring the length of TIFFFile.IFDs, and isn't needed
because IFDs are structured as a linked list.
* patterns/tiff: drop set_endian()
The call in TIFFFile is redundant. Drop both calls and open-code the
check at the top level, before executing any code. The BigTIFF check
will eventually be added alongside this one.
Fail if we don't recognize the magic number.
* patterns/tiff: minor cleanups
* patterns/tiff: drop strip offset/byte count arrays from struct IFD
They're redundant with the fields in the DirectoryEntry array. Also
they're buggy: they assume the field Value Offsets are always offsets,
which isn't true for single-strip IFDs, and they ignore a partial last
strip in multiple-strip IFDs.
* patterns/tiff: rewrite strip array generation
We're making extra work for ourselves by avoiding the type system. Also,
by calculating the number of strips we expect rather than the number of
strips we actually have, we're miscounting and omitting any partial last
strip.
Instead, read the strip offsets and byte counts directly from the
IFDEntry array.
* patterns/tiff: add ImageData array for tiled IFDs
* patterns/tiff: increase variable widths for BigTIFF
Use 64-bit temporary variables for values that can be 64 bits in BigTIFF.
* patterns/tiff: support BigTIFF
* tests/patterns/test_data: add more TIFF tests
* Add files via upload
* Update README.md
Added nes.hexpat to list of hex patterns
* Fix indenting of hex patterns list
Moved nes.hexpat below NE.hexpat
* BSON support multiple documents per file
BSON files can contain consecutive documents glued one after another. An example of these is MongoDB FTDC metrics export.
[`bsondump`](https://github.com/mongodb/mongo-tools/blob/master/bsondump/bsondump.go) can unpack this type of BSON documents.
* Add accidentally deleted lines
* Replaced right_to_left to bitfield_order
* Fixed type of ParentLocatorEntry (char -> char16)
* Fixed item address of MetadataTableEntry
* Improved RegionTableEntry# Please enter the commit message for your changes. Lines starting
* Update pe.hexpat
New improvement
* Add ips.hexpat via upload
* Add ips.hexpat.ips via upload
* Added IPS to README
* Mentioned Windows in portable_executable_magic
In order to have a better time viewing FDTs in the visualizer
scanner will now unflatten the FDT.
It could still be improved slightly by modifying FDTProps to
make their values be `u32`s and possibly detect whether they
should be u64s.
* Fix flattened device tree parsing
Fix parsing to support multiple FDTs in a file and
non-zero base addresses.
* Fix string parsing
Parent offset wasn't being taken into account
when looking for prop names.
- Add various version of the BitmapInfoHeader struct, and autodetect
the correct one.
- Fix palette detection.
- Use BitmapInfoHeader::biSize to find the position of the palette / data.
