PNG/ICO/CUR/ANI изображения в стандартных контролах VB6.

Автор обещает много интересных штучек.

Модератор: The trick

The trick
Постоялец
Постоялец
 
Сообщения: 534
Зарегистрирован: 26.06.2010 (Сб) 23:08

PNG/ICO/CUR/ANI изображения в стандартных контролах VB6.

Сообщение The trick » 23.01.2019 (Ср) 23:47



ОПИСАНИЕ УСТАРЕЛО. АКТУАЛЬНОЕ ОПИСАНИЕ НА GITHUB.

Всем привет.

Как известно встроенные средства Visual Basic 6.0 не поддерживают возможности работы с PNG изображениями, т.е. к примеру нельзя ипользовать Png картинку в качестве свойства Form.Picture. Я представляю небольшую библиотеку и Add-in которые позволяют обойти эти ограничения. Данная библиотека позволяет загружать и сохранять Png изображения (с альфа каналом) стандартными средствами (LoadPicture / SavePicture), а также включает поддержку Png изображений (с альфа каналом) в контролы. Любой контрол который в своей работе использует стандарнтые Ole Picture объекты будет поддерживать загрузку Png изображений. В свою очередь если изображение выводится посредством IPicture::Render то картинка будет отрисовываться с учетом альфа канала. Данная библиотека должна работать на всех версиях Windows начиная с XP:

Изображение

Как использовать?

Библиотека может быть использована как внешняя DLL либо быть прилинкована к исполняемому файлу (только native code). Для использования в качестве Dll необходимо вызвать функцию Initialize которая вернет 1 в случае успеха. После этого можно пользоваться возможностями библиотеки. Если необходимо выгрузить библиотеку то нужно вызвать функцию CanUnloadNow которая сообщит можно ли в данный момент выгрузить библиотеку. Если библиотека готова к выгрузке функция вернет S_OK после которой нужно вызвать Uninitialize. Если функция возвращает S_FALSE то библиотеку нельзя выгружать т.к. имеются активные Picture объекты которые еще не выгружены и они используют библиотеку. Для IDE создан специальный Add-in который автоматически загружает библиотеку при старте среды. В скомпилированном варианте можно к примеру в событии Initialize или в процедуре Main вызывать Initialize, а при завершении Uninitialize:
Код: Выделить всё
Private Declare Function Initialize Lib "VBPng.dll" () As Long
Private Declare Sub Uninitialize Lib "VBPng.dll" ()

Private Sub Form_Initialize()

    If Initialize() = 0 Then
        MsgBox "Unable to initialize png dll", vbCritical
    End If
   
End Sub

Private Sub Form_Terminate()
    Uninitialize
End Sub


Для статической линковки необходимо использовать более новый линкер (в своих примерах я использовал линкер из Visual Studio 2010), поскольку оригинальный имеет баги при использовании опции /OPT:REF, а также в секцию VBCompiler файла проекта (vbp) необходимо добавить параметры:
Для EXE:
Код: Выделить всё
LinkSwitches= ..\Libs\msvcrt_winxp.obj ..\Libs\VBPng.lib -ENTRY:mainCRTStartup

Для DLL:
Код: Выделить всё
LinkSwitches= ..\Libs\msvcrt_winxp.obj ..\Libs\VBPng.lib -ENTRY:VBDllMain -EXPORT:Initialize -EXPORT:Uninitialize

В случае DLL, в скомпилированном виде необходимо сделать инициализацию, вызвав Initialize из себя же при первом запуске.

Как это работает?

