search for: major_v

...nerator.ml index 065c25d..fc7b483 100755 --- a/generator/generator.ml +++ b/generator/generator.ml @@ -159,6 +159,16 @@ but instead are lost. See L<hivex(3)/WRITING TO HIVE FILES>."; "\ Return root node of the hive. All valid hives must contain a root node."; + "major_version", (RInt32, [AHive]), + "return the major version of the hive", + "\ +Return major version stored in the hive header, -1 on error."; + + "minor_version", (RInt32, [AHive]), + "return the minor version of the hive", + "\ +Return min...

...checks be? > > No, hivex should definitely have those checks. > > I'll have a proper look at this in the morning. > > Thanks, > > Rich. Thanks, Rich. As far as I can tell, the only sanity checks in the initial loading of a registry hive are the magic bits (“regf”), major_ver = 1, and the checksum match. When calling hivex_open with a file under 4 bytes, you run into the out-of-bounds access when comparing against the magic bits; pass in a file 4 bytes long with “regf” correctly set, you’ll get an out-of-bounds access to major_ver; pass in a file truncated at 0x18 (m...

Hello all, I know that one of the original design goals of libhivex was to be resilient to corrupt, invalid, or malicious registry hives. I've encountered some undefined behavior in libhivex when attempting to open registry files that are too small. I'm not sure if this is a known issue per-se or not, so I figured I'd ask here on the mailing list before I jumped in and started adding

...have those checks. > > > > I'll have a proper look at this in the morning. > > > > Thanks, > > > > Rich. > > Thanks, Rich. > As far as I can tell, the only sanity checks in the initial loading > of a registry hive are the magic bits (“regf”), major_ver = 1, and > the checksum match. > > When calling hivex_open with a file under 4 bytes, you run into the > out-of-bounds access when comparing against the magic bits; pass in > a file 4 bytes long with “regf” correctly set, you’ll get an > out-of-bounds access to major_ver; pass i...

.../* For writing. */ size_t endblocks; /* Offset to next block allocation (0 @@ -104,7 +105,7 @@ struct ntreg_header { char magic[4]; /* "regf" */ uint32_t sequence1; uint32_t sequence2; - char last_modified[8]; + int64_t last_modified; uint32_t major_ver; /* 1 */ uint32_t minor_ver; /* 3 */ uint32_t unknown5; /* 0 */ @@ -173,7 +174,7 @@ struct ntreg_nk_record { int32_t seg_len; /* length (always -ve because used) */ char id[2]; /* "nk" */ uint16_t flags; - cha...

...if not allocated anything yet). */ -}; - /* NB. All fields are little endian. */ struct ntreg_header { char magic[4]; /* "regf" */ uint32_t sequence1; uint32_t sequence2; - char last_modified[8]; + uint64_t last_modified; uint32_t major_ver; /* 1 */ uint32_t minor_ver; /* 3 */ uint32_t unknown5; /* 0 */ @@ -173,7 +135,7 @@ struct ntreg_nk_record { int32_t seg_len; /* length (always -ve because used) */ char id[2]; /* "nk" */ uint16_t flags; - cha...

...it/fstype/f2fs_fs.h @@ -0,0 +1,44 @@ +#ifndef __F2FS_FS_H +#define __F2FS_FS_H + +#define F2FS_SUPER_MAGIC 0xF2F52010 /* F2FS MAGIC */ +#define F2FS_MAX_EXTENSION 64 /* # of extension entries */ + +/* + * For superblock + */ +struct f2fs_super_block { + __le32 magic; /* Magic Number */ + __le16 major_ver; /* Major Version */ + __le16 minor_ver; /* Minor Version */ + __le32 log_sectorsize; /* log2 sector size in bytes */ + __le32 log_sectors_per_block; /* log2 # of sectors per block */ + __le32 log_blocksize; /* log2 block size in bytes */ + __le32 log_blocks_per_seg; /* log2 # of blocks per s...

.../* For writing. */ size_t endblocks; /* Offset to next block allocation (0 @@ -104,7 +106,7 @@ struct ntreg_header { char magic[4]; /* "regf" */ uint32_t sequence1; uint32_t sequence2; - char last_modified[8]; + uint64_t last_modified; uint32_t major_ver; /* 1 */ uint32_t minor_ver; /* 3 */ uint32_t unknown5; /* 0 */ @@ -173,7 +175,7 @@ struct ntreg_nk_record { int32_t seg_len; /* length (always -ve because used) */ char id[2]; /* "nk" */ uint16_t flags; - cha...

..._utf8 h v) + with + Not_found -> () + ); + + (* Version is complicated. Use CurrentMajorVersionNumber and + * CurrentMinorVersionNumber if present. If they are not + * found, fall back on CurrentVersion. + *) + (try + let major_v = List.assoc "CurrentMajorVersionNumber" values + and minor_v = List.assoc "CurrentMinorVersionNumber" values in + let major = Int32.to_int (Hivex.value_dword h major_v) + and minor = Int32.to_int (Hivex.value_dword h minor_v) in + data.ve...

This is, hopefully, a full fix for handling of li-records. See: https://bugzilla.redhat.com/show_bug.cgi?id=717583 https://bugzilla.redhat.com/show_bug.cgi?id=987463 Rich.

v10: https://www.redhat.com/archives/libguestfs/2017-July/msg00245.html No actual change here, but I rebased and retested. Also this series now does not depend on any other patch series since everything else needed is upstream. Rich.

v9 was here: https://www.redhat.com/archives/libguestfs/2017-July/msg00139.html This depends on these three series (the first two being single minor patches): https://www.redhat.com/archives/libguestfs/2017-July/msg00207.html https://www.redhat.com/archives/libguestfs/2017-July/msg00209.html https://www.redhat.com/archives/libguestfs/2017-July/msg00215.html There is no substantive change. I

This depends on the patch series "[PATCH 00/27] Reimplement many daemon APIs in OCaml." (https://www.redhat.com/archives/libguestfs/2017-July/msg00098.html) v8 was posted here: https://www.redhat.com/archives/libguestfs/2017-June/msg00274.html v9: - I split up the mega-patch into a more reviewable series of smaller, incremental patches. There are some other changes vs v8, but

This fixes almost everything. Note that it adds an extra commit which fixes the whole utf8/iconv business. It's probably better to list what isn't fixed: (1) I didn't leave the osinfo code around because I'm still haven't looked too closely at virt-builder-repository. Can't we just fetch this code from the git history when we need it? (2) I didn't change the way

v6 was posted here: https://www.redhat.com/archives/libguestfs/2017-June/msg00103.html and this requires the utilities refactoring posted here: https://www.redhat.com/archives/libguestfs/2017-June/msg00169.html Inspection is now complete[*], although not very well tested. I'm intending to compare the output of many guests using old & new virt-inspector to see if I can find any

v5: https://www.redhat.com/archives/libguestfs/2017-June/msg00065.html Since v5, this now implements inspection almost completely for Linux and Windows guests. Rich.

v7 was: https://www.redhat.com/archives/libguestfs/2017-June/msg00169.html https://www.redhat.com/archives/libguestfs/2017-June/msg00184.html I believe this addresses all comments received so far. Also it now passes a test where I compared about 100 disk images processed with old and new virt-inspector binaries. The output is identical in all cases except one which is caused by a bug in blkid