Да вот пытаюсь, сначала надо клиента уговорить.
Кстати кто нить знает, на самсунгах есть такой чип MCP79MX или парт номер, хочу у самсунга заказать.

... но денюжки на другой чипак не из своегож кармана.... прально?

_________________
Ремонт ноутбуков в Краснодаре. +7 961 5O8-57-55

можно сказать ,что из моего кармана,т.к как деньги то списываются из того что клиент платит,состветственно я меньше получаю.ну как то так.

Столкнулся с той-же проблемой ,перепробовал в биосе все варианты DEV ID. Биосы корректить умею.Вшивал видео из DELL с MCP79MXT,еще с какой-то хрени,где DEVID 086C (тоесть MXT).Все время ругается и дает то-же пресловутое сообщение. Может кто-то настолько крут ,что может отследить чтение этого и заменить переход на выдачу этого сообщения??

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

_________________
Ремонт ноутбуков в Краснодаре. +7 961 5O8-57-55

и резистора потом биосом читаются, след в биосе все равно есть

Добрый день.

Столкнулся с аналогичной проблемой и поборол её.

Сначала попытался поменять в видеобиосе DevID на все подряд из цитируемого сообщения, а также пробовал 0863 (как в Apple) , но ошибка всё равно вылетала:



В результате дизассемблил видеобиос - нашел место, где происходит проверка и отключил её.
Сам BIOS, с отключенной проверкой в приложении.
Видеобиос из этого биоса, по идее должен пойти к любой MCP79, так что можно его вытянуть и заменить в биосе и для других моделей на этом чипе.

Ну и естественно посмотрел, а какой же на**ен DevID у моего чипа
Оказалось, что он был "0860"... (скрин в приложении)

ЗЫ Если кому интересно, могу рассказать как делал эту "операцию".

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

Ну, поехали!

1) Нам нужен биос с аппарата, на котором мы получаем "DevID mis-match between VBIOS and GPU. System halt" :




2) Берем PhoenixTool имеющейся версии и скармливаем ему наш биос.
PhoenixTool обрабатывая биос, распаковывает все входящие в него модули, и складывает каждый из них в виде отдельного файла в папочку DUMP
там-же, где лежал исходный файл биоса:



3) Теперь среди всех этих файлов в папке DUMP нам нужно найти модуль видеобиоса. Обычно, видеобиос находиться в одном из модулей с названием OPROMxx:




4) Как узнать, что это именно видеобиос? Очень просто - нужно последовательно открывать модули OPROMxx с помошью HEX-редактора. Я использовал бесплатный HxD. Когда вы откроете видеобиос, то в самом начале файла должны увидеть описание видеочипа, который должен стоять в этом аппарате.
ВНИМАНИЕ! Некоторые аппараты имеют в составе биоса несколько различных модулей видеобиоса для поддержки различных видеочипов (например Samsung R70), поэтому будьте внимательны и проверяйте все OPROM'ы.



5) Итак, модуль видеобиоса мы нашли. Теперь можем посмотреть, а какой же DevID у нас прописан сейчас в видеобиосе в качестве правильного?
Как известно, в системе компьютера каждое устройство имеет свой ID, который состоит из двух частей: VEN (Vendor - Производитель) и DEV (Device - устройство). Убедиться в этом вы можете зайдя в Диспетчер устройств, выбрав например, видеокарту и перейти в Свойства устройства \ Сведения \ ИД оборудования. Тут мы увидим значения VEN и DEV – это идентификаторы, благодаря которым можно точно определить модель оборудования. Например:



Что это даёт нам? Ну например то, что код VEN для одного и того-же производителя всегда одинаковый. Например , как видно на картинке выше, для Nvidia этот код 10DE. А значит, если видеобиос проверяет, что в системе реально работает "правильный" видеочип, то где-то должен храниться DevID этого "правильного" чипа. Значит ищем в нашем видеобиосе значение 10DE, но, не забываем, что в биосе используется т.н. Big-endian порядок байтов (подробнее - в википедии) Это означает, что запись начинается со старшего и заканчивается младшим байтом а в нашем примере в видеобиосе искомая строка должна выглядеть как DE10:



Ага, ну вот и оно: DE 10 66 08 после приведения к обычному виду выглядит так: 10 DE 08 66 а это ни что иное, как DevID "правильного" видеочипа VEN_10DE&DEV_0866
Вот тут давайте сделаем паузу и уточним, что если вдруг, вы ТОЧНО знаете DevID чипа, который вы поставили, то строго говоря отключать проверку DevID вам и не нужно. Достаточно заменить его в видеобиосе на DevID установленного чипа и тогда при проверке система посчитает его правильным и дело в шляпе.
Обычно же проблема как раз и состоит в том, что х\з с каким DevID у вас чип, а запускать как-то надо.

