From 4ad95e3ae44b06199652ffc855df523a6990e4a7 Mon Sep 17 00:00:00 2001 From: Eric Biggers Date: Sat, 26 Jul 2014 00:58:40 -0500 Subject: [PATCH] lzms-common.c: Don't process first byte in x86 filter Microsoft's LZMS compressor and decompressor seemingly skip this byte. This resulted in different behavior on the following uncompressed data: 0000000 e8 6b e8 fb ff 5e 1f 03 e8 63 e8 fb ff 5e c0 02 0000016 e8 5b e8 fb ff 5e 51 01 e8 53 e8 fb ff 5e c4 00 wimlib would do a translation following the e8 byte at offset 16, since it would enable x86 translations following the identification of matching absolute addresses following the potential opcodes at offsets 0 and 8. But as far as I can tell, the Microsoft implementation just skips byte 0 entirely and doesn't consider it as beginning a potential instruction. --- src/lzms-common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/lzms-common.c b/src/lzms-common.c index db9bd905..e274c6ba 100644 --- a/src/lzms-common.c +++ b/src/lzms-common.c @@ -317,7 +317,7 @@ lzms_x86_filter(u8 data[restrict], s32 size, for (s32 i = 0; i < 65536; i++) last_target_usages[i] = -LZMS_X86_MAX_GOOD_TARGET_OFFSET - 1; - for (s32 i = 0; i < size - 16; ) { + for (s32 i = 1; i < size - 16; ) { s32 max_trans_offset; s32 n; -- 2.46.1