пятница, 19 сентября 2014 г.
Как снизить количество ошибок в программе
Хорошие разработчики всячески стремятся снизить количество ошибок в коде и для этого изобретают различные подходы, которые позволяют эти ошибки найти до того, как продукт попадет к пользователям. Тут можно выделить следующие подходы, некоторые из которых могут отсутствовать в вашем производственном цикле:
Posted by
Kirill V. Lyadvinsky
обновлено:
2016-02-16T19:22:33Z
вторник, 9 сентября 2014 г.
DLL Hijacking
DISCLAIMER: Вся информация предоставлена исключительно в ознакомительных целях. Автор не несет ответственности за любой возможный вред, причиненный материалами данной статьи.
Продолжаем усложнять жизнь злоумышленникам. В этот раз посмотрим как написать приложение, которое не будет подвержено атаке DLL Hijacking.
Продолжаем усложнять жизнь злоумышленникам. В этот раз посмотрим как написать приложение, которое не будет подвержено атаке DLL Hijacking.
Posted by
Kirill V. Lyadvinsky
обновлено:
2015-12-16T11:27:08Z
Labels:
DLL
,
programming
,
security
,
vulnerability
пятница, 5 сентября 2014 г.
Forward exported functions
При создании DLL в Windows необходимо определить точки входа в библиотеку. Чтобы имена были не декорированные (а именно такие стоит использовать, чтобы не зависеть от компоновщика — он от версии к версии делает совершенно разными) часто используется DEF-файл. Минимальный DEF-файл выглядит примерно так:
Документация MSDN однако умалчивает, что тут мы имеем возможность какие-то функции перенаправлять в другие DLL. Для этого надо написать что-то вроде:
Теперь, если вызвать функцию WriteConsole из нашей библиотеки, то на самом деле вызовется функция WriteConsoleA из Kernel32.dll. Такой способ позволяет избежать явных зависимостей от других DLL и создания stub-функций. Указанная DLL будет подгружаться только, если кто-то вызовет конкретную экспортируемую функцию. Такого же результата можно добиться и с помощью директивы pragma:
В прекрасной утилите Dependency Walker можно посмотреть на результат:
Тут видно, что вместо адреса функции WriteConsole указано перенаправление на функцию из Kernel32.dll.
Подобным образом можно обращаться и с экспортируемыми данными. Подробнее о том как это можно сделать можно почитать в статье по ссылке ниже.
Ссылки по теме:
LIBRARY mydll EXPORTS CreateSomethingCool @1
Документация MSDN однако умалчивает, что тут мы имеем возможность какие-то функции перенаправлять в другие DLL. Для этого надо написать что-то вроде:
LIBRARY mydll EXPORTS CreateSomethingCool @1 WriteConsole=Kernel32.WriteConsoleA
Теперь, если вызвать функцию WriteConsole из нашей библиотеки, то на самом деле вызовется функция WriteConsoleA из Kernel32.dll. Такой способ позволяет избежать явных зависимостей от других DLL и создания stub-функций. Указанная DLL будет подгружаться только, если кто-то вызовет конкретную экспортируемую функцию. Такого же результата можно добиться и с помощью директивы pragma:
#pragma comment(linker, "/export:WriteConsole=Kernel32.WriteConsoleA")
В прекрасной утилите Dependency Walker можно посмотреть на результат:
Тут видно, что вместо адреса функции WriteConsole указано перенаправление на функцию из Kernel32.dll.
Подобным образом можно обращаться и с экспортируемыми данными. Подробнее о том как это можно сделать можно почитать в статье по ссылке ниже.
Ссылки по теме:
Posted by
Kirill V. Lyadvinsky
обновлено:
2022-05-12T06:50:32Z
Labels:
Cplusplus
,
DLL
,
export
,
programming
,
VisualStudio
,
Windows
Подписаться на:
Сообщения
(
Atom
)