Обнаружил взлом своей программы копированием файла msimg32.dll , в папку моей программы

1.Написать самому вирус под видом кряка.
2. Вирус пускай спамит мыло ФСБ угрозами о теракте.
3. Разложить на каждом углу.
4. Дожидаться очной ставки с любителями халявного софта.

Цитата UncleBob @ 28.01.14, 08:32

Есть мнение, что в случае защиты от описанного хака любым приведенным выше способом, выйдет другой кряк

Если втянулся в гонку вооружений - это надолго. Возможно, навсегда.
Можно использовать её с целью роста собственного уровня знаний и интеллекта.

Сообщение отредактировано: ЫукпШ - 28.01.14, 09:36

Какая гонка вооружений?
Автор даже не удосужился посмотреть что dll-ка подгружаемая делает.
Она в любом случае в памяти что-то патчит, а раз не запатчили сам файл значит он протом каким-то накрыт.
Короче говоря автор топика не особо представляет что из себя представляет защита и как её поломали, так что dll можно удалять сколько влезет, только будут другие решения типа инлайн патча и всё.

Сообщение отредактировано: cppasm - 28.01.14, 10:02

Цитата reinterpret_alexey @ 28.01.14, 00:41

Решение в твоем случае - указать явно системную директорию, в которой лежит msimg32.dll:
1) GetSystemDirectory(sysdir)
2) SetDllDirectory(sysdir)

или LoadLibrary(PathCombine(sysdir, 'msimg32.dll'))

Цитата reinterpret_alexey @ 28.01.14, 00:41

Сначала загрузите вредоносную DLL, а потом проверьте путь. Это что-то из серии про "- Как проверить, существует ли таблица MySQL? - Очень просто: if (DROP TABLE ... != 0) таблица существовала"

Сам написал и потом своё же зачеркнул
Ты то видимо до загрузки системных библиотек собрался пути их поиска указывать? Гений!

Цитата reinterpret_alexey @ 28.01.14, 00:41

Чет вас не в ту степь понесло

Именно в ту. Ты никакими стандартными способами не сможешь контролировать загрузку системных DLL. Только сделать то что я сказал. Всё же лучше чем ничего, проверил - если что-то не так завершил программу. А если предполагать, что в подмененной DLL каким то образом во время загрузки можно "отключить", предотвратить пост-проверку откуда чего загружено. Ну так от этого защита только - контроль за тем чтобы все системные библиотеки были в порядке. Другого в принципе ничего не придумаешь. И это уже не задача программера.

А что касается своих библитек тут ещё всё проще - делать статику и все дела. Но если очень надо DLL, то подписывать их и подписывать свою программу и далее по тому же принципу что я говорил для системных библиотек.

Добавлено 28.01.14, 11:12
А где цитаты? Что за глюк?

Сообщение отредактировано: neokoder - 28.01.14, 11:20

У тебя один [/quote] лишний

Цитата UncleBob @ 28.01.14, 11:19

У тебя один quote лишний

Точно. Исправил

Добавлено 28.01.14, 11:37

Цитата reinterpret_alexey @ 28.01.14, 00:41

Несистемная же DLL, при неуказании пути к ней - ищется, да, сначала в папке с программой, а только потом в других дирах.

И вот от этого кроме статичной линковки или цифровых подписей программы и DLL-ок(ну или хешей DLL-ок забитых в программу с цифровой подписью) НЕТ других защит.
Хотя, конечно, при желании всё можно сделать. Но от "дурака" защита будет работать точно.

Сообщение отредактировано: neokoder - 28.01.14, 11:37

Цитата

Ты то видимо до загрузки системных библиотек собрался пути их поиска указывать? Гений!

Цитата

Именно в ту. Ты никакими стандартными способами не сможешь контролировать загрузку системных DLL.

О господи. Какие ещё системные DLL, какие ещё цифровые подписи и хеш-суммы? msimg32.dll есть в любой винде,
но она не перечислена в KnownDlls, поэтому системной её не назовешь. Контролировать её загрузку как раз
можно, если положить DLL с таким именем в папку рядом с приложением, которое её загружает без указания пути. Это и есть
DLL hijacking, это и есть то, о чем спрашивает ViH. Нужно пути к DLL правильно указывать:
C:\windows\system32\msimg32.dll
А хеш-суммы считать от системных DLL - это вообще бред: если у атакующего есть возможность перезаписать
системную DLL, он может сделать и всё остальное.

Цитата

Даже в этом случае тоже можно грохнуть чужие dll.
Программа может создать .bat - файл и рестартовать
с его помощью. Этот батник и зачистит папку от плохих модулей
перед запуском.

Гонка вооружений! DLL, заинжектившись на первом этапе в программу перехватит функции
записи в файл и при записи bat-файла добавит туда само-восстановление.
Кстати, .bat-файл для перезаписи вовсе не нужен. Для этого нужно выполнить
ping -n 1 -w 2000 1.2.3.4&&del /q /f program.exe
(ping организует задержку 2000 мсек, за это время программа успевает сделать ExitProcess)

Добавлено 28.01.14, 13:17

Цитата

И вот от этого кроме статичной линковки или цифровых подписей программы и DLL-ок(ну или хешей DLL-ок забитых в программу с цифровой подписью) НЕТ других защит.
Хотя, конечно, при желании всё можно сделать. Но от "дурака" защита будет работать точно.

Защит от чего? От порядка директорий, в которых ищется DLL? Если DLL твоя, то она должна лежать в папке с программой.
Если DLL чужая - ты должен знать к ней путь. Если ты грузишь DLL по пути, по которому её нет и кто-то может положить -
то это уязвимость, надо перестать так делать, а не "защиты" писать.

