Bug 982057 - hivex-value-utf8 failed "hivex: conversion of registry value to UTF8 failed"
hivex-value-utf8 failed "hivex: conversion of registry value to UTF8 failed"
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libguestfs (Show other bugs)
6.5
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Richard W.M. Jones
Virtualization Bugs
:
Depends On:
Blocks: 982058
  Show dependency treegraph
 
Reported: 2013-07-07 22:53 EDT by bfan
Modified: 2013-07-18 13:19 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 982058 (view as bug list)
Environment:
Last Closed: 2013-07-18 13:19:54 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description bfan 2013-07-07 22:53:08 EDT
Description of problem:
Use 'hivex-node-set-value' to set value with type=1 (type=1, A Windows string (encoding is unknown, but often UTF16-LE)), and read that value by hivex-value-utf8, command failed.

I check the value in a running windows guest, it's an unreadable code. may hivex-node-set-value does not work well.


Version-Release number of selected component (if applicable):
libguestfs-1.20.9-6.el6.x86_64


How reproducible:
100%


Steps to Reproduce:
1. prepare a windows guest, Win2003-32 bit
2. use hivex-node-set-value to set a value with type=1
3. use "hivex-value-utf8" to read the value


Actual results:
hivex: conversion of registry value to UTF8 failed


Expected results:
get the correct result


Additional info:
same issue in rhel7, libguestfs-1.22.2-1.el7.x86_64
Comment 1 Richard W.M. Jones 2013-07-08 03:25:18 EDT
What's the precise code you're running to set and get the value?
Comment 2 bfan 2013-07-08 05:05:58 EDT
(In reply to Richard W.M. Jones from comment #1)
> What's the precise code you're running to set and get the value?

I set string "hello" with key='mykey' and type=1 in guestfish, and can find 'mykey' in windows registry, but the its value is gibberish not 'hello'.
Comment 3 Richard W.M. Jones 2013-07-08 05:33:09 EDT
Here's a "reproducer" (note: I don't think this is a bug).
You will need the 'minimal' file from hivex source here:
https://github.com/libguestfs/hivex/blob/master/images/minimal

#!/bin/bash -

guestfish -x -N fs -m /dev/sda1 <<EOF

upload /mnt/scratch/minimal /minimal
hivex-open /minimal write:true

hivex-root
# 0x1020

hivex-node-set-value 0x1020 mykey 1 hello

hivex-node-get-value 0x1020 mykey
# 0x2028

hivex-value-value 0x2028
hivex-value-utf8 0x2028

EOF
Comment 4 Richard W.M. Jones 2013-07-08 05:47:04 EDT
The problem is the following line:

  hivex-node-set-value 0x1020 mykey 1 hello

This sets the contents of the hive value to the bytes
"hello" (I believe without any trailing \0).  However
Windows would expect a UTF16-LE string here (hivex does
no conversion).  guestfish doesn't let you write a
string containing \0 escapes, but you could do it in
another language, eg in Perl:

#!/usr/bin/perl -w

use Data::Dumper;
use Sys::Guestfs;

my $disk = "/tmp/test.img";
my $minimal = "/mnt/scratch/minimal";
#my $value = "hello\0";
my $value = "h\0e\0l\0l\0o\0\0\0";

unlink $disk;
open DISK, ">$disk" or die "$!";
truncate DISK, 100*1024*1024 or die "$!";
close DISK or die "$!";

my $g = Sys::Guestfs->new ();
$g->set_trace (1);
$g->add_drive ($disk, format => "raw");
$g->launch ();
$g->part_disk ("/dev/sda", "mbr");
$g->mkfs ("ext2", "/dev/sda1");
$g->mount ("/dev/sda1", "/");
$g->upload ($minimal, "/minimal");
$g->hivex_open ("/minimal", write => 1);
my $root = $g->hivex_root ();
$g->hivex_node_set_value ($root, "mykey", 1, $value);
my $valh = $g->hivex_node_get_value ($root, "mykey");
printf ("raw value = %s\n", Dumper ($g->hivex_value_value ($valh)));
printf ("utf8 value = %s\n", Dumper ($g->hivex_value_utf8 ($valh)));
Comment 5 Richard W.M. Jones 2013-07-18 13:19:54 EDT
To the best of my knowledge, this is NOTABUG based
on the rationale in comment 3 & comment 4, therefore
I am closing this.

Note You need to log in before you can comment on or make changes to this bug.