[hr]

ВНИМАНИЕ! Сейчас я для общего развития и углубленного понимания проблемы попытаюсь объяснить как это работает вообще. Повторять эти операции не нужно. О том как по-быстрому отключить саму проверку я расскажу чуть ниже.

Итак, давайте-ка найдем в модуле видеобиоса нашу злополучную строку "DevID mis-match between VBIOS and GPU. System halt":



Ага, вот она. Теперь смотрим с какого адреса она начинается (значение смещения слева внизу) - с адреса B9E7. Теперь найдём в каком месте есть ссылка на этот адрес, но помним про Big-endian а значит ищем E7B9:



Нашли! Вот то место где ссылаются на адрес нашей строки с ошибкой. Запоминаем адрес этого места - D5C5
А еще давайте запомним адрес, по которому у нас в видеобиосе находиться информация о правильном видеочипе:
как видно на шестой картинке адрес DevID у нас 19C.
Теперь открываем в IDA Pro наш модуль видеобиоса и переходим к адресу D5C5, а вернее чуть раньше его и пытамеся преобразовать это в команды:



Ну вот! То что искали:


To be continued...

Продолжаем.

Итак, дизассемблировав видеобиос, мы нашли то место, где происходит сравнение ID чипа реально установленного в системе и того, который в видеобиосе прописан как "правильный". Сама проверка состоит из двух строк.

Данная строка содержит команду CMP, которая производит сравнение двух операндов. Она сравнивает два значения и устанавливает флаг нуля Z (zeroflag) если они равны.


А в данной строке присутствует команда JZ, которая является командой условного перехода. Она "срабатывает" только в том случае, если установлен флаг Z, то-есть если сравниваемые на предыдущем шаге значения были равны.


Разобравшись с этим, становиться очевидным путь отключения этой проверки - нужно заменить команду условного перехода, например на команду безусловного перехода jmp - тогда вне зависимости от результатов сравнения мы прыгнем куда надо, а не туда где нам выдадут ошибку DevID.

Теперь переходим к практике и смотрим как это сделать на примере:

6) Я предполагаю, что алгоритм этой проверки в видеобиосах для чипов Nvidia одинаковый, а следовательно Вам не нужно дизассемблировать его, что бы разобраться, а достаточно найти характерные куски в HEX редакторе и исправить всего один байт. НО! Это лишь предположение, и тем, кто владеет IDA рекомендую всё перепроверить в ней.

Для этого нужно знать:

- адрес того места, где в биосе прописан DevID правильного чипа - в нашем случае этот адрес 19C;
- адрес того места, где начинается строка с ошибкой "DevID mis-match between VBIOS and GPU. System halt" - в примере это B9E7;
- адрес того места, где ссылаются на адрес строки с ошибкой - в нашем примере это D5C5;

Итак, переходим по последнему из указанных выше адресов - D5C5. Это как раз то место, в районе которого и происходит проверка:



Как видно из сравнения HEX и ассемблера, команда условного перехода JZ (её код операции равен 74) находиться сразу же после ссылки на адрес того места, где в видеобиосе прописан DevID правильного чипа (в нашем случае этот адрес 19C а учитывая Big-endian это 9С 01).

Всё что Вам нужно - это найти это место и заменить следующую за ним команду JZ (код операции 74) на JMP (её код операции равен EB):



Сохраняем получившийся файл и считаем что 90% дела сделано!
Вам проверять не обязательно, а я для демонстрации проверю в IDA, что у нас получилось:



Как видим - всё в порядке. Теперь у нас вместо условного перехода (JZ) в видеобиосе прописан безусловный (JMP), который сработает вне зависимости от того, совпадет ли ID чипа с тем, который должен быть.

7) Казалось бы, всё? Можно сворачиваться и шить биос в аппарт? Нет, не спешите. Есть ещё несколько обязательных действий, без которых наш биос не соберется или не заработает.
Первый из шагов - это корректировка контрольной суммы модуля видеобиоса. Зачем это? Всё просто - когда ноутбук включается, он распаковывает сжатые модули биоса из флеш-памяти в свою оперативную память - практически так же как PhoenixTool распаковывает их в папочку DUMP.
При этом, происходит проверка того, что модули не повреждены и распаковались нормально. Как это делается? Сверяется контрольная сумма модуля, рассчитанная при распаковке и та, которая прописана в самом модуле как правильная. Так как мы изменили содержание нашего файла видеобиоса, то и его контрольная сумма, естественно, изменилась. Значит нужно скорректировать и ту, которая прописана в нем как правильная!

Вот тут я снова сделаю отступление: наверняка существует более простой/правильный/логичный/технологичный метод расчёта контрольной суммы модуля, но я отталкивался от того, что было под рукой. Если Вы знаете метод лучше моего, пожалуйста, отпишитесь. Буду очень благодарен!

