Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
[Win32] Возможно ли писать в запущеный файл? 21.04.02 11:39 Число просмотров: 1129
Автор: ih8u <i hate you> Статус: Member
|
Мля, кроме как не через ring0 прямо так @#$ запишешь,
простых способов нету, через rin0 - милое дело! пиши хоть в kernel32.dll
|
|
<programming>
|
[Win32] Возможно ли писать в запущеный файл? 21.04.02 03:50
Автор: Бяша <Biasha> Статус: Member
Отредактировано 21.04.02 03:56 Количество правок: 1
|
Уже много раз поднимались темы типа "как сохранить параметры программы в программе". Вот только заканчивались обсуждения всегда bat файлами или перезапуском процесса.
Всё это кажется некрасиво. Можно ли писать прямо в exe файл (или в загруженную dll)?
Насколько я помню, этот самый, исполняемый файл, используется, как файл подкачки, для страниц с кодом и инициализированными данными. Но только эти страницы помечены как копируемые при записи - когда в них пишешь, файлом подкачки становится стандартный файл подкачки.
Я ничего не перепутал?
Если нет: как можно снять копирование при записи и т.д., так, чтоб все изменения попадали прямо в исполняемый файл на диске?
Я попробовал, но что-то у меня сходу не вышло, да ещё и рихтеровская утилита для просмотра атрибутов страниц виснуть начала после такого...
Может так кто уже делал? Дайте пример?
P.S.
Драйверы ядра и 9х не предлагать :)
P.P.S.
Исключительно спортивный интерес.
|
|
[Win32] писать в свой же файл в win98 и NT 10.05.02 14:15
Автор: vh <Дмитрий> Статус: Member
|
здес описано про самоудаление файла на диске, ну и соответственно как я понял таким же фигом его можно просто модифицировать...
здесь
|
| |
[Win32] писать в свой же файл в NT только 11.05.02 02:22
Автор: Бяша <Biasha> Статус: Member
|
> здес описано про самоудаление файла на диске, ну и
> соответственно как я понял таким же фигом его можно просто
> модифицировать...
Самоудаление происходит после завершения процесса.
А мне хочется модифицировать себя не завершаясь.
|
|
[Win32] From "Undocumented Windows NT." 08.05.02 23:22
Автор: + <Mikhail> Статус: Elderman
|
Copy-on-Write
“Eureka!” you might say, “I violated Windows NT security. I wrote to a shared page used by other processes also.” No! You did not do that. You changed only your copy of the DLL code. The DLL code page was being shared while you did not write to the page. The moment you wrote on that page, a separate copy of it was made, and the writes went to this copy. All other processes are safely using the original copy of the page. This is how Windows NT protects processes from each other while consuming as few resources as possible.
The VirtualProtect() function does not mark the page as read-write–it keeps the page as read-only. Nevertheless, to distinguish this page from normal read-only pages, it is marked for copy-on-write. Windows NT uses one of the available PTE bits for doing this. When this page is written onto, because it is a read-only page, the processor raises a page fault exception. The page fault handler makes a copy of the page and modifies the page table of the faulting process accordingly. The new copy is marked as read-write so that the process can write to it.
Windows NT itself uses the copy-on-write mechanism for various purposes. The DLL data pages are shared with the copy-on-write mark. Hence, whenever a process writes to a data page, it gets a personal copy of it. Other processes keep sharing the original copy, thus maximizing the sharing and improving memory usage.
A DLL may be loaded in memory at different linear address for different processes. The memory references–for example, address for call instruction, address for a memory to register move instruction, and so on–in the DLL need to be adjusted (patched) depending on the linear address where the DLL gets loaded. This process is called as relocating the DLL. Obviously, relocation has to be done separately for each process. While relocating, Windows NT marks the DLL code pages as copy-on-write temporarily. Thus, only the pages requiring page relocation are copied per process. Other pages that do not have memory references in them are shared by all processes.
Author: Prasad Dabak
Milind Borate
Sandeep Phadke
Published: October 1999
|
| |
[Win32] А может можно закрыть себя? 09.05.02 00:14
Автор: Бяша <Biasha> Статус: Member
|
И всё то у тебя на английском.
Нет чтоб нормальным понятным (а не транслитом!) языком.
Да я это уже понял:
Нужно различать защиту страниц, используемую ядром, и защиту страниц, которую NT предоставляет пользовательским процессам.
При загрузке модуля как PAGE_*COPY метиться именно внутренняя страница (и это, кстати, аппаратно поддерживается).
Жаль. Хотя можно было и сразу догадаться, что ничего не выйдет - иначе это был бы обход атрибутов открытия файла.
Но не будем сдаваться. Всё же хочется писать в себя. :)
Может кто знает, как получить дескриптор файла, из которого загружен модуль?
|
|
[Win32] Возможно ли писать в запущеный файл? 21.04.02 11:39
Автор: ih8u <i hate you> Статус: Member
|
Мля, кроме как не через ring0 прямо так @#$ запишешь,
простых способов нету, через rin0 - милое дело! пиши хоть в kernel32.dll
|
| |
[Win32] см. P.S. ёлы-палы 21.04.02 16:21
Автор: Бяша <Biasha> Статус: Member
Отредактировано 21.04.02 16:43 Количество правок: 1
|
> Мля, кроме как не через ring0 прямо так @#$ запишешь,
Что мешает?
>простых способов нету,
Мне любой сойдёт
> через rin0 - милое дело! пиши хоть в kernel32.dll
См. sbj :)
А мне не нужно в kernel32.dll - мне нужно в свой файл.
|
| |
Простой пример: ReGet качает музыку, и одновременно прослушиваешь ее WinAmp-ом, но запущенную прогу писать нельзя. Наврядли.. 21.04.02 13:33
Автор: CETb2 Статус: Незарегистрированный пользователь
|
|
|
| | |
Простой пример: ReGet качает музыку, и одновременно прослушиваешь ее WinAmp-ом, но запущенную прогу писать нельзя. Наврядли.. 22.04.02 00:37
Автор: ih8u <i hate you> Статус: Member
|
Ну да, регет пишет, винамп читает,
Одно дело читать, а другое дело писать в запущенный файл
|
| | |
[GOD] Об'єктивный идеализм, следующий 21.04.02 16:34
Автор: Бяша <Biasha> Статус: Member
Отредактировано 21.04.02 16:37 Количество правок: 1
|
Да, наверное, ведь иначе твоя модель мира будет разрушена.
Не стоит и пытаться - это невозможно.
Лучше слушать винампом файл открытый с FILE_SHARE_READ, не задумываясь о том почему же это, собственно, возможно.
Главное чтоб у тебя не было никаких противоречий:
1. в запущенный файл писать нельзя,
2. ReGet'овские файлы слушать можно, благодаря чудесной его и винампа силе,
это кажется правдой, и не пытайтесь меня переубедить, мне хорошо.
А все, кто задумываются над таким вопросом - зря теряют время. Бог уже всё решил.
|
| | | |
[Win32] ;)) - Filosofskii humor = good 26.04.02 16:01
Автор: eugeneme Статус: Незарегистрированный пользователь
|
...
> А все, кто задумываются над таким вопросом - зря теряют
> время. Бог уже всё решил.
Ne God a Bill Gates (raznitsa, pravda, tol'ko v tom chto God sebya Bill'om ne schitaet ;) no vse je)
P.S. U Win takaya glupaya architectura.
Windows source code:
'-----Cut Here-------
'
Sub SetWindowsArchitectureType()
'Uncomment next line to set windows architecture to "smart"
'WindowsArchitectureType="smart"
WindowsArchitectureType="stupid"
End Sub
Call SetWindowsArchitectureType
---
|
| | | | |
[Win32] Загадка 06.05.02 22:34
Автор: Sidor Статус: Незарегистрированный пользователь
|
Всё как бы верно: физическая память для исполняемого модуля
передаётся не из страничного файла, а из бинарника на диске и
для страниц, подлежащих модификации програмой, устанавливается
атрибут PAGE_WRITECOPY.
Но в примере ниже страница, в которой
находиться буфер buf имеет атрибут PAGE_READWRITE до записи
в неё!
Значит какое-то несоотвествие! Может кто-то обьяснить этот парадокс?
Да и если изменить атрибуты страниц кода и записать туды,
то казалось бы --- должны быть изменения на диске в файле
(бинарник -- файл проецируемый в память), но НИЧЕГО!
.data
mes db 'Hello!',0
buf db 6 dup(1) ;буфер для записи
prev_protect dd 0 ; здесь будет предыдущий атрибут страницы
.code
start:
lea esi,mes
lea edi,buf
call VirtualProtect,edi,6,PAGE_READWRITE, offset prev_protect
test eax,eax
jz error
;удачно изменили атрибуты страниц(ы) -- пишем в память!
mov ecx,6
rep movsb
jmp exit
error:
call GetLastError
exit:
call ExitProcess,0
end start
|
| | | | | |
[Win32] Я начинаю понимать 07.05.02 02:13
Автор: Бяша <Biasha> Статус: Member
|
> Всё как бы верно: физическая память для исполняемого модуля
> передаётся не из страничного файла, а из бинарника на
> диске и
> для страниц, подлежащих модификации програмой,
> устанавливается
> атрибут PAGE_WRITECOPY.
> Но в примере ниже страница, в которой
> находиться буфер buf имеет атрибут PAGE_READWRITE до записи
> в неё!
> Значит какое-то несоотвествие! Может кто-то обьяснить этот
> парадокс?
Существует защита выделенных в памяти страниц (Protect - Specifies the access protection of the pages in the region) и защита зарезервированных страниц (AllocationProtect - Specifies the access protection given when the region was initially allocated).
Так вот, загрузчик, резервируя память, в качестве AllocationProtect для региона, начиная с 0x00400000 указывает PAGE_EXECUTE_WRITECOPY.
А при выделении памяти указывает PAGE_READWRITE для данных, которые мы потом хотим модифицировать.
Причём:
VirtualAllocEx, который вызываем мы, простые смертные, не допускает никаких PAGE_*COPY, однако загрузчик это может.
И ещё "The VirtualProtectEx function changes the access protection on a region of committed pages" то есть мы не можем менять AllocationProtect с помощью этой функции.
Вот только никак понять не могу: в чём же разница между PAGE_EXECUTE_WRITECOPY указанным при резервировании и PAGE_EXECUTE_WRITECOPY у выделенной страницы.
Может кто расскажет?
|
| | | | | | |
[Win32]Вот что странно.. 09.05.02 18:38
Автор: Sidor Статус: Незарегистрированный пользователь
|
> Вот только никак понять не могу: в чём же разница между
> PAGE_EXECUTE_WRITECOPY указанным при резервировании и
> PAGE_EXECUTE_WRITECOPY у выделенной страницы.
> Может кто расскажет?
Ну как мне кажется, регионы резервируются с какими-то атрибутами
лишь затем, шоб потом при выделении физической памяти случаём не
забыть и не перепутать атрибуты. К примеру, ежели зарезервирован
регион с PAGE_READONLY, то с PAGE_READWRITE ему физ. память не передашь!
Вот что странно:
Нафиг резервировать регион с PAGE_EXECUTE_WRITECOPY, дабы затем выделить физ.память с PAGE_READWRITE !? Где тут срабатывает идея,
мол все процессы будут юзать одни страницы кода/данных пока в них
чего не запишут???
Всё таки что-то MicroSoft скрывает! А может это всё бабушкины сказки
и каждому процессу предоставляется своя копия данных :((((((((
|
| | | | | | | |
[Win32]Вот что странно.. 09.05.02 21:23
Автор: + <Mikhail> Статус: Elderman
|
> > Вот только никак понять не могу: в чём же разница
> между
> > PAGE_EXECUTE_WRITECOPY указанным при резервировании и
> > PAGE_EXECUTE_WRITECOPY у выделенной страницы.
> > Может кто расскажет?
> Ну как мне кажется, регионы резервируются с какими-то
> атрибутами
> лишь затем, шоб потом при выделении физической памяти
> случаём не
> забыть и не перепутать атрибуты. К примеру, ежели
> зарезервирован
> регион с PAGE_READONLY, то с PAGE_READWRITE ему физ. память
> не передашь!
> Вот что странно:
> Нафиг резервировать регион с PAGE_EXECUTE_WRITECOPY, дабы
> затем выделить физ.память с PAGE_READWRITE !? Где тут
> срабатывает идея,
> мол все процессы будут юзать одни страницы кода/данных пока
> в них
> чего не запишут???
> Всё таки что-то MicroSoft скрывает! А может это всё
> бабушкины сказки
> и каждому процессу предоставляется своя копия данных
> :((((((((
Kto skazal chto kazdomu processu predostavlietsia svoia copia?
chitai moi post vyshe. Tam chernym po belomu napisano chto zagruzhennye modules ispolzuut odnu i tuzhe copy etogo module, no esli kto to pytaetsia zapisat` v etu oblast` pamiati sozdaetsia copy togo module dlia etogo processa (stavitsia attribute PAGE_EXECUTE_WRITECOPY. "write on copy" pri popytke zapisat` v etu pamiat sozdaetsia kopia)
|
| | | | | | | | |
[Win32]Вот что странно.. 09.05.02 22:43
Автор: Sidor Статус: Незарегистрированный пользователь
|
> > мол все процессы будут юзать одни страницы кода/данных
> пока
> > в них
> > чего не запишут???
> > Всё таки что-то MicroSoft скрывает! А может это всё
> > бабушкины сказки
> > и каждому процессу предоставляется своя копия данных
> > :((((((((
>
> Kto skazal chto kazdomu processu predostavlietsia svoia
> copia?
> chitai moi post vyshe. Tam chernym po belomu napisano chto
> zagruzhennye modules ispolzuut odnu i tuzhe copy etogo
> module, no esli kto to pytaetsia zapisat` v etu oblast`
> pamiati sozdaetsia copy togo module dlia etogo processa
> (stavitsia attribute PAGE_EXECUTE_WRITECOPY. "write on
> copy" pri popytke zapisat` v etu pamiat sozdaetsia kopia)
Ты чо читаешь тексты снизу вверх? И не до конца?
Будь внимательней! Нефиг захламлять форум таким вздором!
Последнее предложение было сказано потому, что никто пока
не даёт правильных обьяснений на стоящую проблему!
|
| | | | | | | | | |
[Win32] Ты хоть бы всю нитку прочитал сначала 10.05.02 05:50
Автор: Бяша <Biasha> Статус: Member
|
Например. http://www.bugtraq.ru/cgi-bin/forum.mcgi?type=sb&b=2&m=47093
Поясняю ещё и я:
Есть аппаратная защита страниц, которая используется ядром винды. Эта защита используется для копирования при записи страниц образа. Это и есть AllocationProtect. И поменять эту защиту мы никак не можем.
А есть защита страниц пользовательского процесса. Она всем кроме как процессу пофигу. Это и есть наш Protect, который мы бодро меняем VirtualProtect’ом.
Так что забудь эту идею.
Лучше скажите мне кто-то, как получить HANDLE своего образа. Или его не существует для пользовательского процесса?
|
| | | | | | | | | | |
[Win32] Ты хоть бы всю нитку прочитал сначала 10.05.02 21:04
Автор: + <Mikhail> Статус: Elderman
|
> Например.
> http://www.bugtraq.ru/cgi-bin/forum.mcgi?type=sb&b=2&m=4709
> 3
>
> Поясняю ещё и я:
>
> Есть аппаратная защита страниц, которая используется ядром
> винды. Эта защита используется для копирования при записи
> страниц образа. Это и есть AllocationProtect. И поменять
> эту защиту мы никак не можем.
>
> А есть защита страниц пользовательского процесса. Она всем
> кроме как процессу пофигу. Это и есть наш Protect, который
> мы бодро меняем VirtualProtect’ом.
>
> Так что забудь эту идею.
>
> Лучше скажите мне кто-то, как получить HANDLE своего
> образа. Или его не существует для пользовательского
> процесса?
1.GetCurrentProcess()- psevdo handle good dlia sebia.
2.DuplicateHandle( ) - posylaesh psevdo handle tuda i poluchaesh real handle.
3.OpenProcess()- real handle good dlia vseh.
|
| | | | | | | | | | | |
[Win32] Издеваешься? 11.05.02 02:01
Автор: Бяша <Biasha> Статус: Member
|
> > Лучше скажите мне кто-то, как получить HANDLE своего
> > образа. Или его не существует для пользовательского
> > процесса?
Я имел в виду HANDLE файла своего образа
Ну нафига мне дескриптор процесса? :)
> 1.GetCurrentProcess()- psevdo handle
> good dlia sebia.
>
> 2.DuplicateHandle( ) - posylaesh psevdo
> handle tuda i poluchaesh real handle.
real handle :) Это чем же он real то?
>
> 3.OpenProcess()- real handle good dlia
> vseh.
К тому же я не понял, а нафига DuplicateHandle - мне то только для себя нужно.
|
| | | | | | | | | |
[Win32]Dlia tupuh eche raz 10.05.02 00:26
Автор: + <Mikhail> Статус: Elderman
|
>
> > > мол все процессы будут юзать одни страницы
> кода/данных
> > пока
> > > в них
> > > чего не запишут???
> > > Всё таки что-то MicroSoft скрывает! А может это
> всё
> > > бабушкины сказки
> > > и каждому процессу предоставляется своя копия
> данных
> > > :((((((((
> >
> > Kto skazal chto kazdomu processu predostavlietsia
> svoia
> > copia?
> > chitai moi post vyshe. Tam chernym po belomu napisano
> chto
> > zagruzhennye modules ispolzuut odnu i tuzhe copy etogo
> > module, no esli kto to pytaetsia zapisat` v etu
> oblast`
> > pamiati sozdaetsia copy togo module dlia etogo
> processa
> > (stavitsia attribute PAGE_EXECUTE_WRITECOPY. "write on
> > copy" pri popytke zapisat` v etu pamiat sozdaetsia
> kopia)
>
> Ты чо читаешь тексты снизу вверх? И не до конца?
> Будь внимательней! Нефиг захламлять форум таким вздором!
> Последнее предложение было сказано потому, что никто пока
> не даёт правильных обьяснений на стоящую проблему!
Copy-on-Write
“Eureka!” you might say, “I violated Windows NT security. I wrote to a shared page used by other processes also.” No! You did not do that. You changed only your copy of the DLL code. The DLL code page was being shared while you did not write to the page. The moment you wrote on that page, a separate copy of it was made, and the writes went to this copy. All other processes are safely using the original copy of the page. This is how Windows NT protects processes from each other while consuming as few resources as possible.
The VirtualProtect() function does not mark the page as read-write–it keeps the page as read-only. Nevertheless, to distinguish this page from normal read-only pages, it is marked for copy-on-write. Windows NT uses one of the available PTE bits for doing this. When this page is written onto, because it is a read-only page, the processor raises a page fault exception. The page fault handler makes a copy of the page and modifies the page table of the faulting process accordingly. The new copy is marked as read-write so that the process can write to it.
Windows NT itself uses the copy-on-write mechanism for various purposes. The DLL data pages are shared with the copy-on-write mark. Hence, whenever a process writes to a data page, it gets a personal copy of it. Other processes keep sharing the original copy, thus maximizing the sharing and improving memory usage.
A DLL may be loaded in memory at different linear address for different processes. The memory references–for example, address for call instruction, address for a memory to register move instruction, and so on–in the DLL need to be adjusted (patched) depending on the linear address where the DLL gets loaded. This process is called as relocating the DLL. Obviously, relocation has to be done separately for each process. While relocating, Windows NT marks the DLL code pages as copy-on-write temporarily. Thus, only the pages requiring page relocation are copied per process. Other pages that do not have memory references in them are shared by all processes.
Author: Prasad Dabak
Milind Borate
Sandeep Phadke
Published: October 1999
|
|
|
подробно о проекте
Анализ криптографических сетевых...
