Четырёхметровый EXE-шник, подгружающий тьму DLL, нервирует. IDA справляется легко, W32Dasm загибается. Страшно признаться, но не могу уже целый день снять ограничение по времени. Где идёт проверка неизвестно. Выяснил только, что это не всеми любимые GetLocalTime и прочие API. Сей продукт юзает MFC. Это бы ладно, но OLLY просто давится от EXCEPTION'ов(под SICE'ом ещё не пробовал, у меня его на работе нет пока, а сломать попросили именно там).
Кстати, интересная эта, блин, версия: В отличие от обычной коммерческой она не содержит НИКАКОЙ возможности для регистрации, хотя DLL-ки для этого предназначенные имеются. Предположительно, влом было их коцать, когда лепили ограничения и вырезали куски.

Вообщем, если кто возился с этой прогой, поделитесь инфой, буду рад любой квалифицированной помощи. Заранее спасибо.

| Сообщение посчитали полезным:

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

push esi
lea eax, [ebp+SystemTimeAsFileTime]
push eax ; lpSystemTimeAsFileTime
call GetSystemTimeAsFileTime
mov esi, [ebp+SystemTimeAsFileTime.dwHighDateTime]
xor esi, [ebp+SystemTimeAsFileTime.dwLowDateTime]
call GetCurrentProcessId
xor esi, eax
call GetCurrentThreadId
xor esi, eax
call GetTickCount
xor esi, eax
lea eax, [ebp+PerformanceCount]
push eax ; lpPerformanceCount
call QueryPerformanceCounter
mov eax, dword ptr [ebp+PerformanceCount+4]
xor eax, dword ptr [ebp+PerformanceCount]
xor esi, eax
mov dword_7954B0, esi
jnz short loc_606CD7
mov dword_7954B0, 0BB40E64Eh
pop esi
leave
retn

| Сообщение посчитали полезным:

хаха

а вот и нет.

это не кусок защиты.
этот код я встречал почти во всех продуктах, собраных в visual studio 2005 (насчет 2003 тоже подозреваю но не уверен)

обычно entry point выгляди так:


.text:00401275 public start
.text:00401275 start proc near
.text:00401275 call sub_402956
.text:0040127A jmp loc_401096
.text:0040127A start endp


где sub_402956 и есть вышеприведенная функция.

| Сообщение посчитали полезным:

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

.text:00402956 sub_402956 proc near ; CODE XREF: startp
.text:00402956
.text:00402956 PerformanceCount= LARGE_INTEGER ptr -10h
.text:00402956 SystemTimeAsFileTime= _FILETIME ptr -8
.text:00402956
.text:00402956 push ebp
.text:00402957 mov ebp, esp
.text:00402959 sub esp, 10h
.text:0040295C mov eax, dword_40A000
.text:00402961 and [ebp+SystemTimeAsFileTime.dwLowDateTime], 0
.text:00402965 and [ebp+SystemTimeAsFileTime.dwHighDateTime], 0
.text:00402969 push ebx
.text:0040296A push edi
.text:0040296B mov edi, 0BB40E64Eh
.text:00402970 cmp eax, edi
.text:00402972 mov ebx, 0FFFF0000h
.text:00402977 jz short loc_402986
.text:00402979 test ebx, eax
.text:0040297B jz short loc_402986
.text:0040297D not eax
.text:0040297F mov dword_40A004, eax
.text:00402984 jmp short loc_4029E6
.text:00402986 ; ---------------------------------------------------------------------- -----
.text:00402986
.text:00402986 loc_402986: ; CODE XREF: sub_402956+21j
.text:00402986 ; sub_402956+25j
.text:00402986 push esi
.text:00402987 lea eax, [ebp+SystemTimeAsFileTime]
.text:0040298A push eax ; lpSystemTimeAsFileTime
.text:0040298B call ds:GetSystemTimeAsFileTime
.text:00402991 mov esi, [ebp+SystemTimeAsFileTime.dwHighDateTime]
.text:00402994 xor esi, [ebp+SystemTimeAsFileTime.dwLowDateTime]
.text:00402997 call ds:GetCurrentProcessId
.text:0040299D xor esi, eax
.text:0040299F call ds:GetCurrentThreadId
.text:004029A5 xor esi, eax
.text:004029A7 call ds:GetTickCount
.text:004029AD xor esi, eax
.text:004029AF lea eax, [ebp+PerformanceCount]
.text:004029B2 push eax ; lpPerformanceCount
.text:004029B3 call ds:QueryPerformanceCounter
.text:004029B9 mov eax, dword ptr [ebp+PerformanceCount+4]
.text:004029BC xor eax, dword ptr [ebp+PerformanceCount]
.text:004029BF xor esi, eax
.text:004029C1 cmp esi, edi
.text:004029C3 jnz short loc_4029CC
.text:004029C5 mov esi, 0BB40E64Fh
.text:004029CA jmp short loc_4029D7
.text:004029CC ; ---------------------------------------------------------------------- -----
.text:004029CC
.text:004029CC loc_4029CC: ; CODE XREF: sub_402956+6Dj
.text:004029CC test ebx, esi
.text:004029CE jnz short loc_4029D7
.text:004029D0 mov eax, esi
.text:004029D2 shl eax, 10h
.text:004029D5 or esi, eax
.text:004029D7
.text:004029D7 loc_4029D7: ; CODE XREF: sub_402956+74j
.text:004029D7 ; sub_402956+78j
.text:004029D7 mov dword_40A000, esi
.text:004029DD not esi
.text:004029DF mov dword_40A004, esi
.text:004029E5 pop esi
.text:004029E6
.text:004029E6 loc_4029E6: ; CODE XREF: sub_402956+2Ej
.text:004029E6 pop edi
.text:004029E7 pop ebx
.text:004029E8 leave
.text:004029E9 retn
.text:004029E9 sub_402956 endp



