Осталось тут три дня до активации, а никакие кряки существующие не помогли, пришлось самому копать эту активацию. Оказалось, что если пропатчить один переход в winlogon'е, то активация проверяться не будет. Кряк работает на XP Pro SP2 точно, насчёт других комбинаций не знаю.

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

RideX
обойтись только одной DLL
Типа так?
типа как это делается, когда патчится ASProtectченнная прога, которая грузит DLL
т.о. получается универсальное решение, не нарушающее целостность файла

добавить в код DllMain какой-либо из библиотек, кот. грузит winlogon, пропатчивание самого winlogon'a

-----
EnJoy!

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

RideX пишет:
Типа так?

Именно так.

только в обработчике DLL_PROCESS_ATTACH
нужно возвращать TRUE, иначе ниЧЧё не получится,
т.е. DLL не загрузится ;)

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

Asterix пишет:
все существующие кейгены только для так
называемых корпоративных версий

Для корпоративных версий активация вообще не требуется ;)

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

S_T_A_S_ пишет:
Для корпоративных версий активация вообще не требуется ;)

Там все-равно нужен кейген, который генерит установочный номер,
потом можно проверить свежеустановленную систему с этим номером
на сайте MS ;)

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

Asterix пишет:
потом можно проверить свежеустановленную систему с этим номером
на сайте MS
не, уже низзя.
я раньше так и делал, но все время получал ответ типа, ваш номер вроде пирейтед. обратитесь к сисадмину за другим номером. на ру-борде прочел, что для корпоративки д.б. 640-642.
накачал новых кейгенов, сгенерил, полез на MS проверить - а там такого сервиса уже нет!
пишут про то как отличить правильную винду от пиратской - всякие там лейблы, сертификаты и голограммы.
а если сомневаетесь, грят, пришлите ваш продукт нам на экспертизу. LOL!
видимо последние кейгены действительно хороши, не могут больше MS по сидикею пиратов ловить!

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

Asterix пишет:
нужно возвращать TRUE, иначе ниЧЧё не получится, т.е. DLL не загрузится ;)
А я подумал зачем DLL в памяти болтаться, после того как сделает свою работу =)
У меня это работает одинаково с TRUE/FALSE:

.486

.model flat,stdcall

option casemap :none



include \masm32\include\windows.inc

include \masm32\include\kernel32.inc

include \masm32\include\user32.inc

includelib \masm32\lib\kernel32.lib

includelib \masm32\lib\user32.lib



.data

 szCaption      TCHAR "DLLApp",0

 szHello        TCHAR "Hello from DLL",0



 bNewByte       BYTE   090h

 hProcess       HANDLE ?



.code

DllMain proc hInstance :HINSTANCE, dwReason WORD, lpReserved :LPVOID

        .if dwReason == DLL_PROCESS_ATTACH

                invoke GetCurrentProcessId

                invoke OpenProcess, PROCESS_ALL_ACCESS, FALSE, eax

                .if eax != NULL

                        mov hProcess,eax

                        invoke WriteProcessMemory, hProcess, 00401000h, addr bNewByte,\

                                sizeof bNewByte, NULL

                        invoke CloseHandle,hProcess

                .endif

                invoke MessageBox, NULL, addr szHello, addr szCaption, MB_ICONINFORMATION

	.endif

        xor eax,eax

;	inc eax

        ret

DllMain endp

end DllMain

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

RideX пишет:
А я подумал зачем DLL в памяти болтаться, после того как сделает свою работу =)

В принципе тоже мысль правильная ;)

Что до листинга то GetCurrentProcess будет вполне достаточно ;)
также неплохо перед тем как патчить узнать адрес загрузки exe, мало ли что ;)

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

Asterix
У меня диск SP2 уже полгода наверное лежит, всё пока никак не решусь поставить (сейчас стоИт SP1 + несколько заплаток). А antiwpa для SP2 не нравится тем, что процесс постоянно висит в памяти, метод предложенный dragon лучше

Только что проверил, winlogon не грузит DLL если нет ключа:

"Logon"=<export_funcname_from_dll>

