После обновления на 1903 люди начали жаловаться что перестали работать лекарства, реализованные через прокси-дллки.
Например version.dll
Для тех кто не в теме: винда по умолчанию (раньше) ищет загружаемую прогой dll сначала в папке самой проги, если не находит, то дальше идёт в ...\system32\ .Если мы создаём dll с системным именем, как например version.dll, сделаем в ней тот же экспорт, и "проксирование" этого экспорта на настоящую системную dll. То все будет работать как раньше, но наша dll уже инжектирована в процесс, причем на самом старте, и мы можем делать с ним что угодно.

Тепрь же это не прокатывает, dll сразу грузится из system32....
Комрады, в какую сторону копать? Чую какое то обновление виновато, может какие записи в реестре появились или еще что. Кстати в Win2012 после установки обнвлений та же беда...

| Сообщение посчитали полезным:

RAMZEZzz пишет:
Думаю надо копать в сторону .config файла,
А если манифест?
К примеру...


| Сообщение посчитали полезным:

Ты используешь крипто апи, это тянет cryptbase.dll которая внезапно пытается прогрузится из локальной папки программы.

| Сообщение посчитали полезным: RAMZEZzz

Alchemistry
Хм, спасибо, не обратил внимания.
Но все таки с cryptbase это частный случай, в проге может и свой криптоалгоритм быть прописан

| Сообщение посчитали полезным:

Если программа использует commctl или gdiplus (см ее манифест или просто депенденси волкером) то можно попробовать инжект через механизм dotlocal.

| Сообщение посчитали полезным:

если кому нужны еще примеры с неработающей прокси dll в win 10 1903 - релиз MiniTool Partition Wizard v11.4 by OnlyOne --> Link <--... прога с dll просто не стартует...

| Сообщение посчитали полезным:

и эта работает без проблем и предыдущая версия (там длл была пакованная) тоже работала на 1903

ЗЫ версия 11.5 тоже работает

| Сообщение посчитали полезным:

evggrig пишет:
если кому нужны еще примеры с неработающей прокси dll в win 10 1903 - релиз MiniTool Partition Wizard v11.4 by OnlyOne --> Link <--... прога с dll просто не стартует..
Все работает. Смотрите в сторону антивирусов.

| Сообщение посчитали полезным:

Пробовал переименовать в импорте дотнет приложения mscoree на mscore1 и подложить проксик с таким именем, приложение не запускается. Procmon все равно показывает загрузку оригинального mscoree.dll

| Сообщение посчитали полезным:

RAMZEZzz

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

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
Включи загрузочный лог
это где и как его включить?

| Сообщение посчитали полезным:

IFEO.GlobalFlag -> 2.

-----
vx

| Сообщение посчитали полезным:

