Пожалуйста подскажите другие простые алгоритмы нахождения хеш-ей строк

Пробую писать маленький шелл.
Все адреса нужных функций в стеке адресация по ebp.
Поиск функций в кернеле по известному их хешу из заготовленной.
Хеш для каждого имени ищу по такому алгоритму ->

Код (Text):

1. main:
2.     invoke  GetCL,1,addr string_; возьмем первый аргумент командной строки
3.     .if eax == 1        ; если нет ни одного аргумента выход
4.                
5.     .else           ; вывод сообщения о правилах использования      
6.         invoke  StdOut,addr Error1
7.         jmp _Exit
8.     .endif
9.           xor   esi,esi
10.     mov esi,offset string_
11. _GetHash:
12.           xor   eax,eax
13.           push  eax
14. _CalcHash:
15.           ror   eax,7
16.           xor   [esp],eax
17.           lodsb
18.           test  al,al
19.           jnz   _CalcHash
20.           pop   eax
21.  
22.           xor   ebx,ebx
23.     mov ebx,eax
24.  
25.     invoke  RtlZeroMemory,ADDR buffer,256  
26.     invoke  wsprintf,addr buffer,addr template,addr string_, ebx
27.     invoke  StdOut, addr buffer
28. _Exit:
29.     ret
30. end main

Сам алгоритм взял тут же у кого-то из раздела "Вирусология"
Проблема - две функции имеют одинаковый хеш:

Код (Text):

1. CreateFileMapping            : 0x9CA63AEAh
2. NlsConvertIntegerToString : 0x9CA63AEAh

Сам в математике не силен, теорию чисел пока не изучаем
Пожалуйста подскажите еще другие простые алгоритмы нахождения хеш-ей строк. Спасибо.

 

Посмотри тут: http://ru.wikipedia.org/wiki/Хеш-таблица

 

Monogen
моя дяка тобi шановный - що вказав менi на це нэпахане полэ ))

 

Попробуйте так разнообразить код:
...
mov cl, al
ror eax, cl
...

На самом деле, коллизии неизбежны. Вопрос только в том, будут они для вашего набора символов или нет

 

хэш функция - это любая функция, позволяющая однозначно уменьшить неплотное множество больших чисел в сторону повышения плотности. чем меньше коллизий, тем хэш функция лучше.

на практике, для 100% отсутствия коллизий это подбирается. для начала нужен словарь всех слов/срок (больших чисел) для которых вы хотите считать хэш без коллизий.
ваше максимальное хэш-число должно быть > общего количества ваших строк.

далее, вы пишете свои функции или берете готовые, или берете готовые, а потом модифицируете их сами. и прогоняете по вашему списку. не возникнет коллизий - функция найдена.

 

7mm
qqwe
Спасибо, будем перебирать.
Придется видно перебирать все строки из kernell32.dll
Их там примерно около 1000 значит разрядов у хеша должно быть 10. 2^10 = 1024,
А у меня (0x9CA63AEAh) как видно - 8, значит коллизии очень вероятны
Еще раз спасибо за разъяснение.
Кстати статья (http://ru.wikipedia.org/wiki/%D0%A5%D0% … 1%86%D0%B0), таки, доходчиво написана, извините.

 

_sheva740

..ваше хэш-число будет колебаться от 0 до >999. 1024 это 10 разрядов. те, в 2 байта должно влезть.

 

http://blog.harmonysecurity.com/2009/08/calling-api-functions.html

Вот тут ещё посмотрите, там авторы используют хеш-функцию наподобие вашей. В конце статьи про коллизии речь идёт - типа на частоиспользуемых библиотеках коллизий не зафиксировано. На самом деле, не совсем понятно, зачем вам сильная хеш-функция, если обычно требуется найти пару-тройку символов, типа VirtualAlloc Смысл же всей этой затеи с хешами имён - это сокращение размера кода и исключение мозолящих глаза строк типа GetProcAddress ))

 

qqwe
сознаю, пупанул.
7mm

немного не понял, ну как зачем, не писать же мне открыто имена этих функций. Можно конечно вся кое шифрование, но код так разростается что мне показалось разумным именно выбрать старый путь получения адресов.
Да мне вот этот список хотелось

Код (Text):