ViH

Т.к. msimg32.dll системная библиотека но её нет в списке KnownDLLs (почему то!) и поэтому она будет грузиться из папки где запущено ваше приложение, вам чисто для решения вашей проблемы:

Ипользуйте Run-Time Dynamic Linking, там видимо используете одну из 3-х функций из этой библиотеки - AlphaBlend, TransparenrtBlt или GradientFill, так что мароки не особо много.
Но если и в системном каталоге могут подменить DLL, то тут уже конечно могут всё что угодно и защититься сложно. Но один из вариантов я обозначил - забить хеш msimg32.dll в свою программу и проверять его. Если у вас программа будет с цифровой подписью, то для аттакера это уже очень сложная проблема будет, при условии сохранности подписи конечно.

И чтобы не было потенциальных проблем уже с вашими DLL - линкуйтесь статически, без DLL.

Надо же, когда писал своё сообщение ещё твоего не видел Одновременно мы почти...

Цитата reinterpret_alexey @ 28.01.14, 13:15

А хеш-суммы считать от системных DLL - это вообще бред: если у атакующего есть возможность перезаписать
системную DLL, он может сделать и всё остальное.

Что сделать? Если хеш будет в основной программе и она будет с цифровой подписью. Ну так не разбирая варианты подмены системных корневых сертификатов и прочее. Вариант простой, где аттакер это скажем такой обычный товарщ, который может смастерить подменную DLL-ку и объяснить куда файлик надо положить.

Цитата reinterpret_alexey @ 28.01.14, 13:15

Защит от чего? От порядка директорий, в которых ищется DLL?

От подмены DLL приложения.

Цитата reinterpret_alexey @ 28.01.14, 13:15

Если DLL твоя, то она должна лежать в папке с программой.

Ну так кто спорит то. Вот от подмены своих DLL с помощью цифровых подписей или хешей и цифр. подп. и шла речь.

Цитата reinterpret_alexey @ 28.01.14, 13:15

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

Ну то что ты предложил 100% не будет работать для системных билиотек Сам же пишешь если их подменить, то без раницы по какому пути они загружаются.

Сообщение отредактировано: neokoder - 28.01.14, 13:42

neokoder

И опять мимо

В конкретно этом случае нужно просто заменить AlphaBlend на GdiAlphaBlend, а msimg32.lib заменится на gdi32.lib,
соответственно, msimg32.dll заменится на gdi32.dll. А gdi32.dll уже есть в KnownDlls)

Поэтому я и говорю: решением проблемы должно стать понимание DLL hijacking)

Ох, neokoder, помню я был таким же. Влезал в дискуссию только для того, чтобы показать какие-то знания. Даже если
по теме сказать было нечего. Да я и до сих пор такой же остался, че тут) Поэтому я ну ооочень хорошо это в
других замечаю Не будем же этого стыдицо)

Сообщение отредактировано: reinterpret_alexey - 28.01.14, 13:40

Цитата reinterpret_alexey @ 28.01.14, 13:38

В конкретно этом случае нужно просто заменить AlphaBlend на GdiAlphaBlend, а msimg32.lib заменится на gdi32.lib,
соответственно, msimg32.dll заменится на gdi32.dll. А gdi32.dll уже есть в KnownDlls)

И чё дальше то?

Ты вообще хоть одно мало мальское практическое решение автору топика подсказал? Кроме теоретической болтовни от тебя ничего не слышно

Тут дело ширше обстоит, а не "понимание DLL hijacking)"
Чисто практически, вот есть программа у клиента. Если у аттакера есть доступ к компьютеру локально и он более мене квалифицированный - НИЧЁ не спасёт! Если не очень квалифициованный, то о чём я говорил поможет решить проблему.
Вопрос в необходимости таких мер. Поскольку ни одно известное коммерческое приложение так не озадачивается точно, проблемы локальной безопасности целиком лежат на клиенте. Это невозможно универсально предусмотреть.

И вот если такие меры необходимы, то что я предложил как раз добавит дополнительных трудностей(а по-другому мыслить в данной теме нельзя, только это и можно сделать) потенциальному аттакеру, а дальше всё уже зависит от его квалификации.

Ещё разок напомню:
1) Run-Time Dynamic Linking c msimg32.dll
2) Проверка хеша msimg32.dll забитого в подписанное цифровой подписью главное приложение.
3) Никаких своих DLL-ок, только статическая линковка

Сообщение отредактировано: neokoder - 28.01.14, 14:01

Ну чего то автор топика пропал совсем. Молчит... А мы тут разболтались
ViH, ау ты где? Ну нашёл что-нибудь здесь для решения или хотя бы снижения градуса своей проблемы?

Сообщение отредактировано: neokoder - 28.01.14, 14:06

Имхо, идеальной защиты не сделать. Если есть необходимость, то можно периодически выискивать кряки и править код, чтобы они перестали работать наипростейшим образом. Заморачивается не стоит. Ну допустим заменим статическое взывание на динамическое, этот кулкацкер скачает новую версию, быстро посечет, что DLL подцепляется динамически (через отладчик) и элементарно заменит параметр в LoadLibrary на нужный себе. Правда будет уже распространять исполняемый файл + DLL. Попытаться удалять DLL? Сразу найдет неугодный вызов DeleteFile или что-нить аналогичного.

shm

А если юзать Obfuscator-LLVM ? http://crypto.junod.info/2013/12/24/about-...cademic-ethics/