RAMZEZzz
Проблема с автоподгрузкой version.dll для win 10 1903 актуальна для программ на дотнете, ибо именно дотнет грузит эту длл первой. Как вариант - надо ложить эту длл именно в папку к дотнету(для х64 например сюда "C:\Windows\Microsoft.NET\Framework64\v4.0.30319", и она оттуда будет подгружаться в твой софт. Соответственно она будет подгружаться и в другие проги на дотнете, поэтому в длл надо как минимум на старте проверять куда она подгрузилась и не делать лишнего где не надо. Если для нескольких прог - то тогда уж проблемно, ибо надо пихать все в одну длл, что не есть гут (ну или version.dll использовать как загрузчик только другой любой длл в нужный процесс).

| Сообщение посчитали полезным: RAMZEZzz

Tolkin
Да, идея хорошая. Спасибо. Но тоже не всегда оттуда пытается грузить.

Вот что еще удалось выяснить:
Если в приложении нет манифеста в ресурсах (а это редко) и он лежит рядом с exe то добавив туда в секцию "assembly" такую строчку: <file name="version.dll" />
DLL начинает грузиться.

Пару суток курения MSDN не помогли заставить грузить внешний манифест вместо встроенного (хотя может кто знает как это сделать?)

Ну или искать другие dll какие дотнет программа пытается загрузить из своей папки и на основе них делать прокси (пока так и делаю). Но для каждой программы они разные. Эх а как было хорошо с "универсальной" версион...

| Сообщение посчитали полезным:

RAMZEZzz пишет:
Пару суток курения MSDN не помогли заставить грузить внешний манифест вместо встроенного (хотя может кто знает как это сделать?)
Внешний манифест при наличии внутреннего игнорируется. Никак.

Чем тебя не устраивает профайлер дотнет. Загрузит тебе хоть HYI32.dll хоть version128.dll. Единственное что надо будет проверять в коде а в тот ли ты процесс попал потому что это работает глобально для всех дотнет приложений.

| Сообщение посчитали полезным: RAMZEZzz

Alchemistry пишет:
Чем тебя не устраивает профайлер дотнет.
Да понять бы еще что это и как им загрузить dll? Что то нахожу - читаю, но терзают смутные сомнения - что не то.

UPD:
Взял за основу: ExampleProfiler
На событие AppDomainCreationFinished повесил LoadLibrary(L".\version.dll");
на тестовой проге работает, на реальных - из 5 проверенных сработало только на одной, другие даже не грузят дллку профилера Разбираюсь дальше....

| Сообщение посчитали полезным:

RAMZEZzz

REG ADD "HKCU\Software\Classes\CLSID\{FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF}\InprocServer32" /ve /t REG_EXPAND_SZ /d "C:\Temp\test.dll" /f
REG ADD "HKCU\Environment" /v "COR_PROFILER" /t REG_SZ /d "{FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF}" /f
REG ADD "HKCU\Environment" /v "COR_ENABLE_PROFILING" /t REG_SZ /d "1" /f
REG ADD "HKCU\Environment" /v "COR_PROFILER_PATH" /t REG_SZ /d "C:\Temp\test.dll" /f

test.dll



| Сообщение посчитали полезным: freudz, Lambda

Alchemistry

Вот интересный момент, если дот-нет таргет накрыт протектором, который в последствии грузит managed код, то подобный способ не работает (

речь идет о
Alchemistry пишет:
REG ADD "HKCU\Software\Classes\CLSID\{FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF}\InprocServer32" /ve /t REG_EXPAND_SZ /d "C:\Temp\test.dll" /f

Такие дела...

| Сообщение посчитали полезным:

Для таких ситуаций есть множество других способов, тот же верифер например.

| Сообщение посчитали полезным:

Alchemistry пишет:
тот же верифер например.

А можно подробней чутка, если не оффтоп?..

| Сообщение посчитали полезным:

Пишешь свою длл в формате верифера и регаешь ее для выбранного приложение через IFEO. Приложение грузится и нтдлл грузит твою длл на ранней стадии инициализации. Инфы в гугле предостаточно вместе с готовым кодом.

| Сообщение посчитали полезным: freudz, Tolkin, Hugo Chaves, difexacaw, plutos

Alchemistry пишет:
в формате верифера

Спасибо. Собссно нужно было пару ключевых слов для гугления.
Интересный, надо скахать, подход.
Буду тестить.

| Сообщение посчитали полезным:

Alchemistry

AVRF самый простой и хороший способ загрузки в процесс, это верно. Но это нэйтив, провайдер должен быть нэйтивным и запускается он до загрузки юзер среды, тоесть винапи и тп нельзя юзать. А тут тема про .net и прочий басик, так что врядле это им нужно и чем то поможет

-----
vx

| Сообщение посчитали полезным:

difexacaw
В принципе ничего не мешает посидеть там же на колбеке верифера и посмотреть когда загрузятся все нужные длл, потом дергать апи через gpa. Комрад freudz спросил - вот ему вариант раз так хотелось.

| Сообщение посчитали полезным:

Для верифера нужно только вставить код обработки ошибок, поскольку мало сейчас правильно пишут, 0xC0000008 часто вылетает. Засуньте верифер в любую популярную игру, много чего писать для обработки, чтоб он там работал нормально.

-----
IZ.RU

| Сообщение посчитали полезным:

Alchemistry пишет:
В принципе ничего не мешает посидеть там же на колбеке верифера и посмотреть когда загрузятся все нужные длл, потом дергать апи через gpa

Мерси, именно в эту сторону и думал. Главное попасть в процесс.
Планирую также проверить AVRF на предмет попадания в Windows Service и последующего хука винсокета recv/send. Пока не вижу препятствий. )

| Сообщение посчитали полезным:

freudz пишет:
Планирую также проверить AVRF на предмет попадания в Windows Service
Да хоть services.exe, хоть smss.exe!

-----
IZ.RU

| Сообщение посчитали полезным: freudz

DenCoder

> 0xC0000008 часто вылетает

Если параметр задан, но обнулён, это не значит что он не используется. Нужно задать VerifierFlags eq 0, тогда не будет включена трассировка описателей и не будет этой ошибки

Добавлено спустя 19 минут
DenCoder

> Да хоть services.exe, хоть smss.exe!

Это способ запуска дий для системных процессов. Тот же lsass запускается под визором через данный механизм. Это нужно что бы не пропустить ничего, запуск до юзер оболочки. Интересно что при взятии под визор серверного процесса система уходит в синь, не знаю почему, но происходит бсод из юзер треда.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
Интересно что при взятии под визор серверного процесса система уходит в синь, не знаю почему, но происходит бсод из юзер треда.
Может, какая-то подсистема ещё не готова? При попытке использовать бсод. Было у меня такое 10 лет назад при инжекте в winlogon на старте системы. Решение нашёл в ожидании вызова какой-то функции из user32.dll - вызов прошёл, значит можно использовать всё остальное дальше.

-----
IZ.RU

| Сообщение посчитали полезным:

DenCoder

Ядро ничего не знает про готовность". Я думал что там видел уже всё, но нет. Чудеса таки бывают:

- analyze -v

BugCheck D1, {75b14b0c, ff, 0, 70005bed}

FOLLOWUP_IP:
nt!Kei386EoiHelper+2883
804e0a9c f7457000000200 test dword ptr [ebp+70h],20000h



Адрес в обычной юзер длл, не на сискале(на call rel). В xp была трабла с ядреными указателями в гуй, потом это зафиксили. Такое может быть только в свопируемой секции драйвера. Изначально я думал что это проблема фильтров, но удалив из системы сиську происхоит тоже самое. Оказалось что и на 7-ке та же синь

Такое возможно только если создаётся ядерный поток и по какой то причине поднимается IRQL, память свопиться и происходит ядерный #AV. Этого не может быть в юм

-----
vx

| Сообщение посчитали полезным:

Так а на какой функции падает-то?

-----
IZ.RU

| Сообщение посчитали полезным: