В правильно написанной многопользовательской операционке gdt не то что на запись, но и на чтение не должна быть доступна (за исключением штатной загрузки селекторов аппаратным образом). Если нет дырок в софте, уже работающем под r0, то шансов нет.
// ну и далее убираем за собой
memset(pGDTDescriptor, 0, 8
return true;
}
// если не нашли, переходим к след.
pGDTDescriptor++;
}
// нет свободных!
return false;
}
Это под мд98. А в 2000 есть аналогичный способ прыгнуть в r0?14.02.02 14:31 Автор: z0 <z0> Статус: Member
вот тут надо быть очень осторожным
я даже так делал - искал несколько дыр в GDT и делал свои дескрипторы (вернее алиасы) для CS и SS с PL=0
> _asm Call FWORD PTR [CallgateAddr]
не забудь что для SS PL должен совпадать с PL CS
здесь есть такие решения:
1) все пройти на IF=0
2) дать свой SS но помнить что при аппаратном прерывании на PL=0 SS не перегружается автоматически
3) работать с SS_0 текущего TSS (для виндов он единственный вроде)
с моей практической точки зрения 2 и 3 варианты дают редкие/странные глюки под виндой
> // нет свободных!
а вот эту интереснейшая ситуация - сам видел многократно - разные версии чикаги дают разный начальный и по-разному меняют размер GDT более того возможны ситуации когда в системе не одна GDT и кстати ситуация теоретически разрешима бекапом каких-то позиций в GDT (например СВОИХ!!! CS/SS)
по-поводу NT/2000 - этот номер не пройдет по защите страниц и вообще никакой (проверено) такой номер не пройдет кроме очень билд-зависимых срывов стека (например при вызове int 2e)
я делал так: патчил NTLDR
но тебе же надо в прогу
нужно сотворить нечто подобное
прямо из 32разр. кода (не создавая и не загружая 16 dll)
les di, lpCallStruct ; Real mode call structure
int 31h ; Call DPMI
Вопрос: пойдет ли оттуда int и как сделать так, чтобы lpCallStruct загрузился в база:смещение виде?
можно, конечно базу грузить прямо в ES, а смещение в di, но как их получить из 32-разр. адреса?
[Win32] Экстренный вопрос:15.02.02 10:39 Автор: Chingachguk <Chingachguk> Статус: Member Отредактировано 15.02.02 10:51 Количество правок: 2
> нужно сотворить нечто подобное > прямо из 32разр. кода (не создавая и не загружая 16 dll) > les di, lpCallStruct ; Real mode call structure > int 31h ; Call DPMI > Вопрос: пойдет ли оттуда int и как сделать так, чтобы > lpCallStruct загрузился в база:смещение виде? > можно, конечно базу грузить прямо в ES, а смещение в di, но > как их получить из 32-разр. адреса?
У сервиса int 31h есть ф-ция - получить линейный адрес по селектору и наоборот(назад немного сложнее).
В досе CallStruc я в селектор кидал то, что DPMI засовывало в DS при переключении(lim=64K и т.д.), offset = обычный оффсет:
mov bl,16h ; Call int 16h
mov byte ptr CallDPMIS.RegEAX+1,0 ; reg ah=0h
lahf
and ah,0feh
mov bh,ah
mov cx,0
mov di,offset CallDPMIS
and edi,0ffffh
push ds
pop es
mov ax,0300h
int 31h
jnc @CallV86
Я думаю, из 32 надо кидать в DI обычный оффсет, селектор и так в порядке, DPMI(а точнее, винда) сама разберется. Ж)
ЗЫ А исчо есть апи такая - вызвать прерывание реального режима, так на дискетку "царапины" для защиты записывают. Я про int 25h/26h на 99.666% уверен, что можно.
[Win32] Так, уже теплее, но:15.02.02 10:48 Автор: Zef <Alloo Zef> Статус: Elderman
> А как int 31h из 32-разрядной проги вызвать? При любой > попытке я получаю "синяк" или вылетаю в WinIce (если он > загружен)
это смотря какая прога
если win32 - не выйдет
если dos32 (екстендеры всякие включая самодельные) - сколько угодно и из-под любой винды (у win3.x были некоторые (небольшие) проблемы с DPMI)
сделай две проги и организуй обмен
Я хотел сказать, что есть такая бяка - VWIN32_DIOC_DOS_INT25/26 в DeviceIoControl, но вот проблема: для ее работы нужен хендёл устройства, но в 95 его можно получить тока для файла, а что делать, если нужен диск?
[Win32] Все у Гейтса через Ж:18.02.02 05:38 Автор: Zef <Alloo Zef> Статус: Elderman
Короче, нужно читать на прямую с сидюка под МД95/98, а еще лучше сделать аналог НТёвой IOCTL_CDROM_RAW_READ, чтобы все сидело в одном .ехе-файле и ни каких драйверов или 16бит дллок не писать!
[Win32] Опять не то! Помогите, загибаюсь!!!18.02.02 17:11 Автор: z0 <z0> Статус: Member
> Короче, нужно читать на прямую с сидюка под МД95/98, а еще > лучше сделать аналог НТёвой IOCTL_CDROM_RAW_READ, чтобы все > сидело в одном .ехе-файле и ни каких драйверов или 16бит > дллок не писать!
ну и пиши
чем тебе помочь-то конкретно?
может тебе доку по MSCDEX кинуть?
[Win32] Доку бы хорошо, а еще: кто из корифеев знает?19.02.02 04:12 Автор: Zef <Alloo Zef> Статус: Elderman Отредактировано 19.02.02 04:14 Количество правок: 1
а то вчера весь Инет прогуглил, а вразумительной доки по Int 2F не нашел. А вообще проблема в том, что все известные мне способы обращения к CD в 95-й кривы: либо пиши 16бит дллку, к-рая будет работать через Int 2F, а к ней еще один файл - 32/16 thunk и через него из 32бит - проги обращайся (стандартный путь, предлагаемый МД), либо делай "незаконный" прыжок в Ring0 и оттуда...
Но но для прыжка может не найтись свободного дескриптора (см выше).
А вот, как чтобы одним файлом, и всегда срабатывало?
Есть правда мысль: скопировать Таблицу Дескрипторов на новое место, затем добавить к ней Дескриптор Шлюза, а потом подменить указатель на системную таблицу своим. Только как? И сработает ли? Кто из корифеев подскажет?
[Win32] Так, уже теплее, но:15.02.02 10:52 Автор: Chingachguk <Chingachguk> Статус: Member Отредактировано 15.02.02 10:54 Количество правок: 1
> А как int 31h из 32-разрядной проги вызвать? При любой > попытке я получаю "синяк" или вылетаю в WinIce (если он > загружен)
ЗЫ А исчо есть апи такая - вызвать прерывание реального режима, так на дискетку "царапины" для защиты записывают. Я про int 25h/26h на 99.666%
уверен. Так парень один делал в конторе по защите данных. Из си плюса-плюса.
На то и 2000, чтобы не прыгали в r014.02.02 10:51 Автор: ukv Статус: Незарегистрированный пользователь
В правильно написанной многопользовательской операционке gdt не то что на запись, но и на чтение не должна быть доступна (за исключением штатной загрузки селекторов аппаратным образом). Если нет дырок в софте, уже работающем под r0, то шансов нет.
На то и 2000, чтобы не прыгали в r014.02.02 16:55 Автор: Sandy <Alexander Stepanov> Статус: Elderman Отредактировано 14.02.02 16:56 Количество правок: 1
> В правильно написанной многопользовательской операционке > gdt не то что на запись, но и на чтение не должна быть > доступна (за исключением штатной загрузки селекторов > аппаратным образом). Если нет дырок в софте, уже работающем > под r0, то шансов нет.
Не совсем понятно в части "gdt не то что на запись, но и на чтение не должна быть доступна". Недоступна кому? Если пользовательским аппликациям - то это так и есть. А если самому ядру - каким образом готовить дескрипторы для переключения контекста при передаче кванта процессорного времени создаваемому процессу? Здесь как ни крути, а планировщик ДОЛЖЕН иметь возможность и читать и писать в GDT.
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
