» Assembler

Ха. Так бы сразу и сказали.
1. В современном миру вообще то это невостребовано. Только драйверы напрямую работаю с железом, и том 2/3 - через слои абстракции а не напрямую.
2. Ищите проекты разработки "собственных ос" - кое что есть в виде исходников на асме + есть старые книги о том как работать с оборудованием и ссылки на всякие спецификации.
3. депозит файлы.сом/files/17cqaoat0 - Старая серия книг. Где то в интернетах они есть, но найти наверное будет не просто. 1/3 - посвещена MS-DOS, 1/3 - BIOS, 1/3 - портам ввода-вывода, прерыванием, защитному режиму и прочему. Последние две трети возможно и будут вам интерестны. Но все ити вещи делать надо не из под Windows или Linux, а из MS-DOS - заведите виртуалку и эксперементируйти с 16 разрядным кодом в ней.

ЗЫ. Работать с железом не учили потому что из под винды или линуха такое могут делать только драйвера. Ну или как исключение - ссылка в сообщении akaGM - там драйвер вмешиваеться в работу ОС и разрешает доступ из ring3 к io ports. В итоге это не очень востребовано - вот и не учат.

Честно говоря не знаю зачем вам это нужно. Только если свою ОС писать.

http://rghost.net/5179911 - Перепостил ссылку, а то депозитовскую вруг замених форум на спам_детект

Molniev
Объясните, как пользоваться функициями CreateFile, WriteFile, CloseHandle? Из вашего пояснения ничего не понятно.

blaro, единственно верное объяснение приведено по ссылкам. Но повторюсь:
С файлами работали? Сначала открываем файл вызовом функции CreateFile, потом пишем туда данные
WriteFile, потом закрываем CloseHandle. Что где и какие параметры - по ссылкам.
Для работы с принтером, делаем всё то же самое, только вместо имени файла CreateFile первым параметром передаём "имя устройства" - вида "\\.\COM1" - без кавычек. Или для ltp - "\\.\LTP". При этом параметр dwCreationDisposition должен иметь значение OPEN_EXISTING, dwShareMode должен быть установлен в ноль.

Ну ведь все же написано: CreateFile

Цитата:

Communications Resources

The CreateFile function can create a handle to a communications resource, such as the serial port COM1. For communications resources, the dwCreationDisposition parameter must be OPEN_EXISTING, the dwShareMode parameter must be zero (exclusive access), and the hTemplateFile parameter must be NULL. Read, write, or read/write access can be specified, and the handle can be opened for overlapped I/O.

To specify a COM port number greater than 9, use the following syntax: "\\.\COM10". This syntax works for all port numbers and hardware that allows COM port numbers to be specified.

For more information about communications, see Communications.

И то что вы будете записывать в "файл" с таким именем будет печататься. Ну а как пользоваться CreateFile & co для работы с файлами написано у Юрова + исходников в интернетах тьма. Нужно просто поменять в любом из таких исходников путь к файлу, dwCreationDisposition с CREATE_ALWAYS или OPEN_ALWAYS или что там будет и dwShareMode в ноль, если будет FILE_SHARE_READ или WRITE или DELETE. - три места подправить.

Molniev
Это понятно. Я так и сделал. Только все равно не работает. Я писал так:

Код:
call CreateFile(\\.\LPT1,GENERIC_WRITE,0,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL)

blaro, такое знание асма ввергло меня в уныние...
Это неправильный синтаксис. Есть два варианта вызова функций:
1. Через call. В этом случае, данные помещаються в стек и отдаёться комманда call [имя функции].
2. Через макрос invoke. Почти так как во втором вашем варианте invoke [имя функции], [параметр1], [параметр2]...

Чтоб не быть голословным:

Код:
include \masm32\include\masm32rt.inc
.data
;ltpname db "\\.\LPT1"
ltpname db "C:\test.txt"
n dd 0
hFile dd 0
.code
start:
push 0
push 0
;push OPEN_EXISTING
push CREATE_ALWAYS
push 0
push 0
push GENERIC_WRITE
push offset ltpname
call CreateFileA
mov hFile, eax
push 0
push offset n
push 5
push offset ltpname
push eax
call WriteFile
push 0
call ExitProcess
end start

Мужики,помогите пожалуйста,нужно написать программу,которая удаляет файлы любые,но в винде,причем в XP3

Любые в винде - невозможно.

Qraizer
Смотрим сообщение выше вашего о call & invoke и юзаем функцию DeleteFile. А в идеале открываем на странице где то 250
Цитата:

(Assembler: Практикум, В.И. Юров)

Там расписано.

Это по поводу удаления файла. Раскрывая предыдущий коментарий: по поводу удаления любого файла - если прав доступа к файлу нет, то невозможно. Если открыт монопольно другим приложением - можно, но сложно - вашего уровня знаний, судя по вопросу на это не хватит. Если файл на CD-ROM - ну не выйдет удалить - только чтение же. Поэтому любой нельзя. Можно удалить только то что система разрешит.

