Windows Параметр REG_BINARY

Кирилл

Команда форума
Администратор
Ассоциация VN
Сообщения
14,354
Реакции
6,331
Параметр REG_BINARY

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

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

Разберем.

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

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

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

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

i_005.png
e853ab31e7c1.png


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

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

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



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

Как я и говорил ранее нам понадобится таблица из этой темы
Пробуем ввести следующий код в центральной части :
Код:
53 61 66 65 5a 6f 6e 65
В правой части увидим SafeZone .
Обратите внимание что окончание строки тут не подписывается значением null 00,00
parametr.png

Если произвести экспорт в 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
rf.png
И получаем нужное значение.

Вот и все.
 
Последнее редактирование:

safer

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

Вложения

  • хоннекайт- книга.png
    хоннекайт- книга.png
    16.4 KB · Просмотры: 115
  • регбин .png
    регбин .png
    30.8 KB · Просмотры: 120
Последнее редактирование:

safer

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

Кирилл

Команда форума
Администратор
Ассоциация VN
Сообщения
14,354
Реакции
6,331
Как ни странно,но на самом деле такой формат позволяет читать системе его гораздо быстрее,чем привычный глазу пользователя.
 

safer

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

Кирилл

Команда форума
Администратор
Ассоциация VN
Сообщения
14,354
Реакции
6,331
что неплохо бы иметь пример реального раскодированного рег бин.
Реальная декодировка и кодировка указаны в первом сообщении.
Так же следует учитывать тот факт,что декодировка может производиться как с лева направо,так и справа налево - в зависимости от типа банарника.
Так же данные примеры вовсе не означают того,что расшифрованные данные будут удобочитаемы и понятны пользователю.
Или вообще может быть другой принцип кодировки.
 

Dragokas

Angry & Scary Developer
Команда форума
Супер-Модератор
Разработчик
Клуб переводчиков
Сообщения
6,951
Реакции
6,375
safer, что-то намешали всего в кучу. А реального вопроса нет.

Начнём с того, что чистка реестра не обсуждается в этой теме. Вы можете получить ответы, почитав эту тему: http://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 битные варианты.
Вообще непонятно, о чём речь.
 
Последнее редактирование:

Кирилл

Команда форума
Администратор
Ассоциация VN
Сообщения
14,354
Реакции
6,331
Dragokas,ага,где то намесил.
Найду где сохранил исходники разберусь,похоже должно было быть две темы.
Статью поправлю.
 

safer

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

Вложения

  • 142.png
    142.png
    20.9 KB · Просмотры: 97
  • 142.png
    142.png
    20.9 KB · Просмотры: 89

Dragokas

Angry & Scary Developer
Команда форума
Супер-Модератор
Разработчик
Клуб переводчиков
Сообщения
6,951
Реакции
6,375

«G~Lí†çh»

Новый пользователь
Сообщения
7
Реакции
6
и вот увидел-вес некоторых рег бин =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)
 
Последнее редактирование:
Сверху Снизу