Дизассемблирование файла, содержащего большие данные или сжатого

В библиотеке дизассемблера udis86 есть очень полезный и удобный дизассемблер под названием udcli.

Например, что я сделал, чтобы понять ваш код:

Сначала скопируйте все байты шестнадцатеричного кода в файл ASCII. Я скопировал ваш вывод OllyDbg, а затем отрезал с помощью Vim все, кроме двоичного кода, в результате чего получился такой текстовый файл (скажем, hexcode.txt):

68 01 50 44 00 E8 01 00 00 00 C3 C3 A9 FE 39 B1 30 D8 BB A6 45 23 92 AC 3D B3 9C 8C 90 0E 26 3B D3 48 49 70 88 07 78 36 7C 88

Затем интересно, 16-битный, 32-битный или 64-битный код Intel ... обычно вы можете увидеть и почувствовать, если код кажется странным, в этом случае это либо неправильный процессор, неправильный режим процессора, либо код может быть зашифрован или это могут быть данные, а не код.

Давайте попробуем, если это 16-битный код:

В консоли Linux $ cat hexcode.txt | udcli -x -16

0000000000000000 680150           push word 0x5001        
0000000000000003 44               inc sp                  
0000000000000004 00e8             add al, ch              
0000000000000006 0100             add [bx+si], ax         
0000000000000008 0000             add [bx+si], al         
000000000000000a c3               ret                     
000000000000000b c3               ret                     
000000000000000c a9fe39           test ax, 0x39fe         
000000000000000f b130             mov cl, 0x30            
0000000000000011 d8bba645         fdivr dword [bp+di+0x45a6]
0000000000000015 2392ac3d         and dx, [bp+si+0x3dac]  
0000000000000019 b39c             mov bl, 0x9c            
000000000000001b 8c900e26         mov [bx+si+0x260e], ss  
000000000000001f 3bd3             cmp dx, bx              
0000000000000021 48               dec ax                  
0000000000000022 49               dec cx                  
0000000000000023 7088             jo 0xffffffffffffffad   
0000000000000025 07               pop es                  
0000000000000026 7836             js 0x5e                 
0000000000000028 7c88             jl 0xffffffffffffffb2   

Хм. Уже в начале inc sp очень странная инструкция. Вывод: не 16-битный код.

Может быть, это 32-битный код?

$ cat hexcode.txt | udcli -x -32

0000000000000000 6801504400       push dword 0x445001     
0000000000000005 e801000000       call dword 0xb          
000000000000000a c3               ret                     
000000000000000b c3               ret                     
000000000000000c a9fe39b130       test eax, 0x30b139fe    
0000000000000011 d8bba6452392     fdivr dword [ebx+0x922345a6]
0000000000000017 ac               lodsb                   
0000000000000018 3db39c8c90       cmp eax, 0x908c9cb3     
000000000000001d 0e               push cs                 
000000000000001e 263bd3           cmp edx, ebx            
0000000000000021 48               dec eax                 
0000000000000022 49               dec ecx                 
0000000000000023 7088             jo 0xffffffffffffffad   
0000000000000025 07               pop es                  
0000000000000026 7836             js 0x5e                 
0000000000000028 7c88             jl 0xffffffffffffffb2   

Это выглядит уже лучше. Во-первых, вы можете установить точку останова в 0x445001. Поскольку dword помещается непосредственно перед call dword 0xb, за которым следует ret, может случиться так, что ret после call 0xb фактически извлекает значение 0x445001 из стека и переходит к cs:0x445001. С другой стороны, если есть намерение запутать код, может случиться так, что функция, вызываемая с call dword 0xb, может изменить значение 0x445001, помещенное в стек, так что ret после call dword 0xb перейдет не на 0x445001, а куда-то еще. Поэтому установите другую точку останова на адрес стека, где хранится 0x445001. Перед вызовом функции call dword 0xb [ss:esp] должно указывать на значение 0x445001, поэтому установите там точку останова. Его можно задать и внутри функции, но в этом случае адрес будет [ss:esp+4] ([ss:esp] содержит обратный адрес). Поэтому я бы попробовал сначала установить эти 2 точки останова, а затем проследить код с пошаговым выполнением внутри функции call dword 0xb.

Последняя мысль: что, если это 64-битный код?

$ cat hexcode.txt | udcli -x -64

0000000000000000 6801504400       push dword 0x445001     
0000000000000005 e801000000       call dword 0xb          
000000000000000a c3               ret                     
000000000000000b c3               ret                     
000000000000000c a9fe39b130       test eax, 0x30b139fe    
0000000000000011 d8bba6452392     fdivr dword [rbx-0x6ddcba5a]
0000000000000017 ac               lodsb                   
0000000000000018 3db39c8c90       cmp eax, 0x908c9cb3     
000000000000001d 0e               invalid                 
000000000000001e 263bd3           cmp edx, ebx            
0000000000000021 48497088         jo 0xffffffffffffffad   
0000000000000025 07               invalid                 
0000000000000026 7836             js 0x5e                 
0000000000000028 7c88             jl 0xffffffffffffffb2

Начинается так же, как 32-битный код, но позже появляется недопустимая инструкция, поэтому, вероятно, это не 64-битный код (если только код не перехватывает обработчик исключения недопустимого кода операции int 6) или никогда не выполняет этот код.