Немного не так выразился.Нужно стереть файл так чтобы безвозвратно.Пусть это будет документ или картинка.

Maxv90
может тебе тулзов достаточно? коих -- тьма...

Нет,мне нужен чистый код на ассемблере.Я написал прогу,которая просто уничтожает данные,но их можно вернуть,а это не вариант.Выручайте,если сможете..

Maxv90
перезаписывай файл случайными данными несколько раз...

Цитата:

Если открыт монопольно другим приложением - можно, но сложно - вашего уровня знаний, судя по вопросу на это не хватит.

Хватит. Даже чтобы удалить pagefile.sys. Только это будет последнее, что увидит винда в своей жизни. Это явно не та степень погружения в глубины системы, которая нужна Maxv90. Да и Ассемблер тут не причём.
Maxv90, вот так бы сразу. Зачем задавать не тот вопрос, на который хочешь получить ответ?
Вообще, перетирая данные файла, ты безвозратно трёшь их только в текущей версии. Если запущена Служба теневого копирования тома, то это тоже может не помочь, всегда можно восстановить предыдущие версии.

Qraizer,
Цитата:

Хватит. Даже чтобы удалить pagefile.sys.

Каким образом? Разве что отложено, но не системные.
Это во времена Win98 всю папку Windows можно было отправить к корзину. А нынче винда стала умней - и доступ вроде режет?

Ну, раз интересно... непосредственно в MFT. Винда будет жить, пока записи о файле подкачки не будут выброшены из дискового кеша, а менеджер ВП не будет реинициализирован, например, хибернетом и выходом из него. Спасти сможет может быть установка новых параметров подкачки пользователем, но не пробовал, потому не уверен.
Molniev, мой ответ Maxv90-у был скорее демонстрирующим абсурдность такой формулировки вопроса. Обычно, если не ответить "математически точно и бесполезно" (© Холмз из анекдота), начинается флейм из кучи вариантов ответа, потому что никто не понял, что же собственно спрашивалось, а вопрошающий тихо уходит в панику, т.к. не может в этих ответах разобраться. Впрочем, тут рассказано гораздо лучше. Тут вон тоже вопрос другим оказался.

для таких случаев я и пихнул в шапку руководство для "вопросозадавателей",
только кто ж его эРТэФеМит...

Qraizer, не-а, винда доступ режет - с висты на системных томах такие фокусы не проходят (доступа туды нет). Варианты через IOCTRL'ы, scsi комманды, минипорт, api для дефрагментации и прочая муть тоже не катит. Собственно недавно близкая тема на работе поднималась (только не про удалении, а доступ вообще) - и обшим консилиумом пришли к выводу что нельзя на системных томах, выше хрюшки. Поэтому меня так и зацепил положительный ответ )))

Molniev, подумай, каким святым духом будет работать драйвер файловой системы, если винда его не пустит к его данным на томе?

Qraizer, Вы вообще то в курсе как драйвера соотносятся с томами? Менеджер томов ищет подходящий драйвер фс и монтирует том. Всё. Драйвер фс имеет полный доступ к тому - он смонтирован для него с эксклюзивным доступом. Все остальные жестко обламываються - нужно сначала размонтировать том, а уже потом можно писать туда что-то.

Когда вы открываете том (или дисковое устройство) в режиме записи - система автоматически отмонтирует том (вырубая дравер фс для него). Закрывает - подмонтирует снова. Но системный том отмонтировать нельзя (помойму там сам драйвер фс и будет упираться, а не менеджер томов) - поэтому и запись на него не возможна. Открыть CreateFile или чем-ещё-там с GENERIC_WRITE у вас получиться. А вот WriteFile будет возвращать ошибку и ноль записаных байт.
Это относиться кстати также к томам содержащим файл подкачки, а не только системному. Если у вас виста/семерка - попробуте, вы убедитесь, что я прав.

Molniev, осталось чуть-чуть.
Но - да, лучше не надо. Последствием может быть не только рухнувшая система, но и убитый том. Маловероятно, но возможно.

Цитата:

Molniev, осталось чуть-чуть.

- чего осталось? Я вас не понял.

Фух...
Я не знаю, что там была за тема, в результате которой было решено, что получить доступ на запись к системному тому невозможно, но не догадаться использовать ядерный уровень и драйвер фильтра FS, мягко говоря, непрофессионально. Намекать и дальше, увы, уже нечем, осталось только сказать решение, хоть в открытом доступе этого делать не хотелось - болваны руками всё пощупать, несмотря на "не влезай, убъёт", да ещё и не на виртуалке, всегда найдутся. Надёюсь, если что, все шишки посыпятся на Linux-NTFS Project.

Во первых в том споре фигурировало "без прав администратора" в изначальной версии и "с прикладного уровня" в конечной.
Извиняюсь, что это не уточнил.