но хотя бы пустой ключ его устраивает В остальном наша DLL отрабатывает как ожидалось и не висит в памяти. Теперь уже точно можно будет переходить к "упражнениям" с самим winlogon ;)

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

Asterix пишет:
GetCurrentProcess будет вполне достаточно ;)
Просто мне показалось это более надёжным %)

1. The GetCurrentProcess function retrieves a pseudo handle for the current process.

2. The GetCurrentProcessId function retrieves the process identifier of the calling process.

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

RideX
А antiwpa для SP2 не нравится тем, что процесс постоянно висит в памяти
AntiWPA c antiwpa3.tk/ патчит winlogon, a не висит в памяти
но в любом случае корпоративная версия предпочтительнее
в сети полно ресурсов о том, как самому сделать корпоративный образ XP

-----
EnJoy!

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

RideX
В случае использования GetCurrentProcess тебе не нужно открывать процесс,
у тебя и так будет хэндл

invoke WriteProcessMemory, $invoke(GetCurrentProcess), 00401000h, addr bNewByte,\
sizeof bNewByte, NULL

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

я про кейгены от again и zwt... как??? можно было закейгенить ecc-512??? кто-нить в курсе, что за дырки были в реализации

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

ssx
ктож об этом расскажет... но я могу попробовать уточнить у мемберов again

-----
once you have tried it, you will never want anything else

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

Jupiter
Просто я у кого-то видел, а т.к. больше крэков к SP2 не знаю, то подумал что это и есть antiwpa.

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

Asterix
Понял, тогда значит так?

.486

.model flat,stdcall

option casemap :none



include \masm32\include\windows.inc

include \masm32\include\kernel32.inc

include \masm32\include\user32.inc

includelib \masm32\lib\kernel32.lib

includelib \masm32\lib\user32.lib





.data

 szCaption      TCHAR "DLLApp",0

 szHello        TCHAR "Hello from DLL. Dump right now!",0



align 4

 dwOffsets      DWORD  00001000h, 00001001h, 00001002h, 00001003h, 00001004h

                DWORD  00001005h, 00001006h, 00001007h, 00001008h, 00001009h



 bNewBytes      BYTE   090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h

 nNewBytes      equ    $ - bNewBytes





.code

DllMain proc hInstance :HINSTANCE, dwReason WORD, lpReserved :LPVOID

        .if dwReason == DLL_PROCESS_ATTACH

                pushad

                invoke GetModuleHandle, NULL

                mov edx,eax

                invoke GetCurrentProcess



                xor ecx,ecx

                mov ebx,offset dwOffsets

                mov esi,offset bNewBytes

             @@:

                pushad

                add esi,ecx

                mov edi,[ebx + ecx*4]

                add edi,edx

                invoke WriteProcessMemory, eax, edi, esi, 1, NULL

                popad

                inc ecx

                cmp ecx,nNewBytes

                je  @f

                jmp @b

             @@:

                invoke MessageBox, NULL, addr szHello, addr szCaption, MB_ICONINFORMATION

                popad

        .endif

        xor eax,eax

        ret

DllMain endp

end DllMain

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

зачем pushad/popad
просто пишешь DllMain proc uses ebx esi edi hInstance :HINSTANCE, dwReason WORD, lpReserved :LPVOID

> mov edx,eax
> invoke GetCurrentProcess

так нельзя, MS не гаранирует сохранность eax, edx, ecx после GetCurrentProcess

а побайтная запись через WriteProcessMemory тоже для прикола?

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

Asterix пишет:
uses ebx esi edi
если так, то они будут находиться сразу после пролога, я сохраняю только там где их использую - в обработчике DLL_PROCESS_ATTACH. Или это без разницы?

Asterix пишет:
MS не гаранирует сохранность eax, edx, ecx
Точно, тогда

invoke GetModuleHandle, NULL

push eax

invoke GetCurrentProcess

pop edx

Asterix пишет:
побайтная запись через WriteProcessMemory тоже для прикола?
Не, это если нужно писАть по байту по нескольким разным адресам, иначе конечно блоком и цикл отсюда выбросить %)

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

Asterix пишет:
MS не гаранирует сохранность eax, edx, ecx
Блин, тормознул, просто ebx,esi или edi

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