К сожалению не могу уверенно привязать появление нового функционала DISM к конкретному номеру билда,
но обнаружил я эти изменения в среде 16188: VEfremov несомненно сразу оценит НОВУЮ ВОЗМОЖНОСТЬ СОЗДАВАТЬ бэкап ПОЛНОГО диска с помощью DISM. В принципе для тех, кто на диске создает лишь один раздел, FFu-команды не нужны, но вот тем, у кого физический диск или SSD нарезан на несколько разделов, этот функционал несомненно очень пригодится. И еще куча опций, которые я как минимум НЕ ЗАМЕЧАЛ раньше, так что извините, если эти опции была и до появления RS3: Поскольку я люблю все документировать в логах, то опци /LogPath, /Format, мне также очень полезны. /English - Displays command line output in English.
Хоть я использую EN-US без локализации интерфейса, тем не менее даже мне эта опция полезна в случае, если вдруг придется на локализованной версии системы что-то делать. Особенно, если на китайской
Теперь о не очень приятном изменении в HKLM: все билды, начиная с 7600, а может и раньше и до появления RS3 всегда в ветке HKLM\SOFTWARE\Microsoft\Internet Explorer\Registration имелся бинарнное значение DigitalProductKey. После появления десятки именно это значение хранило оригинальный ключ активации Windows 7, 8, 8.1 в том случае, если ЛЕГАЛЬНАЯ, Retail/OEM система была обновлена одним из билдов десятки. Но начиная с 16170 ветка HKLM\SOFTWARE\Microsoft\Internet Explorer\Registration стала ПУСТОЙ и потому теперь ОТСУТСТВУЕТ возможность узнать какой же ключ имела система, которая была обновлена до десятки.
Но начиная с 16170 ветка HKLM\SOFTWARE\Microsoft\Internet Explorer\Registration стала ПУСТОЙ и потому теперь ОТСУТСТВУЕТ возможность узнать какой же ключ имела система, которая была обновлена до десятки.
А здесь? Компьютер\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
А здесь? Компьютер\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
Здесь для ОБНОВЛЕННОЙ системы хранится ОБЩЕИЗВЕСТНЫЙ ключ, одинаковый для ВСЕХ в пределах ОДНОЙ РЕДАКЦИИ. Так что этот ключ - просто ЗАГЛУШКА, никому не интересная, начиная с 10240.
Здесь для ОБНОВЛЕННОЙ системы хранится ОБЩЕИЗВЕСТНЫЙ ключ, одинаковый для ВСЕХ в пределах ОДНОЙ РЕДАКЦИИ.
Я вас удивлю, но во всех ключах, которые я вам скинул - там, кстати, и ваш адресок присутствует, - везде одно и тоже бинарное выражение у параметра DigitalProductId.
Цитатаsysprg ()
Так что этот ключ - просто ЗАГЛУШКА, никому не интересная, начиная с 10240.
А это уже хрень полнейшая... Нет никакой заглушки и быть не может, - ключ на активацию цифры прилетает с сервера, а не в дистре хранится, иначе бы не менялся так с каждым новым обновлением, - я про МАКи сейчас.
А это уже хрень полнейшая... Нет никакой заглушки и быть не может, - ключ на активацию цифры прилетает с сервера
VK7JG-NPHTM-C97JM-9MPGT-3V66T - общеизвестный ключ для Про начиная с 10240, а в поле DigitalProductId хранятся одни и те же байты начиная с 10240 и по сегодняшний день. Более того, байты, конвертируемые в VK7JG-NPHTM-C97JM-9MPGT-3V66T хранятся еще нескольких местах ветки CurrentVersion. Поэтому я их и назвал заглушкой. До 10240, значение байтов, конвертируемых в ключ, время от времени МЕНЯЛИСЬ. У меня есть полная история изменений, начиная с 10079. P.S: а вот активация действительно прилетает с серверов, где хранится СЕРТИФИКАТ никоим образом не связанный с тем, что лежит в поле DigitalProductKey. P.S:
сравните значения подсвеченных байтов поля DigitalProductKey в CurrentVersion и в ЛЮБОЙ ветке hklm\System\Setup\Source OS(Updated... для того, чтобы убедиться в том, что начиная с 10240 значения этих байт ОДНО И ТО ЖЕ и потому и при конвертации получается один и то же ключ VK7JG-NPHTM-C97JM-9MPGT-3V66T
Более того, байты, конвертируемые в VK7JG-NPHTM-C97JM-9MPGT-3V66T хранятся еще нескольких местах ветки CurrentVersion. Поэтому я их и назвал заглушкой.
Ну почему тогда в прошках как минимум два ключа про умолчанию проскакивают? Один ритейл, и несколько волюмных? Не задавались таким вопросом? Ещё раз - в разделах HKLM\SOFTWARE\Microsoft\Internet Explorer\Registration HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion одни и те же данные всегда. Ну и до кучи...
задавался и потому, что САМ ПИСАЛ код извлечения ключа, то точно знаю, что одни и те же байты хранятся во всех полях DigitalProductKey в диапазоне x034-x042 ( 52-66 ), поскольку ПРОВЕРЯЛ и глазками и кодом P.S:
а вот ОФИСНЫЕ ПОЛЯ не надо сюда вмешивать, там и другие смещения и действительно есть зависимость от Retail/Volume и еще и от ИЗДАНИЯ Офис - только для 2003, 2007 поле DigitalProductKey содержит ключ активации, а начиная с 2010 там уже неизвестно что, не имеющее отношения к реальному ключу. Но это ОТДЕЛЬНАЯ ТЕМА.
задавался и потому, что САМ ПИСАЛ код извлечения ключа, то точно знаю
Вы только что тоже написали -
Цитатаsawq ()
HKLM\SOFTWARE\Microsoft\Internet Explorer\Registration стала ПУСТОЙ и потому теперь ОТСУТСТВУЕТ возможность узнать какой же ключ имела система, которая была обновлена до десятки.
Вы хоть пробегитесь по всем адресам или на мои картинки посмотрите...
Вы хоть пробегитесь по всем адресам или на мои картинки посмотрите
На Ваших картинках не видно для КАКИХ БИЛДОВ, я же сразу написал, что ПУСТОЙ ветка HKLM\SOFTWARE\Microsoft\Internet Explorer\Registration стала начиная с 16170, а еще в 15063 СОДЕРЖАЛА DigitalProductKey.
"Ещё раз - в разделах HKLM\SOFTWARE\Microsoft\Internet Explorer\Registration HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion одни и те же данные всегда." - у меня - НЕ ТАК, поскольку я ЛЕГАЛЬНУЮ, Retail 8.1 обновил с помощью 10079. Поэтому только для 10079 у меня значения в ветке HKLM\SOFTWARE\Microsoft\Internet Explorer\Registration и ветке hklm\System\Setup\Source OS(Updated.. для9600 - совпадали, а далее ВСЕГДА РАЗЛИЧАЮТСЯ. Но вот у тех, кто НЕ ОБНОВЛЯЛ семерку, восьмерку, а СРАЗУ ставил десяточный билд, будет ПОЛНОЕ СОВПАДЕНИЕ.
На Ваших картинках не видно для КАКИХ БИЛДОВ, я же сразу написал, что ПУСТОЙ ветка HKLM\SOFTWARE\Microsoft\Internet Explorer\Registration стала начиная с 16170, а еще в 15063 СОДЕРЖАЛА DigitalProductKey.
Да какая разница? Сути мной написанного это не меняет. И вот вам ещё картинка на это ваше утверждение -
Цитатаsysprg ()
VK7JG-NPHTM-C97JM-9MPGT-3V66T - общеизвестный ключ для Про начиная с 10240, а в поле DigitalProductId хранятся одни и те же байты начиная с 10240 и по сегодняшний день. Более того, байты, конвертируемые в VK7JG-NPHTM-C97JM-9MPGT-3V66T хранятся еще нескольких местах ветки CurrentVersion.
Два разных ключа. Ни о какой заглушке и речи быть не может. Не знаю и не понимаю, что и кому вы здесь пытаетесь доказать, но при желании всё предметно видно.
Два разных ключа. Ни о какой заглушке и речи быть не может.
Вы показали 15 нулей в полях 52-66, что означает что НЕТ КЛЮЧА. Так бывает, если у Вас VL, а не Retail. Я же пишу о том, что у тех, кто десятку поставил ОБНОВЛЕНИЕМ активированных Retail версий Windows 7, 8, 8.1, ключ HKLM\SOFTWARE\Microsoft\Internet Explorer\Registration в поле DigitalProductKey содержит ключ активации обновленной системы. В любом другом случае ( VL или даже, как мне подсказал DRINKO, Retail с ТЕЛЕФОННОЙ активацией ), сказанное выше не не актуально. Спорить нет смысла, посколькумоя система прошла 77 обновлений начиная с 9600->10079 и для всех этих билдов я могу извлечь значения ключей и полей DigitalProductKey и привести их сравнение.
Вот значимые для ключа байты от 9600 из hklm\System\Setup\Source OS... Bот аналогичные байты из HKLM\SOFTWARE\Microsoft\Internet Explorer\Registration для 10586, выгруженные в виде текстового файла:
Я же пишу о том, что у тех, кто десятку поставил ОБНОВЛЕНИЕМ активированных Retail версий Windows 7, 8, 8.1, ключ HKLM\SOFTWARE\Microsoft\Internet Explorer\Registration в поле DigitalProductKey содержит ключ активации обновленной системы.
Тогда строковый параметр должен иметь отличное от DigitalProductId имя. Не может один тот же параметр в разных разделах иметь разные бинарные значения.
Я допустил НЕ КОРРЕКТНОСТЬ в том, что написал "содержит ключ активации" - ПРАВИЛЬНО было бы СОДЕРЖИТ 15 БИНАРНЫХ байт, которые преобразуются в КЛЮЧ АКТИВАЦИИ. Вот ПРИМЕР преобразования, который я СЕГОДНЯ выполнил для своего брата, у которого начальная система была семерка:
$ie = @( 0x81, 0x9b, 0x0c, 0xb8, 0xbe, 0x23, 0x52, 0x3c, 0xb9, 0xb9, 0xd0, 0x86, 0x7a, 0x33, 0x03 ) > DecryptWindowsKey $ie xxxxx-xxxxx-xxxxx-BFRC8-GX8BC Брат сравнил с тем, что у него было записано и подтвердил полное совпадение. А выполнял преобразование я на основе выгруженной ветки HKLM\SOFTWARE\Microsoft\Internet Explorer\Registration из десятки билд 15063.
Вот, значение поля DigitalProductKey на основе которых я построил массив байт для вычисления ключа:
В связи с введением в действие Постановления Правительства Российской Федерации от 14.11.2023 № 1905 т.н. "о запрете популяризации VPN" с 1 марта 2024 года - любое обсуждение способов обхода блокировок и VPN на портале запрещено!