Итак, берем то, что есть под рукой, а есть у нас программка NiBiTor, которую обычно используют для тюнинга биоса десктопных видеокарт Nvidia.
Она, конечно же не знает такого видеочипа как наш, но честно выводит его DevID и, что самое главное, рассчитывает и выводит реальную контрольную сумму модуля, а также ту, которая указана в самом модуле. Нам остается лишь заменить самый последний байт в нашем модуле на тот, который указан в NiBiTor как Calculated cheksum - у нас это 58:




8) Вот теперь наш модуль видеобиоса готов! Нужно его "имплантировать" в биос. Делаем это так - в программе PhoenixTool, после того как она разобрала наш оригинальный биос в папку DUMP, в разделе Advanced устанавливаем чекбокс "Allow user to modify other modules" и "No SLIC" и нажимаем Done.
Далее нажимаем Go и не закрывая окно с информацией, копируем наш отредактированный видеобиос в папку DUMP, и только потом нажимаем OK - при этом происходит сборка видеобиоса с нашим отредактированным модулем:



Вот теперь всё! Наш биос, с отключенной проверкой видеокарты готов - можно шить его на программаторе. Он называется dump_bios_SLIC.bin и лежит там же, где и оригинальный файл биоса.

Успеха!

Спасибо,занялся по окончании процесса отпишусь .

Vadimi4
Статья супер! Все доступно.
Использую эту методику можно и WhiteList HP и IBM обходить, как я понимаю.

Появилось несколько вопросов, да и я кое-что вспомнил, так что давайте поговорим:

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

Если не заработает, то придется ковыряться с IDA. Как это сделать я расскажу чуть ниже.


Сергей, спасибо! Да - примерно таким образом исправляют и whitelist в биосах, но в тех нескольких статьях, которые я читал на хабре по этому поводу (один товарищ корректировал whitelist в HP а другой в Lenovo - неплохие, кстати, статейки) я увидел пару важных отличий от описанной мной корректировки видеобиоса: во-первых в статьях говорилось, что проверка whitelist устроена несколько хитрее и на самом деле там не одна проверка а две или три, а во-вторых авторы ни разу не упоминали о корректировке контрольной суммы, отредактированного ими модуля.
Почему у них работало без корректировки контролной суммы - не знаю. Может в модуле с whitelist её вообще нет...

Теперь опишу пару моментов, которые я не осветил в предыдущих сообщениях.

1) Во время своих продолжительных экспериментов с видеобиосом и его интеграцией в биос, сталкивался со следующей ошибкой в phoenixtool:

Changes detected in OPROM00.ROM
New OPROM00.ROM Module is 4 bytes too big
New OPROM00.ROM Module is 4 bytes too big
OPROM00.ROM not reintegrated
Unable to reintegrate OPROM00.ROM

Что сие означает? Это означает, что phoenixtool не умеет интегрировать в биос модуль, который больше чем оригинальный модуль. Вроде бы глупость - мы же размер файла не трогали, а просто поменяли значения двух байт. Но дело тут вот в чем - модули в биосе хранятся в запакованном (сжатом) виде. И наши манипуляции повлияли на то, что модуль не получается сжать до его оригинального размера!

Что делаем? Для начала думаем: как работает простейший алгоритм сжатия? Он заменяет цепочку последовательных одинаковых блоков на один такой блок и указатель количества его повторов. То-есть, если мы имеем строку KKKLLLL то, после сжатия простейшим алгоритмом, получим 3K4L .

Значит пробуем поменять что-нибудь в видеобиосе так, что-бы получилась несколько последовательных одинаковых символов, причем не важно каких именно. Но что можно безболезненно поменять, ведь там же всякие команды, которые явно не стоит трогать? Тогда давайте поменяем что-нибудь в текстовых строках! А именно в той, которая, как мы надеемся, скоро станет совершенно бесполезной :



Готово! Не забываем снова откорректировать контрольную сумму и пробуем интегрировать полученный модуль в Phoenixtool.
У меня, после этих манипуляций, ошибка больше не вылетала.

2) Я показал в предыдущем сообщении скрин IDA, но ничего не рассказал, как Вам получить такое-же. Исправляюсь! Но прежде, должен уточнить, что до данного случая с видеобиосом, я IDA в глаза не видел и никогда в ней не работал. Так что я могу лишь показать как делал я, но наверняка спецы по этой программе смогут рассказать о более простых и правильных путях получения того-же результата.

Итак, запускаем IDA, открываем наш модуль видеобиоса и получаем окно, с параметрами загрузки нашего модуля. В данном окне, нам нужно выбрать тип процессора, для которого написан наш модуль. Очевидно, что у нас это x86, причем какой именно - не особо важно. Но давайте выберем самый современный из доступных:



