Problem with read_unicode_str_va function

[0xarash]

Hello,

I'm trying to read UNICODE_STRING from a structure but hadn't any luck. Here is a info I have about the problem:

I did test on different structures, I could extract the string and the length manually with vmi.read_va, and some other functions

I checked read_unicode_str_va, the returned value.encoding and value.length seems correct, but value.contents not. extracted buffer just have one character of the string.

The host is CentOS 7 and python version is 3.6.8

Here is the error message I receive:

UnicodeDecodeError: 'utf-16-le' codec can't decode byte 0x50 in position 0: truncated data

Here is the snipped code I'm using for test.

with pause(vmi):
    process_type_va = vmi.translate_ksym2v('PsProcessType')
    process_type = vmi.read_addr_va(process_type_va, 0)
    name_off = vmi.get_kernel_struct_offset('_OBJECT_TYPE', 'Name')
    name = vmi.read_unicode_str_va(process_type + name_off, 0)
    print(name)

Any idea how to deal with this problem

[Wenzel]

Hi,

Can you paste the full stack trace, so that we can see which line throws the error ?

Also, can try to repro this issue with the C library and see if it works (or not ?)

Thanks.

[0xarash]

Ok, thanks for the help. I tested with C library, it's working, the return string is 'Process' which is the expected result.

and here is the stack trace:

Traceback (most recent call last):
  File "demo.py", line 78, in <module>
    ret = main(args)
  File "demo.py", line 53, in main
    name = vmi.read_unicode_str_va(process_type + name_off, 0)
  File "/home/user/_/venv/lib64/python3.6/site-packages/libvmi-3.4-py3.6-linux-x86_64.egg/libvmi/libvmi.py", line 644, in read_unicode_str_va
    return buffer.decode(encoding)
UnicodeDecodeError: 'utf-16-le' codec can't decode byte 0x50 in position 0: truncated data

[0xarash]

I investigate the problem further, it seems like ffi.string() function, if cdata point to pointer of bytes (in our case uint8_t *contents) stop at first null. One solution is to use ffi.unpack() instead.

[Wenzel]

@0xarash thanks for investigating.

Could you make a pull request when you have a working solution ?
Thanks.

[0xarash]

@Wenzel OK I would create a PR today.