(MODULES-2409) Endian-ness incorrect for DWORD and QWORD #95
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@joshcooper if you want to take a look this should be good. |
| when Win32::Registry::REG_QWORD | ||
| bytes = to_byte_array(data, FFI::Type::UINT64.size) | ||
| # Q is 64-bit unsigned native (little) endian order | ||
| bytes = [data].pack('Q').unpack('C*') |
There was a problem hiding this comment.
irb(main):007:0> [0x12345678].pack('L').unpack('C*').map {|ch| ch.to_s(16)}
=> ["78", "56", "34", "12"]
irb(main):008:0> [0x1234567890ABCDEF].pack('Q').unpack('C*').map {|ch| ch.to_s(16)}
=> ["ef", "cd", "ab", "90", "78", "56", "34", "12"]
👍
- In 0b99718 a helper method to_byte_array was introduced to convert a numeric value into a properly padded byte array. Unfortunately that introduced an error as the byte array ordering was incorrect. This has caused DWORD and QWORD values to be written wrong. For instance, creating a native (little) endian string from a large 32-bit value (4294967294) should yield the following bytes: pry(main)> [2**32-2].pack('L').unpack('C*') => [254, 255, 255, 255] That can be further round-tripped with .pack('C*').unpack('L*')[0] However, using to_bytes_array, the bytes come back improperly ordered pry(main)> to_byte_array(2**32-2, 4) => [255, 255, 255, 254] pry(main)> [255, 255, 255, 254].pack('C*').unpack('L*')[0] => 4278190079 As a result, because of the improper ordering of bytes, the wrong value is written. - Previous tests were passing since the range of written values tested was below 0xFF (255). The first point at which written values diverge is 256, where the byte array [0, 1, 0, 0] should have been created, but instead [1, 0, 0, 0] was written. Therefore, new tests have been added to test writing DWORD and QWORD values at each byte boundary + 1 bit - for instance 0xFF + 1, 0xFFFF + 1, ad nauseum. - The simplest additional test to perform was to validate that the written values from the deletion test match what is expected. These values are randomly generated.
- Add an additional check to ensure that the registry 'write' method is never called, which can trigger Ruby's bad behavior.
da3bd6e to
c022d8c
Compare
|
@joshcooper added some additional tests that verify round-trips. With the previous code, they all fail: I think this is ready to go now. |
| @@ -30,6 +30,9 @@ | |||
| # also, expect that we're not using Rubys each_key / each_value which exhibit bad behavior | |||
| Win32::Registry.any_instance.expects(:each_key).never | |||
| Win32::Registry.any_instance.expects(:each_value).never | |||
|
|
|||
| # this covers []= write_s write_i and write_bin | |||
| Win32::Registry.any_instance.expects(:write).never | |||
|
👍 |
|
Looks good. Merging. |
ferventcoder
added a commit
that referenced
this pull request
Aug 13, 2015
…-qword-endianess-wrong (MODULES-2409) Endian-ness incorrect for DWORD and QWORD
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In 0b99718 a helper method to_byte_array was introduced to convert
a numeric value into a properly padded byte array. Unfortunately
that introduced an error as the byte array ordering was incorrect.
This has caused DWORD and QWORD values to be written wrong.
For instance, creating a native (little) endian string from a large
32-bit value (4294967294) should yield the following bytes:
pry(main)> [2*32-2].pack('L').unpack('C')
=> [254, 255, 255, 255]
That can be further round-tripped with .pack('C_').unpack('L_')[0]
However, using to_bytes_array, the bytes come back improperly ordered
pry(main)> to_byte_array(2**32-2, 4)
=> [255, 255, 255, 254]
pry(main)> [255, 255, 255, 254].pack('C_').unpack('L_')[0]
=> 4278190079
As a result, because of the improper ordering of bytes, the wrong
value is written.
Previous tests were passing since the range of written values
tested was below 0xFF (255). The first point at which written
values diverge is 256, where the byte array [0, 1, 0, 0] should
have been created, but instead [1, 0, 0, 0] was written.
The simplest additional test to perform was to validate that the
written values from the deletion test match what is expected.