Windows Параметр REG_BINARY

[Кирилл]

Параметр REG_BINARY​

Из базы знаний Microsoft:

Необработанные двоичные данные.
Большинство сведений об аппаратных компонентах хранится в виде двоичных данных и выводится в редакторе реестра в шестнадцатеричном формате.

Очень много информации содержится именно в параметрах типа REG_BINARY.

Разберем.

Первое что нам нужно запомнить- параметр типа REG_BINARY содержит двоичные данные в шестнадцатиричном формате.

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

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

• Двоичная система счисления — Википедия
• <= КОНСУЛЬТАНТ => Электронный справочник по ИНФОРМАТИКЕ (Автор Панов В.А.)

Рассмотрим содержимое такого REG_BINARY:

Спойлер

В поле Параметр данного окна отображается наименование редактируемого параметра, а в поле Значение с клавиатуры вводится нужное значение.

Тут надо учитывать что в центральной части поля Значение отображается редактируемый байт в шестнадцатиричном виде, а справа от него – уже читабельный вариант,символы появляются по мере ввода соответственно каждому введенному биту в центральной части.
В режиме редактирования двоичного параметра реализована возможность ввода информации как в двоичной, так и в шестнадцатеричной форме (поразрядно).
Нажатием кнопки OK параметру REG_BINARY присваивается введенное значение.

Видимые в центральной части 8 значений-это байты в шестнадцатиричном значении.
Как мы помним из курса по двоичным данным - один символ это один байт.
Один байт - это 8 бит.
8 бит= октет ,полный байт.



Давайте попробуем создать параметр REG_BINARY и вписать туда значение SafeZone .

Как я и говорил ранее нам понадобится таблица из этой темы
Пробуем ввести следующий код в центральной части :

53 61 66 65 5a 6f 6e 65

В правой части увидим SafeZone .
Обратите внимание что окончание строки тут не подписывается значением null 00,00


Если произвести экспорт в reg-файл,значение будет отображаться аналогично,но через запятые:

Windows Registry Editor Version 5.00


[HKEY_CLASSES_ROOT\razdel]
"Tect"=hex:53,61,66,65,5a,6f,6e,65,53,61,66,65,5a,6f,6e,65

Эксперимента ради можно перевести значение в двоичную форму-так как ее видит комп.
Воспользуемся калькулятором:
(вид-программист)

53     61     66      65
101011 110001 110110 110101

Это четыре буквы Safe.
Что бы вычислить ставим флажок на Hex а затем вводим код символа и жмем Bin

И получаем нужное значение.

Вот и все.

 

[machito]

Интересная тема, спасибо Кирилл.

 

[regist]

Для большего удобства этих преобразований можно использовать утилиту OTConvertIt. Вот для примера

 

[safer]

Очень много информации содержится именно в параметрах типа REG_BINARY.

ну хоть бы намек на реальный пример такой информации.
есть книга, где автор \см файл\ много и подробно пишет о реестре и о reg bin. и тоже без хоть маленького примера.
а между тем, как показало мое небольшое исследование, рег бин может иметь просто колоссальный вес\объем\: я ставил RED BUTTON- редактор реестра. но не понравился и удалил. чистил реестр прогой RegScanner. конечно, сначала посмотрел что на удаление.
чем замечательна эта простенькая программа?-указывает вес значений ключей !
и вот увидел-вес некоторых рег бин =58 кб! причем, как обычно, значения часто повторяются в другом разделе. те уже 100 кб! и это для одного рег бин.
конечно, не все рег бин в программе так тяжелы и может не во всякой программе так.
теперь понятно необходимость чистки реестра после удаления. иначе реестр пухнет.
конечно, в нужных прогах такие рег бины не выкинешь.
однако что такое там содержится? ведь 58 кб\ я перенес в блокнот\ это около 40 страниц текста.
уберем половину на кодировку-все равно немало.
что это может быть? вся документация для пользователя открыта свободно. что еще нужно кодировать так много?
раскодировать вручную такие объемы немыслимо. впрочем-может и не надо.

 

[Кирилл]

