gmz

cpl годится для не пак/не лоадер/упх варианта. типа такой себе dll чит все в одном исходнике. там в 2 чите нету норм импорта, инжектор вроде ~550байт и весь размазан по PE хидере не путай специф. лоадер с ехе/длл пакерами. LZMA пакует лоадер/длл а потом LZSS пакует код распаковки LZMA (такое только в 2 чите) короче эти 2 чита хороший пример тому, сколько ошибок можно допустить при плохой планировке PE лоадера

странное оформление у тебя финдвиндов рулит ну там 2 вида лоадера и 3 вида пакера. это старые версии, так что говнокоду особо не удивляйся lol

ссылка в пм ушла.

пф проверяй (если сможешь распак lol) он в ниже v11 nfsw_hack и в nfsw_carchanger всех билдов

ну сам только что его копирнул из очень старого билда своего хака на онлайн игруху. а что? нельзя так делать? lulz я ведь его не сохранил, так как сделалИ круче где то на ~130%. смысл его хранить... тормоз кода не жалко. его еще можно ускорить где то на 30% если заменить древние инструкции lodsb и scasb

старый "тормоз" код. мы его давно уже переписали, потому не жалко. хех proc SearchBytes uses ebx ebp esi edi,Buffer,BufferSize,Pattern,PatternSize mov esi, [Pattern] mov ecx, [PatternSize] lea edx, [esi+ecx] mov eax, esiL_0x00062CFE: cmp word [eax], 0xFEEF jne L_0x00062D0D sub ecx, 0x01 add eax, 0x02 jmp L_0x00062CFEL_0x00062D0D: add eax, 0x01 cmp eax, edx jne L_0x00062CFE mov edi, [Buffer] mov edx, [BufferSize] mov ebx, ecx mov ebp, esiL_0x00062D1E: lodsb scasb je L_0x00062D31 sub ecx, ebx add edi, ecx mov ecx, ebx mov esi, ebp sub edx, 0x01 jne L_0x00062D1E jmp L_0x00062D56L_0x00062D31: cmp word [esi], 0xFEEF jne L_0x00062D48 add edi, 0x01 sub ecx, 0x01 sub edx, 0x01 je L_0x00062D56 add esi, 0x02 jmp L_0x00062D31L_0x00062D48: sub ecx, 0x01 jne L_0x00062D1E test edx, edx je L_0x00062D56 sub edi, ebx xchg eax, edi jmp L_0x00062D58L_0x00062D56: xor eax, eaxL_0x00062D58:retendp0xEF,0xFE - ?? пример: blaaaah db 0x76,0xEF,0xFE,0x0F,0x2E,0xC3,0x9F,0xF6,0xC4,0x44,0x7B,0xEF,0xFE,0xF3

*facepalm* гуглить надо было. короче пробуй: newMem23:lea esi,[eax+edx+0xDB8]rep movsdmov [eax+0xea4],femov [eax+0xea8],fepush ecxpush edxpush esipush edimov ecx,0x16clea esi,[eax+0xdbc]lea edi,[eax+0x53a8]shr ecx,2and edx,3rep movsdmov ecx,edxrep movsbpop edipop esipop edxpop ecxjmp returnHere23не тестил. может вместо rep -> repe хз как это СЕ видит. будет по 4 байта копировать, если после and edx,3 останется что то - побайтово. если крешанет - добавь перед rep movsd флаг направления cld

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

АХАХА. там read/write/terminate/TopXY процедуры 1в1 как на GTS. уже молчу о стрингах которые прямо в секции кода, лажовом GetKeyState. ты явно не видел GTS кода ни распак кода даного трейнера. нда а я еще старался что бы было макс понятно

в тех хардкорд примерах хук ставят на проц. EndScene в d3d9.dll = код разный = паттерн не найдет.

можно ставить хуки на коде игры. тогда 100% совместимость со всеми виндами и без костылей. они ставят хук на EndScene в той длл. так как d3d9.dll на всех виндах разный бредокод - это создает немеряно проблем. +в тех примерах 99% менюха будет крешить при переходе окно > весь экран тд тп.. +наверно еще и fps жрет постоянными вызовами например ReleaseFont...

хмм он ведь на GTS сделан. тот билдер которые на масм32 ~1998г генерит трейнеры. по крайней мере большая часть говнокода оттуда. protection -> поржал

даа какой делфи, давай на fasm уроки хмм... есть гиганский сборник http://board.flatassembler.net/topic.php?t=13931 или уроки от г. masm32 подходят (почти)

dxwnd неплох. на крайняк запатчить вручную игру

фасм пример. на С логика 1в1 invoke GetAsyncKeyState,VK_INSERTand eax,0x8000shr eax,0xFcmp [KeySwitch1],alje nnnnnnmov [KeySwitch1],alcmp [KeyDown1],ah ;1 когда нужно: зажал - вкл, отпустил - отклjnz @ftest al,alje nnnnnn@@:.if [KeyStatus1] = ahmov [KeyStatus1],al.elsemov [KeyStatus1],ah.endif....патч код...nnnnnn:ps ah всегда 0 ид процесса? мне больше нравится: FindWindowW+GetWindowThreadProcessId+OpenProcess. зачем ид если это длл?

вроде так:if(GetAsyncKeyState(key) & 0x8000 != 0)на фасм оно выглядит так (в еах всегда 0/1) invoke GetAsyncKeyState,VK_INSERT and eax,0x8000 shr eax,0xF +тебе надо сохранять результат и проверять зажата клавиша/не можно хукнуть проц окна игрухи через GetWindowLongW/SetWindowLongW +GWL_WNDPROC +оформить саму проц окна в которой будет твой код, тогда GetAsyncKeyState не нужен ps этот твой Sleep(100); он че прям в потоке игры? Lol

