* Create gltf.hexpat
Added glTF binary file pattern.
* Add a test file for the glTF pattern.
* Renamed the test file to fit the pattern file name.
* Fixed typo in documentation.
* patterns/hinf_luas: Added pattern for reading HavokScript 5.1 Bytecode from Halo Infinite
* Parses Header and Structures of the parent tag
* Reads Bytecode types and arguments
* Reads Constants and Debug Info
* Reads Referenced Tags in the File
* readme: fix relative link
* patterns/hinf_bitmap: Added pattern for parsing Halo Infinite bitmap files
* Parses the header of all Halo Infinite files which includes related "dependencies", datablocks, structure references
* Read bitmap sequence data, including bitmap index, complete index, sprite info
* Find the width/height and DDS Format of the raw texture, which can then be parsed into usable DDS textures
* Locates raw DDS block info
* Nulled out the DDS section of the bitmap
* 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)
* 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
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
Allow either a single test file in tests/patterns/${pattern}.hexpat.${ext},
as we do now, or multiple files in tests/patterns/${pattern}.hexpat/*.
Closes#158.
* 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
* 7z.hexpat
This repository contains a custom pattern for the ImHex tool that enables the analysis of 7zip files. The pattern allows for a structured view of 7zip files within ImHex, providing insights into various aspects of the file structure.
- Identification of 7zip files: The custom pattern detects and identifies 7zip file types based on their signature.
- Extraction of key information: The pattern extracts important details from the 7zip file, such as the format version, CRC values, relative offset of the end header, and file size.
- Differentiation of compression methods: The pattern distinguishes between LZMA and LZMA2 compression methods used within the 7zip file.
- Visualization of start and end headers: The pattern helps in visualizing the start and end headers of the 7zip file, making it easier to navigate through its structure.
To use the custom pattern for analyzing 7zip files in ImHex, follow these steps:
1. Install ImHex: Ensure that you have ImHex installed on your system.
2. Open a 7zip file: Launch ImHex and open the 7zip file you want to analyze.
3. Apply the custom pattern: In the "Pattern" menu, select the custom pattern for 7zip file analysis and apply it.
4. Explore the file structure: ImHex will display the matched patterns, allowing you to explore the structure of the 7zip file with the extracted information.
Please note that this custom pattern is designed specifically for 7zip files and may not be suitable for other file formats.
Contributions to this custom pattern for 7zip file analysis are welcome. If you have any improvements, bug fixes, or suggestions, feel free to submit a pull request.
This custom pattern for ImHex is licensed under the [MIT License](LICENSE.md). You are free to modify and distribute this pattern as per the terms of the license.
We would like to acknowledge the developers of ImHex for providing an excellent tool for binary file analysis. The custom pattern for 7zip file analysis in this repository builds upon the capabilities of ImHex to enhance the understanding of 7zip file structures.
---
We hope you find this custom pattern useful for analyzing 7zip files using ImHex. If you encounter any issues or have any questions, please feel free to raise them in the "Issues" section of this repository.
Thanks!
* Added test file
---------
* Create cda.hexpat
pattern language created for .cda files
* added test file for cda pattern
* Delete cda.hexpat.cda.cda
* Add test file cda
test file for cda pattern
* Update README.md
Add cda file in read.me
* Create tiff.hexpat
* Update README.md
Update readme to include tiff hexpat
* added file to test the pattern
---------
Co-authored-by: joelalves <joel.17.alves@gmail.com>
* Added pattern file for M.A.X. v1.04 game files.
* * Added MAX pattern in list of patterns.
* Added MAX sample game save file.
* Reordered the list of patterns to ascending name.
---------
Co-authored-by: n.bitounis <n.bitounis@xe.gr>