safer, вы можете ваш вопрос сформулировать поточнее?
На данный момент это похоже на мысли вслух

 

[safer]

да - это мысли вслух. поделился тем, что накопал. мне кажется вес рег бин в 58 кб вряд ли кто из обычных юзеров ожидал. хотя об этом они просто не думают.
относительно уточнения вопроса: я уже написал-хоть бы небольшой реальный пример содержимого рег бин.
или общее объяснение-какого типа \ инструкция или типа ini-файла и тд\ это содержание бывает.
я понимаю-этот вопрос очень спец, узок. и он ничему и никому не нужен для пользы. у меня это чистый интерес.

 

[Кирилл]

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

 

[shestale]

А мне нравится этот Hex Editor(installable и portable).

 

[safer]

В начале моего поста я указал, что неплохо бы иметь пример реального раскодированного рег бин.
Или хотя типы текстов в рег бин: обычные тексты, программы и тд. не понятно-зачем кодировать текст, весом 58 кб. ведь в реестре по идее его создания должны быть очень краткие сведения о компе , прогах и тд, что мы и видим обычно.
Конечно, вряд ли обычному юзеру это надо - это мой личный интерес.
Я пытался работать с OTConvert утилитой для декодировки и начал с 58 кб текстом - не получилось пока.
Спасибо за наводку на HEX EDIT, попробую.

 

[Кирилл]

что неплохо бы иметь пример реального раскодированного рег бин.

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

 

[Dragokas]

safer, что-то намешали всего в кучу. А реального вопроса нет.

Начнём с того, что чистка реестра не обсуждается в этой теме. Вы можете получить ответы, почитав эту тему: https://safezone.cc/threads/chistka-reestra.23231/
Там же вы узнаете, почему не нужно бояться большого объема файлов реестра.

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

Параметр типа REG_BINARY используется для многих целей. Но зачастую, для записи информации, в содержимом которой могут быть служебные символы, например символы с кодами 0x00 - 0x31.
И ещё когда нужно записать большой объём данных. В этом случае можно конечно задать резонный вопрос, почему не воспользоваться типом REG_SZ. Дело в том, что REG_SZ обычно пишут в формате юникод, поэтому он будет занимимать в 2 раза больше места. Но дело больше в том, что с бинарными данными в программе проще работать. Обычно это кусок структурированной информации, где по определённому смещению находится то или иное поле с данными.
Чтобы понять, как именно система (или программа, создавшая этот параметр) интерпретирует его, нужно обратится к спецификации на данный конкретный параметр (если таковая существует).

Вот к примеру,
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-18 => SID
здесь дублируется в бинарном виде идентификатор безопасности пользователя. Никакого принципа кодирования нет. Просто строка записана в бинарном виде.

Из последнего, в чём я самостоятельно разбирался, например, политики IPSec:
HKLM\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ в этом из разделов есть параметр ipsecData.
По одному из смещений часть инфы кодируется примерно так:

                        '00,00,00,00,00,00,00,00 -> any IP
                        'xx,xx,xx,xx,ff,ff,ff,ff -> specified IP / subnet
                        '00,00,00,00,ff,ff,ff,ff + [0x6F] == 0 -> my IP
                        '00,00,00,00,ff,ff,ff,ff + [0x6F] == 0x81 -> DNS-servers
                        '00,00,00,00,ff,ff,ff,ff + [0x6F] == 0x82 -> WINS-servers
                        '00,00,00,00,ff,ff,ff,ff + [0x6F] == 0x83 -> DHCP-servers
                        '00,00,00,00,ff,ff,ff,ff + [0x6F] == 0x84 -> Gateway
                        '
                        '[0x4E] == 1 -> mirrored
                        '
                        '[0x66] -> port type
                        '[0x6A] -> port number (source)
                        '[0x6C] -> port number (destination)

и так далее... Каждый случай уникален.

Видимые в центральной части 8 значений-это биты.

Это неправда. Там указаны байты в 16-ричном виде. Сам же дальше пишешь, что:

Тут надо учитывать что в левой части поля Значение отображается номер редактируемого байта, а справа от него – восемь битов данного байта