проехали. читай мсдн норм она написана. в даном случае это фейл именно А. а то что внутри А функций видел. получается W даже быстрее работает lulz PUSH 0 PUSH 0 PUSH EDI PUSH DWORD PTR [<&kernel32.LoadLibraryW>] <--- видел на С так делалИ. ЭТО не бред xD PUSH 1000 PUSH 0 PUSH EBX CALL DWORD PTR [<&kernel32.CreateRemoteThread>] *facepalm кст поискал FILE_SHARE_WRITE, оказалось без него у некоторых были странные фейлы CreateFile - так что все правильно задал там.

окее: создай 1000 потоков в пустую проц. потом слип главного потока. посмотри сколько хендлов в диспетчере задач до/после. потом закрой вручную. тогда возьми ollydbg2 и посмотри как она зафейлит загрузку ДЛЛ из папки с японским названием. loaddll.exe юзает А я о ссылке на импорт LoadLibraryW без конструкции "GetProcAddress(hDll, "LoadLibraryA")" такие методы мало кто юзает = будет выделятся. в другой теме (скрытие длл, в флудилке) я накинул как оно выглядит (метод мало чем отличается от ехе варианта), его может ЛЮБОЙ сделать за ~15мин. Кодера вааааашее не понял. код инжекта в DLL_PROCESS_ATTACH остальное НЕВАЖНО. автор темы хотел "специфичный" инжект - я подал еще более спец. вариант. очень сомнительно что он не сможет его реализ.

воу 1 тестани. удивишся - винда не закроет его сама +насколько помню на мсдн индусы писали что надо закрывать самому 2 да ну? создай папку на китайском/японском брось туда длл и пробуй инжект через А 5 имел ввиду CreateRemoteThread,ebx,0,4096,[LoadLibraryW],edi,0,0 типа напрямую из импорта. C ведь так может хех 6 на примере вирьтотал и той кучи пародий на антивири - ефект будет 7 хммм интересно оно создаст файл на шареном диске без? хз о чем ты. не вижу разницы между инжектом exe+dll и dll которая косит под cpl и которая сама себя инжектит будучи загруженой в rundll32.

чел, меня изза тебя скоро тут забанят лучше рискни сделать самоинжекторную длку ака cpl, будешь выделятся среди кучи нубов xD хмм твой код: 1 там после CreateRemoteThread ты забыл WaitForSingleObject а потом закрыть хендл потока и освободить память 2 задай размер стека CreateRemoteThread в 4096 иначе он будет по размеру из хидера ехе игры (иногда там слишком много) 3 параметр 3 юзай W (уникод) иначе некоторые юзера будут очень часто видеть "Я не смог заинжектить твою библиотеку :(" особенно китайские lol 4 длку пиши в темп (как на странном видео выше) а не в С. времена хп прошли 5 зачем делать "GetProcAddress LoadLibrary" если ты можешь добавить ее в импорт инжектора... 6 вероятно долбаные антивири будут ставить дофига детектов на такой инжектор, так что добавь какую-то примитив шифро или в upx его 7 правильно создавай файл когда достанешь из ресурса: CreateFileW,[FilePath],GENERIC_WRITE,FILE_SHARE_WRITE,0,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,0

0 еще скажи что VirtualAlloc может выделить меньше 4096 байта 1 без посторонней "помощи" - очень сомнительно 2 размер из пе хидера SizeOfImage. безопасности? нарушение от прав на запись? мде 3 когда протект на весь модуль - все по другому выглядит, особенно если дофига хуков/нестандартные функции вкл/откл вроде "обмена байтами" ps RtlMoveMemory там потому что crt не используется. на С конечно бред его юзать xD

VirtualProtect работает 4к блоками xD ты собирался сказать что то вроде: lea eax,[Buffer]invoke VirtualProtect,[Address],[PatchSize],PAGE_EXECUTE_READWRITE,eaxinvoke RtlMoveMemory,[Address],[Patch],[PatchSize]lea eax,[Buffer]invoke VirtualProtect,[Address],[PatchSize],[eax],eaxпроверка на фейл VirtualProtect - явно на любителя костылей. кст я забил на такое давно. ставлю протект на весь модуль и работаю с ним как с обычным буфером.

пхах оно совместимо с ASLR? или там адреса от сканера...?

эээ.. ну запустился рундлл, загрузилась в него длка которая потом сама себя загрузила куда то еще.. что тут такого? он ведь системный, длка будет иметь расширение .cpl - 2 клика и инжект готов.. ручная инициализация модуля. типа выравнивание, обработка релоков/импорта и все это своим базонезависимым кодом. можешь примеры поискать. они все правда жуткий говнокод lol

хммм можно еще сделать самоинжекторную длку ака .cpl (инжект через rundll32.exe). уровень сложности минимум, все в 1 файле и скрыть ее через PEB после инжекта. 1 проверка "где длл" например GetModuleHandleW имя ехе/длл какой-то из игры, когда ехе/длл нету - инжект, а когда есть - инициализацию 2 поиск окна/проц/откр. проц. 3 получение пути к длл GetModuleFileNameW+хендл длл 4 VirtualAllocEx/пишем в проц путь к длл/создаем поток на LoadLibraryW 5 ожидаем загрузку, VirtualFreeEx, закрываем хендлы и валим без ExitProcess (rundll32.exe) 6 когда длл подгрузили первым делом код проверяет "где длл". если GetModuleHandleW вернул не 0 - мы в игре 7 переходим на инициализацию, делаем hide PEB, дальше все как обычно.. примерно так. все это должно быть внутри DLL_PROCESS_ATTACH. помоему самый норм метод после pe loader'а