Во вторых, на уровне ядра само собой - "кто кого драйверистей". Нет никакой сложности творить из драйвера с системов абсалютно всё, что захочеться.
В третих. Вы что-то странное говорите: причем тут драйвер фильтр фс? Даже если вы сформируете ложный IRP, драйвер самой фс (поверх которого будет этот фильтр) для этого запроса все равно произведёт все проверки, что и для аналогичного с прикладного уровня. Для ...непосредственно в MFT..., о чем вы говорили сымым простым способом будет скомуниздить хенд тома у драфвера фс (нелегально), либо фильтр поверх дискового устройства (который этот хенд получит при срабатывании).

Molniev, у нас разговор ради разговора. Это называется флеймом. Давай либо переползать во флейм-тему, либо заканчивать.
Доступ уровня прямой записи на том "без прав администратора" не получит никто под любой NT based. Это раз. Так что ваш спор изначально не имел смысла. Для прямой записи тома права админа не нужны, нужен инсталлированный загодя драйвер, к которому есть DeviceIoControl()- или WriteFile()-доступ для не админов, каковой сам же драйвер и может обеспечить. Это два. Да, для его инсталляции нужен админ, этот случай не исключение (путь будет два с половиной). Ложный IRP не надо формировать. Драйвер уровня фильта FS нужен, чтобы внедриться в цепочку и иметь нужные привилегии. Да, я говорил о прямой записи в MFT, а для этого достаточно в нужные моменты дёргать драйвер устройства, а не драйвер файловой системы. А драйверу устройства неинтересно, кто его вызвал и зачем, он оперирует байтиками, портами и адресами, он даже (тут могу ошибаться) в иерархии стоит ниже дискового кэша. Это три. Так что тут всё правильно. Только фильтр FS всё-таки предпочтительнее, ибо они более универсальны, т.к. не зависят от железа, зато зависят от ФС, что как раз и надо - на FAT это делалось бы иначе. Фильтр устройства более геморрен, ибо там разновидностей поболе 2-х будет.

Добавлено:
Насчёт хендла тома... я вроде видел его свечение где-то в интерфейсах WDK FS. Т.е. скоммуниздить его можно и легально. Потом на всякий случай продублировать. Вот только сейчас уже не помню, и найти не могу.

прошу помочь, пишу так:


start proc

local hSCManager:HANDLE
local hService:HANDLE
local acDriverPath[MAX_PATH]:CHAR

invoke OpenSCManager, NULL, NULL, SC_MANAGER_CREATE_SERVICE
.if eax != NULL
mov hSCManager, eax

push eax
invoke GetFullPathName, $CTA0("PS2Versuch1.sys"), sizeof acDriverPath, addr acDriverPath, esp
pop eax

invoke CreateService, hSCManager, $CTA0("PS2Versuch1.sys"), $CTA0("Nice Melody Beeper"), \
SERVICE_START + DELETE, SERVICE_KERNEL_DRIVER, SERVICE_DEMAND_START, \
SERVICE_ERROR_IGNORE, addr acDriverPath, NULL, NULL, NULL, NULL, NULL
.if eax != NULL
mov hService, eax
invoke StartService, hService, 0, NULL
invoke DeleteService, hService
invoke CloseServiceHandle, hService
.else
invoke MessageBox, NULL, $CTA0("Can't register driver."), NULL, MB_ICONSTOP
.endif
invoke CloseServiceHandle, hSCManager
.else
invoke MessageBox, NULL, $CTA0("Can't connect to Service Control Manager."), \
NULL, MB_ICONSTOP
.endif

invoke ExitProcess, 0

start endp

end start


он отвечает: Can't register drive

немогу понять почему?

1. Запущено с правами администратора? Выше xp нужно явно запустить от имени админа.
2. Какой код ошибки возвращает вызов GetLastError ?

Спосибо за быстрый ответ,

да запускаю как админ, иначе выдает:Can't connect to Service Control Manager.
на win 7
GetLastError выдает 0, тоесть в еах = 0.

GetLastError вы вызывали сразу после CreateService?
Заменить в OpenSCManager последний параметр на SC_MANAGER_ALL_ACCESS.
В CreateService: SERVICE_START + DELETE на SERVICE_ALL_ACCESS. SERVICE_DEMAND_START - разве драйвер может быть запущен отложено? замените на SERVICE_SYSTEM_START.

И сделайте вызов MessageBox, выводящий, что вернула GetFullPathName в переменную acDriverPath.

Molniev

Цитата:

SERVICE_DEMAND_START - разве драйвер может быть запущен отложено?

Да в принципе может, почему нет?

Abs62
Да, вы правы. Я перепутал запуск драйверов по требованию и отложеный (delay или как там его) запуск служб (драйверами не являющихся).
arrhangel SERVICE_DEMAND_START, заменять не нужно. Допустимое значение.
Ошибка скорей всего в отсутствии привелегии SC_MANAGER_CREATE_SERVICE - привелегии запуска и удаления вы указали, а привелегию установки нет. Так что пробуйте SC_MANAGER_ALL_ACCESS. И меня терзают сомнения, что вы правильно вызвали GetLastError (тобишь следующим api вызовом после CreateService, если вы это сделали после MessageBox то он и сбросил код ошибки в ноль).