при том что на картинке № байтов показаны 0, а во второй строке уже 8 и т.д. Эти значения также указаны в 16-чной СС.

Возможны еще 4 и 2 битные варианты.

Вообще непонятно, о чём речь.

 

[Кирилл]

Dragokas,ага,где то намесил.
Найду где сохранил исходники разберусь,похоже должно было быть две темы.
Статью поправлю.

 

[safer]

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

 

[Dragokas]

Regedit не предназначен для поиска параметров типа REG_BINARY.
Используйте более продвинутые альтернативы. См. в теме: Набор программ для работы с реестром

 

[«G~Lí†çh»]

и вот увидел-вес некоторых рег бин =58 кб! причем, как обычно, значения часто повторяются в другом разделе. те уже 100 кб! и это для одного рег бин.

Ох, попалось несколько REG_MULTI_SZ в [HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\CurrentLanguage]
Вот тут-то у меня бывало и по 12 МЕГАбайт! Без понятия из-за чего, там по нескольку сотен раз дублировалась одна и та же куча строк что вызывало ошибку при открытии системного монитора «Не удаётся загрузить счётчики»… Ручная правка этого параметра невозможна, удалить ключ тоже нельзя… Благо, именно для этого существует команда LODCTR /R, что помогло решить, но "осадочек остался" — файл куста-то так и остался чересчур разрежённым! Несколько программ, заявляющих возможность дефрагментации реестра, облажались: предлагают "освободить" максимум четверть мегабайта (будто бы вообще не в курсе о высвобожденом десятке мегабайт) — ещё больше укрепило недоверие к organizer / optimizer / cleaner — туфта конченая, абсолютно бесполезная… Уже даже такое безобидное название, как "organizer" вошло в "список" игнорируемых к ознакомлению программ…
Хотелось бы что-то наподобие NTREGOPT из пакета ERUNT, но только чтобы не настолько сильно "сжимало", чтоб стало ещё хуже — хоть какая-то разрежённость должна оставаться в определённых местах (а потом нахожу сообщения и о других недостатках)…
К слову, даже после LODCTR /R — количество данных остаётся "больше позволенного к просмотру" regedit`ом. так что, 64 кб — далеко не лимит…

Что касается REG_BINARY и системного монитора — HKLM\SYSTEM\CurrentControlSet\Control\WMI\Security хранит определённые параметры безопасности Trace Providers (Поставщиков отслеживания) в Data Collector Sets\Startup Event Trace Sessions || Группы сборщиков данных\Сеансы отслеживания событий запуска.
Именно тут мне впервые попался "пользователь" ЗАПИСЬ ОГРАНИЧЕНА… Тупо, что его можно удалить, но невозможно обратно добваить! Если это относится к самому журналу, то можно каким-то образом и через экспорт/импорт XML`ки (всего одна SDDL-строка, где можно подписать S-1-5-33).
В интернете уже давно выяснили, как его "распотрошить" PowerShell`ом:

$key = "hklm:\SYSTEM\CurrentControlSet\Control\WMI\Security"
$sd = (gp -Path $key)."нужный GUID, т.е. имя параметра"
$sddl = ([wmiclass]"Win32_SecurityDescriptorHelper").BinarySDToSDDL($sd).SDDL
$sddl

Причём нашлась эта "подсказка" для параметра AccessPermission у определённых подключей Classes\AppID (которые можно встретить в оснатке "Службы компонентов" … Настройка DCOM)

Есть ещё вроде REG_NONE, и вроде бы как некоторые ключи куста SECURITY || SAM имеют немного другую структуру, "неподвластную" wmiclass`у "Win32_SecurityDescriptorHelper" — secpol.msc немного иначе "потрошится", благо есть PolsEdit от Southsoftware (особенно полезен для home edition), но и он "не всё" может впихнуть (хоть и позволяет больше, чем родной secpol.msc)…
Ещё бы выяснить, где хранятся параметры безопасности остальных WinObj, и особенно интересно тех, что правились в TweakUI на WinXP (где даже была расшифровка S-1-5-32-549 и S-1-5-32-550, которых так же вручную добавить нельзя тем же TweakUI)