вопрос спецам(на засыпку?):
а что это за константа 0BB40E64Eh в данном куске
.text:0040296B mov edi, 0BB40E64Eh
.text:00402970 cmp eax, edi
.text:00402972 mov ebx, 0FFFF0000h
.text:00402977 jz short loc_402986

гугол помнится ничего толкового не выдавал, где-то упоминалось, что это мол есть magic value, что это за значение и почему оно magic, нигде нет.

| Сообщение посчитали полезным:

intty пишет:
вопрос спецам(на засыпку?):
а что это за константа 0BB40E64Eh в данном куске
Гы-гы, число пи помноженное на 10?
Становится интересно

| Сообщение посчитали полезным:

в общем удалось еще кое-что накопать:
оказывается функция эта называется security_init_cookie()
в гугле по этому поводу только один резулт(и тот только в кэше), но частично ясность вносит:

Micorsoft's protection is similar to Stack Guard in the fact that both use a canary4 to protect the return address. However,there is a subtle difference. Microsoft does protect the frame pointer by placing a random canary between it and the local varaiables. The security cookie in this case is initialized in a function called security_init_cookie() which you can find in the file seccinit.c in crt sources that come with Microsoft's Visual Studio .NET. This function is called once, every time the program is started. The security cookie is generated XORing the answer of 5 different functions: GetCurrentProcessId(), GetCurrentThreadId(), GetTickCount(), GetSystemTimeAsFileTime() and QueryPerformanceCounter()19. In Windows NT and 2000, the first too are generated not so randomly (check PIDs in Task Manager). The other 3 are timers. If exploiting something locally, timers can be determined pretty acu- rately, if exploiting remotely, it's not that easy. As the process being exploited will raise an error if you don't know the right value, and as the precision for QueryPerformanceCounter() is really high, bruteforcing is not that straight forward. Like Stack Guard, it is emebeded in C/C++ compiler.



66.249.93.104/search?q=cache:U1XpQTfq91sJ:www.cse.iitk.ac.in/users/avijitk/cs397/node25.html+security_init_cookie&hl=en&gl=ru&ct=clnk&cd=1

по поводу магического валуя ) вопрос открыт

| Сообщение посчитали полезным:

bash пишет:
число пи помноженное на 10
то есть на миллиард (простите, ошибся самую малость )

| Сообщение посчитали полезным:

Кое-что о магических значениях (числах):

"Magic debug values are specific values written to memory during allocation or deallocation, so that it will later be possible to tell whether or not they have become corrupted and to make it obvious when values taken from uninitialized memory are being used.

Memory is usually viewed in hexadecimal, so common values used are often repeated digits or hexspeak.

Famous and common examples include:
0x..FACADE : Used by a number of RTOSes
0xABABABAB : Used by Microsoft's LocalAlloc() to mark "no man's land" guard bytes after allocated heap memory
0xBAADF00D : Used by Microsoft's LocalAlloc(LMEM_FIXED) to mark uninitialised allocated heap memory
0xBADBADBADBAD : Burroughs B6700 "uninitialized" memory (48-bit words)
0xC001D00D
0xC0DEBABE
0xC0EDBABE
0xCACACACA
0xCAFEBABE : Used as the first four bytes of every Java .class file.
0xCAFECAFE
0xCAFEFEED : Used by Sun Microsystems' Solaris debugging kernel to mark kmemfree() memory
0xCCCCCCCC : Used by Microsoft's C++ debugging heap to mark uninitialised stack memory
0xCDCDCDCD : Used by Microsoft's C++ debugging heap to mark uninitialised heap memory
0xDDDDDDDD : Used by MicroQuill's SmartHeap and Microsoft's C++ debugging heap to mark freed heap memory
0xDEADBABE : Used at the start of Silicon Graphics' IRIX arena files
0xDEADBEEF : Famously used on IBM systems such as the RS/6000, also in OPENSTEP Enterprise and the Commodore Amiga
0xDEADDEAD : A Microsoft Windows STOP Error code used when the user manually initiates the crash.
0xDECAFBAD
0xEBEBEBEB : From MicroQuill's SmartHeap
0xFDFDFDFD : Used by Microsoft's C++ debugging heap to mark "no man's land" guard bytes before and after allocated heap memory
0xFEEDBABE
0xFEEDFACE : Seen in Mach-O binaries on Apple's Mac OS X platform
0xFEEEFEEE : Used by Microsoft's HeapFree() to mark freed heap memory"

| Сообщение посчитали полезным: