KeInsertQueueApc как защитить свой процесс ?

Тема в разделе "WASM.WIN32", создана пользователем lamer2k, 6 фев 2010.

  1. lamer2k

    lamer2k New Member

    Публикаций:
    0
    Регистрация:
    14 май 2006
    Сообщения:
    88
    Подскажите, как защитить свой процесс от нехороших приложений, которые выделяют память и затем исполняют свой код в моем приложении через АПЦ ? Без использования Ринг-0 кода.
     
  2. TSS

    TSS New Member

    Публикаций:
    0
    Регистрация:
    13 апр 2009
    Сообщения:
    494
    Не создавать alertable потоков
     
  3. blast

    blast New Member

    Публикаций:
    0
    Регистрация:
    8 мар 2008
    Сообщения:
    170
    Скорее перехватить апц диспатчер.
     
  4. Freeman

    Freeman New Member

    Публикаций:
    0
    Регистрация:
    10 фев 2005
    Сообщения:
    1.387
    Адрес:
    Ukraine
    не создавать alertable потоков и перехватить апц диспатчер
     
  5. lamer2k

    lamer2k New Member

    Публикаций:
    0
    Регистрация:
    14 май 2006
    Сообщения:
    88
    А если все-таки нужно создавать alertable в KiUserApcDispatcher можно определить, что это не моя апц пришла ?
     
  6. lamer2k

    lamer2k New Member

    Публикаций:
    0
    Регистрация:
    14 май 2006
    Сообщения:
    88
    Такая вот идея, нигде не могу параметров найти которые передаются в KiUserApcDispatcher, там скорее всего адрес для запуска есть, если посмотреть к чему он принадлежит и если это 'ничейная' память пропускать АПЦ

    Zw/Nt/AllocateVirtualMemory выделяя память не указывают ведь на регион какой нить длл или ехе в АП которые могут ожидать АПЦ
     
  7. Clerk

    Clerk Забанен

    Публикаций:
    0
    Регистрация:
    4 янв 2008
    Сообщения:
    6.689
    Адрес:
    РБ, Могилёв
    Из юзермода мы не можем в полном обьёме манипулировать потоками и памятью(без доступа к памяти ядра). Также и выполнить надёжный перехват диспетчера апк. Стартупапк ведь тоже следует учитывать. Если диспетчер апк захвачен к примеру редиректом на обработчик непосредственно(джамп напр.), то не проблема обойти:
    Если имеется доступ к потоку, то манипуляции контекстом также следует учитывать, апк лишь одна из них. Наиболее устойчивый перехват получится при замене приватной памяти на проекцию секции, спроецированной только для чтения. В этом случае не получится из юзермода изменить код в этой проекции. Редирект на диспетчер исключений требует захвата его начала с помощью этой манипуляции. Например если перенаправить диспетчер апк на диспетчер исключений(напр. записью привилегированной инструкции) это не решит проблему с защитой диспетчера исключений(KiUserExceptionDispatcher()). Мы видим как решение перемап всей кодовой секции нтдлл.
    Второй проблемой является определение родителя апк, тоесть процесса который её поставил в очередь. Для этого следует получать сообщения при добавлении апк в очередь, что проблемно например в случае нэйтивных таймеров.
    Также как и манипуляции контекстом посредством апк, может быть выполнены манипуляции памятью и контекстом непосредственно. Тоесть NtProtectVirtualMemory и захват диспетчера ислючений, либо как частный случай подключение отладочного порта. Защитой от захвата контекста может стать описанное когдато создание потока-ловушки. При создании нового потока получаем слепок(системинфо) и первый поток текущего процесса в этом списке должен использоваться как ловушка. Делается не валидным стек, либо устанавливается хардварный останов в контексте его и тред выполняет бесконечный цикл обращения к ядру(ожидание в случае апк). Тогда при доставке апк в его контексте либо изменение Eip приведёт к неожтданному исключению(стек не созаёт никто отдельно).
    Вобще понятие защиты в юзермоде слишком мутное.