Blog. Just Blog

Быстрый поиск

Введите фрагмент названия статьи для поиска

Парсинг метаданных OGG-файлов на Ассемблере

01.11.2022 | Категория: Образ мышления: Assembler | Автор: ManHunter

Парсинг метаданных OGG-файлов на Ассемблере

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

Читать статью целиком »
Просмотров: 521 | Комментариев: 0

Как получить путь из символической ссылки

24.10.2022 | Категория: Образ мышления: Assembler | Автор: ManHunter
Начиная с Windows Vista, в системе появились так называемые символические ссылки, специальные файлы, в которых вместо каких-либо данных содержится путь к другому файлу или каталогу, открываемому при обращении к этой ссылке. Это позволяет, например, иметь для одного и того же файла сразу несколько разных имен.

Чтобы получить целевой путь, на который указывает символическая ссылка, есть несколько методов. Обычно в этих ваших интернетах рекомендуют сложный путь через использование функции DeviceIoControl. Штука интересная, с нее и начнем. Но сперва пачка структур и констант, которые нам понадобятся для работы.
  1. struct SymbolicLinkReparseBuffer
  2.     SubstituteNameOffset dw ?
  3.     SubstituteNameLength dw ?
  4.     PrintNameOffset      dw ?
  5.     PrintNameLength      dw ?
  6.     Flags                dd ?
  7.     PathBuffer           rw MAX_PATH*2
  8. ends
  9.  
  10. struct MountPointReparseBuffer
  11.     SubstituteNameOffset dw ?
  12.     SubstituteNameLength dw ?
  13.     PrintNameOffset      dw ?
  14.     PrintNameLength      dw ?
  15.     PathBuffer           rw MAX_PATH*2
  16. ends
  17.  
  18. struct GenericReparseBuffer
  19.     DataBuffer           db ?
  20. ends
  21.  
  22. struct REPARSE_DATA_BUFFER
  23.     ReparseTag dd ?
  24.     ReparseDataLength dw ?
  25.     Reserved dw ?
  26.     union
  27.         SymbolicLink SymbolicLinkReparseBuffer
  28.         MountPoint   MountPointReparseBuffer
  29.         Generic      GenericReparseBuffer
  30.     ends
  31. ends
  32.  
  33. FSCTL_GET_REPARSE_POINT      = 0x000900A8
  34. FILE_FLAG_BACKUP_SEMANTICS   = 0x02000000
  35. FILE_FLAG_OPEN_REPARSE_POINT = 0x00200000
  36. IO_REPARSE_TAG_MOUNT_POINT   = 0xA0000003
  37. IO_REPARSE_TAG_SYMLINK       = 0xA000000C
Первым делом для вашего процесса надо активировать привилегию SeBackupPrivilege. Это мы уже делали, тут ничего нового нет. В оригинале эта привилегия нужна для выполнения резервного копирования файлов, а по факту она предоставляет доступ на чтение для любого файла, независимо от списка контроля доступа. Именно это нам требуется для получения информации из символической ссылки.

Читать статью целиком »
Просмотров: 442 | Комментариев: 2

Сортировка Шелла на Ассемблере

06.10.2022 | Категория: Образ мышления: Assembler | Автор: ManHunter

Сортировка Шелла на Ассемблере

Сегодня разберем еще один алгоритм сортировки - сортировку Шелла. Он назван в честь ученого Дональда Шелла, который в 1959 году опубликовал этот алгоритм. Сортировка Шелла представляет собой нечто среднее между классической пузырьковой сортировкой и сортировкой вставками, легко реализуется на разных языках программирования, при этом показывает хорошую скорость работы и не требует выделения дополнительной памяти.

Читать статью целиком »
Просмотров: 656 | Комментариев: 5

Загрузка шрифтов WOFF на Ассемблере

18.09.2022 | Категория: Образ мышления: Assembler | Автор: ManHunter

Загрузка шрифтов WOFF на Ассемблере

WOFF или Web Open Font Format - формат шрифтов, чаще всего используемый для Web. Он основан на стандартных форматах шрифтов OpenType или TrueType, но данные в WOFF хранятся в сжатом виде, за счет чего повышается скорость загрузки. Штатными средствами система Windows с такими шрифтами работать не умеет, поэтому мне стало интересно разобраться с этим форматом.

Читать статью целиком »
Просмотров: 577 | Комментариев: 2

Получение размера динамической памяти приложения (Heap)