Библиотека написана на C++. Принцип работы библиотеки основан на перехвате функций OleLoadPictureEx и OleLoadPicture. Данные функции не поддерживают загрузку PNG изображений, поэтому если загружается PNG файл, библиотека VbPng пытается загрузить файл с помощью GDI+. При успехе создается аналогичный StdPicture объект который и возвращается функцией. Для вызывающей стороны все это выглядит как-будто она работает с оригинальным объектом. Сам объект поддерживает интерфейсы IPicture, IPictureDisp, IPersistStream, IConnectionPointContainer (не поддерживает connection point'ы возвращает E_NOTIMPL), IDispatch, поэтому может быть присвоен Object переменной или к примеру быть сохраненным в PropertyBag.

Перехватчик функций реализован в классе CHooker. Данный класс использует дизассемблер длин (ldasm) от Ms-Rem с небольшой доработкой. Доработка заключается в добавление флага OP_REL32 к некоторым инструкциям (к примеру JMP SHORT), поскольку в оригинале на некоторых относительных инструкциях этот флаг отсутствовал. Для перехвата функции используется простейший метод сплайсинга при котором в начало функции всталяется инструкция JMP которая переводит поток исполнения на функцию-перехватчик. Поскольку в начале оригинальной функции содержатся инструкции которые мы перезаписываем, необходимо правильно перенести инструкции для того чтобы была возможность вызвать оригинальную функцию. При вызове метода Hook с помощью дизассемблера длин определяется целое количество инструкций которое будет перезаписано инструкцией JMP (5 байт). После этого выделяется временный буфер (с разрешением на исполнение данных) в который будут скопированы данные инструкции + JMP на инструкцию следующую за перезаписываемой. Это позволит, передав управление на этот буфер, вызвать оригинальную функцию как-будто перехвата не было. Тут существует одна сложность заключающаяся в том, что мы не можем просто так скопировать инструкции, поскольку существуют относительные инструкции типа JMP, CALL, JNE которые "прыгают" относительно своего адреса. Для определения типа инструкции как раз и служит флаг OP_REL32 который показывает является ли инструкция относительной или нет. Другая сложность заключается в том что существуют "короткие" относительные инструкции которые "прыгают" в пределах 255 байт, а при переносе кода в буфер расстояние может значительно увеличится. Поэтому после определения количества перезаписываемых инструкций выделяется буфер размером как минимум чтобы обеспечить транслирование из коротких в длинные инструкции. После этого производится анализ каждой инструкции и при необходимости происходит корректировка смещения и типа. В конце буфера добавляется инструкция JMP со смещением на инструкцию следующую за последней перезаписаной. Наконец начало функции перезаписывается на безусловный JMP на функцию-перехватчик.

CHooker объекты используют в качестве буфера кода кучу (Heap) с разрешением на исполнение, поэтому код является DEP безопасным. Куча автоматически создается при создании первого перехватчика и удаляется при уничтожении последнего. В проекте используются 2 таких объекта для перехвата 2-х функций OleLoadPictureEx и OleLoadPicture, с соответствующим перехватчиками OleLoadPictureEx_user и OleLoadPicture_user. В системах до Windows 8 можно было перехватывать только одну OleLoadPictureEx функцию которая вызывается из OleLoadPicture, но начиная с Windows 8 OleLoadPicture вызывает уже недокументированную OleLoadPictureExt, поэтому для обеспечения правильной работы некоторых контролов (к примеру ImageList) нужно перехватывать 2 этих функции. Конечно можно пробовать перехватывать OleLoadPictureExt, но эта функция недокументирована и не факт что в новых версиях Microsoft не изменят эту функцию на другую. В перехватчиках вызывается оригинальная функция и если вызов окончился неудачей вызывается наша реализация. Чтобы обеспечить возможность узнать был ли перехват уже осуществлен (к примеру подгруженная DLL уже перехватила и нет смысла делать это еще раз) используется переменна окружения "VBPng".

Основа библиотеки - класс CPicture который и реализует всю логику работы изображений. Данный класс создавался на основе реверс-инжиниринга библиотеки oleaut32 некоторые функции возможно реализованы не точно. Данный класс позволяет загружать PNG изображения из COM потока (IStream), а также сохранять их в него. Библиотека ведет учет созданных объектов в глобальной переменной g_lCountOfObject для того чтобы обеспечить контроль при выгрузке библиотеки вызовом CanUnloadNow. В противном случае не было бы способа узнать можно ли выгрузить библиотеку или нет. Соответственно при выгрузке библиотеки которой пользуются активные объекты происходило бы падение.

Загрузка изображения выполняется в методе LoadFromStream. Поскольку при загрузке из потока GDI+ автоматически устанавливает указатель в начало, приходится создавать поток в коотром содержатся только данные PNG файла. Эта задача выполняется методом CreatePngStream в котором происходит также первичная валидация PNG чанков. Далее с помощью GDI+ происходит создание объекта Bitmap из данных временного потока. Далее создается DIB-секция и в нее копируются данные PNG пикселей в формате PixelFormat32bppPARGB. Это позволяет выводить изображение с альфа-каналом посредством функции AlphaBlend, а также имеется возможность доступа к GDI-совместимому HBITMAP. Далее, если установлено свойство KeepOriginalFormat равным true, происходит сохранение PNG потока (это позволяет легко сохранять PNG файл без перекодировки).

Второй по важности метод - это Render. Тут все просто, происходит подготовка координат для вывода изображения в HIMETRIC и происходит вывод с помощью AlphaBlend. Т.к. свойство get_Attributes возвращает PICTURE_TRANSPARENT то пользователь перед выводом изображения сам заботится о восстановлении фона за изображением.

Метод SaveAsFile сохраняет изображение в поток. Тут все тоже самое только наоборот. Также стоит отметить что если использовалось сохранение оригинального формата то данные изображение берутся из сохраненного PNG потока. В противном случае создается временный GDI+ битмап из пикселей DIB-секции, извлекается CLSID PNG кодека и происходит сохранение изображения во временный поток. Далее из этого потока данные копируются в поток назначения.

Следующая группа методов это реализация интерфейса IDispatch. Поскольку данные о типе IPicture хранятся в стандартной библиотеке stdole2.tlb то в методе GetTypeInfo происходит загрузка этой библиотеки с извлечением нужного интерфейса типа через ITypeLib::GetTypeInfoOfGuid. Тоже самое относится к методу GetIDsOfNames, тут просто происходит транслирование вызова стандартному ITypeInfo::GetIDsOfNames. Метод Invoke реализован напрямую с проверкой параметров.

Для того чтобы можно было статически прилинковать библиотеку к VB6 EXE файлу необходимо инициализировать сишный рантайм передачей управления на функцию mainCRTStartup и передать управление на метку ___vbaS. Для этой цели служит файл gostartup.asm написаный на fasm'е. Для EXE файла выполняются строчки:
Код: Выделить всё
_main:
call Initialize
jmp ___vbaS

Сишный рантайм вызывает функцию main, а она в свою очередь инициализирует библиотеку VbPng. Тут существует проблема со старым линкером, поскольку то ли из-за бага, то ли из-за чего то еще, ликер отбрасывает весь VB-шный импорт из результирующего файла при использовании опции -OPT:REF. Решается данная проблема просто - заменой линкера на современный.
Для DLL выполняются похожие действия, только в этом случае необходимо указать в качестве точки входа _VBDllMain:
Код: Выделить всё
_VBDllMain:

push dword [esp + 12]
push dword [esp + 12]
push dword [esp + 12]

; // Init CRT
call  __DllMainCRTStartup@12

; // Init runtime
jmp ___vbaS   

В этом случае сначала вызывается инициализации сишного рантайма, а затем происходит переход на функцию DllMain ActiveX Dll.

Для олегчения работы в IDE был написан Add-in который автоматически загружает VbPng.dll для того чтобы было удобно работать с проектами. Для отключения библиотеки просто нужно отключить Add-in. Тут есть ньюанс, если есть активные PNG-изображения, то Add-in выгрузится, но VbPng нет, при этом покажется предупреждение. В любой момент можно будет включить Add-in, найти изображения, удалить их, и заново отключить Add-in, тогда DLL выгрузится.

_____________________________________________________________________________________________________________

Некоторые контролы, к примеру ListView, не будут отображать альфа канал, поскольку отрисовывают себя не методом Render, а через StretchBlt, для них premultiplied фон будет черный. Это следует иметь в виду при работе с библиотекой. Также не поддерживаются уведомления IPropertyNotifySink (при желании можно реализовать). Ресурсы в FRX файлах и скомпилированных файлах также хранятся в PNG поэтому проекты не будут открываться и работать без библиотеки. Для комфортной работы рекомендуется установить Add-in с автоматическим запуском при загрузке IDE.

В директории содержатся также несколько примеров работы:
  • Test_EXE_Linked - демонстрация 32bpp PNG изображений на стандартных контролах с использованием статической линковки;
  • Test_EXE_Dll - тоже самое только с использованием dll;
  • Test_AXDll - ActiveX DLL библиотека с использованием PNG ресурсов на форме;
  • Test_SavePng - пример сохранения изображения посредством SavePicture.

Также в директории содержатся PNG файлы, собраные мной еще давно посредством спутниковой рыбалки.

Модуль слабо тестировался, поэтому возможны баги. Буду очень рад любым замечаниям, по мере возможности буду их исправлять.
Всем спасибо за внимание, надеюсь модуль кому-то будет полезен.

Проект на GitHub.

The trick,
2019.
UA6527P

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16147
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: PNG изображения в стандартных контролах VB6.

Сообщение Хакер » 25.01.2019 (Пт) 19:30

Поддержка PNG и альфа-канала — вещи очень нужные и желанные.

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

Насколько я помню из поверхностного исследования, которое делал 3 года назад (кошмар, я думал это было максимум год назад), OLE не возится самостоятельно с форматами, а при раскодировке файлов полагается на стороннюю DLL-библиотеку. Под каждый формат там есть свой класс, поддерживающий IImageFilter. Я там обнаружил классы для JPEG и GIF.

Идея в том, чтобы решить проблему путём модификации библиотеки-провайдера с классами-раскодировщиками путём добавления туда класса для расшифровки PNG. Модифицированную библиотеку предлагается подсовывать вместо оригинальной не путём подмены файла в system32 (ибо это некрасиво), а с помощью SxS и манифеста — что красиво и правильно. Если наше приложение, точнее его автор, уверен в том, что поддержка PNG ничего в логике приложения не ломает, он снабжает приложение манифестом и оно начинает поддерживать PNG подобно тому, как это было со «стилем XP» для тех приложений, для которых поддержка нового оформления ничего не ломает.

Правда по-моему логика выбора CLSID-а класса-фильтра где-то там была забита жестко, так что боюсь библиотеке в этом случае в момент загрузки придётся всё-таки вмешивать в код OLE с перехватами/модификациями.

Но, в общем, идея в том, что раз проблема неподдержки PNG — это проблема OLE, а не VB, то и решаться она должна на уровне OLE и с применением манифеста (чтобы ничего не сломать нигде). Как бонус: такое решение позволило бы добавить поддержку PNG к другим приложениям, полагающимся на OLE, без необходимости модифицировать их код (путём вставки туда подгрузчика твоей DLL-шки), а просто путём добавления к ним манифеста, что проще. Подход с манифестом также избавил бы от необходимости иметь Add-In.

Что касается самого перехвата: зачем нужен дизассемблер длин, если у перехватываемой функции hook-friendly пролог? Я имею в виду nop×5 + mov edi,edi. На случай, если в каком-то билде библиотеки OLE этот пролог уберут? Они не должны его убрать, потому что оно используется в самой Windwos для перехвата функций.

Код пока не смотрел, DLL не тестировал.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

The trick
Постоялец
Постоялец
 
Сообщения: 534
Зарегистрирован: 26.06.2010 (Сб) 23:08

Re: PNG изображения в стандартных контролах VB6.

Сообщение The trick » 25.01.2019 (Пт) 21:15

Хакер, загрузить PNG еще пол проблемы, его еще нужно отрисовать правильно. Штатные средства рисуют битмапы с помощью StretchBlt, так что если гипотетически как-то получится заставить загрузить PNG (а это скорее всего не получится т.к. проверка типа файла происходит внутри самой oleaut32) то отрисовать его верно не получится:
Код: Выделить всё
    if ( !(_WORD)a2 )
    {
      result = _PictLoadIconToPicInfo(a1, v7, a5, a6, a7);  // Icon
      goto LABEL_15;
    }
    if ( (unsigned __int16)a2 == 1 )
    {
      result = _PictLoadUnknownMetaFile(a1, v7, dwBytes);  // Metafiles
    }
    else
    {
      if ( (unsigned __int16)a2 != 'IG' )   // GIF
      {
        if ( (unsigned __int16)a2 == 'MB' )  // BMP
        {
          result = _PictLoadDIBitmap(a1, v7, dwBytes);
          goto LABEL_15;
        }
        if ( (unsigned __int16)a2 != 'ig' )  // GIF
        {
          if ( (unsigned __int16)a2 == 0xCDD7 ) // WmfPlaceableFileHeader
          {
            result = _PictLoadMetaFile(a1, v7, dwBytes);
          }
          else if ( (unsigned __int16)a2 == 0xD8FF )   // JPEG
          {
            result = _PictLoadSyncImage(&CLSID_JPEGFilter, a1, v7);
          }
          else
          {
            result = CTL_E_INVALIDPICTURE;
          }
          goto LABEL_15;
        }
      }
      result = _PictLoadSyncImage(&CLSID_GIFFilter, a1, v7);
    }

Это часть кода из oleaut32 в котором видно проверку разных типов файлов по сигнатурам в функции _PictLoadNewImage которая используется всеми OleLoadPicture* функциями.

Что касается самого перехвата: зачем нужен дизассемблер длин, если у перехватываемой функции hook-friendly пролог? Я имею в виду nop×5 + mov edi,edi. На случай, если в каком-то билде библиотеки OLE этот пролог уберут? Они не должны его убрать, потому что оно используется в самой Windwos для перехвата функций.

Этот хукер у меня много где используется для перехвата не friendly-hook функций (к примеру в VBA6.dll), поэтому я использовал его. Он универсален и может использоваться вообще в любых проектах. Для hot-patching'а пришлось бы дополнительно анализировать не стоит ли патч, делать редирект и т.д.
UA6527P

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16147
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: PNG изображения в стандартных контролах VB6.

Сообщение Хакер » 26.01.2019 (Сб) 7:40

The trick писал(а):Он универсален и может использоваться вообще в любых проектах.

И вызывать непредсказуемые креши от того, что правит код, который в данный момент выполняется как раз в том месте, которое пытаются править.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

The trick
Постоялец
Постоялец
 
Сообщения: 534
Зарегистрирован: 26.06.2010 (Сб) 23:08

Re: PNG изображения в стандартных контролах VB6.

Сообщение The trick » 26.01.2019 (Сб) 9:32

Хакер писал(а):И вызывать непредсказуемые креши от того, что правит код, который в данный момент выполняется как раз в том месте, которое пытаются править.

А какой подход для перехвата не friendly-hook функций может обеспечить протекцию от этого?
Второй момент, это то что перехватчик перехватывает, а анализатор потоков анализирует - это уже другая сущность. И он-таки есть, только не используется в данном коде, т.к. на 99,9999% не нужен и будет просто бесполезно раздувать размер итоговой программы.
UA6527P

Teranas
Продвинутый пользователь
Продвинутый пользователь
Аватара пользователя
 
Сообщения: 152
Зарегистрирован: 13.12.2008 (Сб) 4:26
Откуда: Новосибирск

Re: PNG изображения в стандартных контролах VB6.

Сообщение Teranas » 27.01.2019 (Вс) 17:07

Прифетствую!

Без обид, но у меня ничего вообще не запускается.
Вложения
Screenshot_1.jpg
Screenshot_1.jpg (49.25 Кб) Просмотров: 173
С уважением, Андрей.

The trick
Постоялец
Постоялец
 
Сообщения: 534
Зарегистрирован: 26.06.2010 (Сб) 23:08

Re: PNG изображения в стандартных контролах VB6.

Сообщение The trick » 27.01.2019 (Вс) 19:05

Без обид

Какие обиды? Наоборот, спасибо за тестирование!

Add-in загружен?
UA6527P

The trick
Постоялец
Постоялец
 
Сообщения: 534
Зарегистрирован: 26.06.2010 (Сб) 23:08

Re: PNG изображения в стандартных контролах VB6.

Сообщение The trick » 29.01.2019 (Вт) 20:09

29.01.2019
Обновление.
Пофикшен баг при использовании загрузки PNG изображений из PropertyBag.
UA6527P

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16147
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: PNG изображения в стандартных контролах VB6.

Сообщение Хакер » 29.01.2019 (Вт) 20:52

The trick писал(а):А какой подход для перехвата не friendly-hook функций может обеспечить протекцию от этого?

Почему friendly-hook? Дружелюбный крюк? Hook-friendly же!

Никакой подход кроме подмены mov edi, edi не может обеспечить это. По этой причине тот единственный подход и используется на практике в Windows.

То, что необходимо определять, установлен ли перехват, не звучит как достойное основание не использовать хот-патчинг. Проверить, что первая инструкция либо mov edi, edi, либо jmp назад — ерундовое дело. Если она кем-то уже перехвачена, то достаточно поправить предшествующий длинный jmp-переходничок. То, что в таком случае два перехвата должны сниматься в обратном порядке, по отношению к порядку установки — да, но это ограничение действует вообще при любом способе перехвата функций. Так что это не контраргумент.

Дизассемблер длин, к тому же, если это не высокоинтеллектуальный анализатор, не сможет понять, что в середину перезаписываемой цепочки инструкций не делается джамп откуда-то из середины процедуры, и гарантировать, что не произойдёт джамп на точку, попавшую в на середину новой инструкции.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

The trick
Постоялец
Постоялец
 
Сообщения: 534
Зарегистрирован: 26.06.2010 (Сб) 23:08

Re: PNG/ICO/CUR/ANI изображения в стандартных контролах VB6.

Сообщение The trick » 03.02.2019 (Вс) 15:03

3.02.2019
Обновление.
Добавлена поддержка 32 битных иконок с альфаканалом, курсоров и анимированных курсоров.
UA6527P


Вернуться в The trick

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

    TopList