Затем мы получаем вопрос от программы, в каком режиме битности мы хотим дизассемблировать наш модуль, в 16-бит или 32-бит?
Тут мы должны вспомнить, что обычный PC-BIOS имеет ряд ограничений (16-битный исполняемый код, адресуемая память 1 Мбайт, аппаратные ограничения IBM PC/AT и т. д.), а значит ваш самый современный 64-разрядный процессор на этапе загрузки биоса работает в 16-разрядном режиме . Кстати обход этих ограничений, пожалуй, и есть самое большое новшество в UEFI.

Итак, нам нужно дизассемблировать в 16-битном режиме, а значит нажимаем в окошке кнопку No.



Ну вот, мы загрузили модуль. Что теперь? А теперь нам нужно перейти к тому месту, где происходит наша проверка (в моём примере - это D5C5) и скомандовать ИДе, что-бы она попробовала преобразовать машинные коды в понятный ассемблерный код. Делается это так - становимся курсором на нужной нам строке и нажимаем клавишу C на клавиатуре (или через меню - Edit -> Code):



Какие могут быть грабли? Ну, например, вы могли выбрать не ту строку, с которой скомандовали начать преобразовывать код и на выходе у вас будет какая-то фигня. В нашем случае, если стать прямо на строку по адресу D5C5 и нажать С, то мы получим ерунду, так как по этому адресу у нас записан аргумент (адрес) для операции mov, а мы заставили ИДу попытаться преобразовать его в инструкцию.


Что делать? Нажать кнопочку U, для того, что-бы все вернуть назад и сместившись на одну или несколько строк вверх/вниз попробовать снова преобразовать в код. Таким образом "прощупываем" интересующий нас кусок и находим наш алгоритм проверки. В нашем примере, начало этой проверки находилось на 17 байт раньше (D5B4) чем ссылка на строку с ошибкой (D5C5).

Вроде-бы всё рассказал из того, что знал.
Будут вопросы - welcome в личку или сюда - постараюсь помочь.

Успехов!

Столкнулся с такой ситуацией после замены MCP75l-b3(брал на PartsDirect) на Asuse k50ip - ошибка DevID.
Нашел на форуме ветку с последним сообщением от Vadimi4 о том что по просьбе он раскажет таинство как отключить проверку DevID...
После просьбы описать все манипуляции таинства,а у Vadima это получилось очень наглядно...За что отдельное спасибо..
Сделал Все по аналогии...
Единственная разница в распаковке,я распаковывал bios прогой amitool),почему понимаите..
Поразбиравшись с IdaPro с пару часиков)для собственного просвещения) нашел злополучное значение условного перехода (JZ) в видеобиосе и прописал безусловный (JMP),тоесть исправил код операции с 74 на EB..


После диссембла у меня получлось вот что:
- адрес того места, где в биосе прописан DevID правильного чипа - в нашем общем случае это тот же адрес 19C;

- адрес того места, где начинается строка с ошибкой "DevID mis-match between VBIOS and GPU. System halt" - в моем это B7B3;

- адрес того места, где ссылаются на адрес строки с ошибкой - в моем это D376;

а адрес строки с которой начинается злополучная команда это D354,чуть выше как и писал vadi4

Откорректировал контрольную сумму тем же NiBiTor.
Вся загвоздка встала в сборке дампа Amitool...
Что и где нужно в ней выставить чтобы правильно собрать дамп с измененным файлом видеобиоса?

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

Ошибка "DevID mis-match between VBIOS and GPU. System halt" на аппарате Asus k50ip после замены MCP75L-B3 на новый, решена путем дизассембла видеобиоса - нашел место, где происходит сверка ID чипа и ID прописанного в биосе и отключил её.
Готовый биос с отключенной проверкой прикрепил, думаю что пригодится)

Спасибо Vadimi4
за полное решение
перенес в проф ветку

_________________
ремонт ноутбуков, планшетов в Одессе
продажа паяльных станций Термопро ик-650
и расходных материалов для пайки и ремонта

Чем собрали биос?

Собрал AMITOOL

Огромное спасибо за выложенный биос! Подтверждаю, все заработало!!!

А как откорректировать контрольную сумму в ATIшных модулях?

Спасибо Вам Огромное! такой же ноутбук и та же проблема - прошил всё завелось!

Просто - там 8 bit checksum . Большая часть модульменятельных софтов это делает самостоятельно.
Вот если оно защищено сертификатом, как на некоторых топовых десктопных видяхах. Тогда никак.

_________________
Хочешь получить правильный ответ - задай правильный вопрос.
Если проблема уникальна , кроме того у кого она на руках, её никто не решит. Для всех остальных проблем - есть Гугл.