05.09.2022 | Категория: Образ мышления: Assembler | Автор: ManHunter
Heap или куча - особая структура данных, с помощью которой приложению выделяется динамически распределяемая память. Крайне удобная штука, когда надо быстренько выделить немного памяти под сиюминутные нужды. Но при активной работе с кучей может возникнуть ситуация, когда надо узнать размер оставшейся памяти, общий размер кучи или максимальный размер непрерывных данных, которые туда можно записать. Что-то из этого можно узнать при помощи штатных функций, а что-то придется получать копанием в недрах системы. Но сперва несколько структур и констант для работы. Их нет даже в MSDN, не говоря уже о FASM.
  1. struct DEBUG_BUFFER
  2.         SectionHandle        dd ?
  3.         SectionBase          dd ?
  4.         RemoteSectionBase    dd ?
  5.         SectionBaseDelta     dd ?
  6.         EventPairHandle      dd ?
  7.         Unknown              rd 2
  8.         RemoteThreadHandle   dd ?
  9.         InfoClassMask        dd ?
  10.         SizeOfInfo           dd ?
  11.         AllocatedSize        dd ?
  12.         SectionSize          dd ?
  13.         ModuleInformation    dd ?
  14.         BackTraceInformation dd ?
  15.         HeapInformation      dd ?
  16.         LockInformation      dd ?
  17.         Reserved             rd 8
  18. ends
  19.  
  20. struct DEBUG_HEAP_INFORMATION
  21.         Base        dd ?
  22.         Flags       dd ?
  23.         Granularity dw ?
  24.         Unknown     dw ?
  25.         Allocated   dd ?
  26.         Committed   dd ?
  27.         TagCount    dd ?
  28.         BlockCount  dd ?
  29.         Reserved    rd 7
  30.         Tags        dd ?
  31.         Blocks      dd ?
  32. ends
  33.  
  34. PDI_HEAPS = 0x04
  35. PDI_HEAP_BLOCKS = 0x10
Каждый процесс может иметь больше одного объекта кучи, для получения данных об этих объектах воспользуемся недокументированной функцией RtlQueryProcessDebugInformation, предварительно подготовив буфер для приема данных еще одной недокументированной функцией RtlCreateQueryDebugBuffer. Указатель на интересующие нас данные содержится в поле HeapInformation структуры DEBUG_BUFFER. Это массив из нескольких структур типа DEBUG_HEAP_INFORMATION, каждая из которых соответствует одному из объектов кучи процесса. Перебирая их по очереди и сравнивая поле Base с искомым хэндлом, находим нужный объект. В следующем код предполагается, что в переменной hHeap содержится хэндл созданной кучи, по которой мы хотим получить информацию.
  1.         ; Зарезервировать буфер для отладочной информации
  2.         invoke  RtlCreateQueryDebugBuffer,0,FALSE
  3.         mov     [debug_buf],eax
  4.  
  5.         ; Получить информацию о кучах текущего процесса
  6.         invoke  GetCurrentProcessId
  7.         invoke  RtlQueryProcessDebugInformation,eax,\
  8.                 PDI_HEAPS+PDI_HEAP_BLOCKS,[debug_buf]
  9.         mov     eax,[debug_buf]
  10.         ; Указатель на информацию о кучах
  11.         mov     eax,[eax+DEBUG_BUFFER.HeapInformation]
  12.         ; Количество записей
  13.         mov     ecx,[eax]
  14.         ; Пропустить заголовок
  15.         add     eax,4
  16. .loc_heap_scan:
  17.         or      ecx,ecx
  18.         jz      .loc_heap_done
  19.  
  20.         ; Это наша куча?
  21.         mov     edx,[eax+DEBUG_HEAP_INFORMATION.Base]
  22.         cmp     edx,[hHeap]
  23.         jne     .loc_heap_next
  24.  
  25.         ...
  26.         ; В структуре DEBUG_HEAP_INFORMATION информация о куче
  27.         ...
  28.  
  29.         jmp     .loc_heap_done
  30.  
  31. .loc_heap_next:
  32.         add     eax,sizeof.DEBUG_HEAP_INFORMATION
  33.         dec     ecx
  34.         jmp     .loc_heap_scan
  35.  
  36. .loc_heap_done:
  37.         ; Прибраться за собой
  38.         invoke  RtlDestroyQueryDebugBuffer,[debug_buf]
Нужный объект кучи найден. Теперь давайте повнимательнее посмотрим на содержимое других полей структуры DEBUG_HEAP_INFORMATION. Запрошенный размер памяти Allocated - суммарный объем всех блоков, выделенных с помощью функции HeapAlloc. Committed - фактически выделенный размер памяти. Максимальный размер кучи Blocks - параметр dwMaximumSize, указанный при вызове функции HeapCreate и выровненный до размера страницы памяти. Размер страницы можно получить при помощи функции GetSystemInfo. BlockCount - количество выделенных блоков памяти в куче, оно может отличаться от количества вызовов функции HeapAlloc, так как содержит еще и служебные блоки. Также важно понимать, что из-за сегментации кучи размер блока, который можно разово выделить в ней, не обязательно равен разнице между значениями Blocks и Allocated. Для получения максимального размера непрерывного блока памяти надо воспользоваться функцией HeapCompact. В случае фрагментированной кучи эта функция вернет размер наибольшего свободного участка.

Читать статью целиком »
Просмотров: 1102 | Комментариев: 0

01 ... 08 09 10 11 12 13 14 ... 70
Наверх
Powered by PCL's Speckled Band Engine 0.2 RC3
© ManHunter / PCL, 2008-2024
При использовании материалов ссылка на сайт обязательна
Время генерации: 0.1 сек. / MySQL: 3 (0.0172 сек.) / Память: 4.5 Mb
Наверх