1. CloseHandle_       
2. FindFirstFileA_    
3. FindNextFileA_     
4. CreateFileA_       
5. CreateFileMapping_ 
6. MapViewOfFile_     
7. GetFileSize_       
8. UnmapViewOfFile_   
9. VirtualProtect_    
10. ExitProcess_       
11. SetCurrentDirectoryA_

... а их я из kernell32.dll все нахожу.

 

А в чём разница, используете вы, например, строку "CloseHandle", или подставляете вместо неё хеш? С точки зрения обнаружения -- и то, и то определённая сигнатура Одно только использование хешей не поможет вам избежать детекта.

 

согласен, не избавит.
Ну тогда, как вариант, - все находится открыто (без всяких хэш-ей) но сверху все покрыть xor - ом.
Да просто так вот наметил себе с этим хешем и уперся. Теперь действительно развилка или добить с ним или отказаться а подумать о шифровании.

 

Да не, использовать хеш -- это однозначно. И шифрование сверху, тоже обязательно. И морфинг....

 

Mikl___
... ооо шайтан, не ребята так далеко я пока не заплываю, глубины боюсь. ))
Мне бs хоть одно до конца довести (насладиться прелестью завершенного действа ),
а потом непременно вернемся к написанию шелов -вирей через native-api.

 

взял crc16, все вроде нормально

Код (Text):

1. .386
2. .model flat,stdcall
3. option casemap:none
4. include \masm32\include\windows.inc
5. include \masm32\include\user32.inc
6. include \masm32\include\kernel32.inc
7. include \masm32\include\masm32.inc
8. includelib \masm32\lib\user32.lib
9. includelib \masm32\lib\kernel32.lib
10. includelib \masm32\lib\masm32.lib
11. ;--------------------------------------------------------
12. .data
13. szAPIname BYTE 0
14.     BYTE "CloseHandle",0
15.     BYTE "CreateFileA",0
16.     BYTE "CreateFileMappingA",0
17.     BYTE "ExitProcess",0
18.     BYTE "FindFirstFileA",0
19.     BYTE "FindNextFileA",0
20.     BYTE "GetFileSize",0
21.     BYTE "MapViewOfFile",0
22.     BYTE "SetCurrentDirectoryA",0
23.     BYTE "UnmapViewOfFile",0
24.     BYTE "VirtualProtect",0,0,0
25.  
26.  
27.     template        db "%s_ dd 0%ph",13,10,0    ;шаблон
28.     buffer      db 256 dup( 0 )     ;для вывода
29. ;--------------------------------------------------------
30. .code
31. main:       lea esi, szAPIname
32. ___load_next_name:  lodsb
33.         test    al, al
34.         jnz ___load_next_name
35.         mov al, BYTE PTR [esi]
36.         test    al, al
37.         jz  __ListDone
38. ;--------------------------------------------------------
39. ; from Win32.Kriz.asm
40. ; ESI = ASCIIZ / returns AX = CRC16.
41. ;--------------------------------------------------------
42. Calculate_CRC16:    push    edx
43.         push    esi
44.         push    0FFFFFFFFh
45.         pop     edx
46.         cld
47. Load_Character: lodsb
48.         or      al, al
49.         jz      Exit_Calc_CRC
50.         xor     dl, al
51.         mov     al, 8
52. CRC_Byte:       shr     edx, 1
53.         jnc     Loop_CRC_Byte
54.         xor     edx, 0EDB88320h
55. Loop_CRC_Byte:  dec     al
56.         jnz     CRC_Byte
57.         jmp     Load_Character
58. Exit_Calc_CRC:  xchg    edx, eax
59.         pop     esi
60.         pop     edx
61. ;--------------------------------------------------------
62.             xor ebx,ebx
63.         mov ebx,eax
64.         invoke  RtlZeroMemory,ADDR buffer,256  
65.         invoke  wsprintf,addr buffer,addr template,esi, ebx
66.         invoke  StdOut, addr buffer
67.         jmp ___load_next_name
68. __ListDone: invoke  ExitProcess,0
69.         ret
70. end main
71. ;--------------------------------------------------------

 

_sheva740,

Вообще говоря, это CRC32.
Побитно он небыстрый (из-за partial EFLAGS и по мелочам). С 1 KiB таблицей можно брать CRC32 от первых восьми байт без цикла, может хватить.

 

_sheva740
Чем вас шифрование не устраивает?


Mikl___

для WinXP там sysenter.