краткое описание акб: акб собран на DS2438 Smart Battery Monitor и DS2433 4k-Bit EEPROM. в EEPROM таблица векторов, её размер по адресу 41h, начало 42h, количество векторов зависит от типа акб, их 13-17, неиспользуемые заполняются FFh. все поля данных начинаются с длинны и заканчиваются контрольной суммой, кроме четвёртого, в нём кс нет. второе поле начинается с двух волшебных байт, они с переворотом записаны в пользовательскую область DS2438. в первом поле ещё один волшебный байт, все три этих волшебных байта жёстко привязаны к серийному номеру DS2433 и из них-как то получается серийный номер акб. фирменное по для этих акб IMPRES Battery Data Reader Software, в нём есть все эти алгоритмы. адреса серийника, модели и химии 597E38, 597E3С и 597E4С, но вот как они туда попадают у меня найти не получилось.
Поле серийника 1032, химия 1044, модель 1035. Остается поставить пару бряков на GetDlgItem и SetWindowsTextW. Скорей всего шлет драйверу запросы TMTouchByte и TMTouchBit, либо ReadCOM и WriteCOM, возможно это даже голый обмен с устройством (учитывая куцость драйвера). Правда это почти наверняка никак не поможет с поиском идентов в еепроме, потому что это всего лишь интерфейс устройства и искать надо в прошивке.
Приветствую, спасибо за быстрый ответ! Модель это самое простое, она в ascii в открытом виде в 0fh поле данных eeprom, с химией тоже особых проблем возникнуть не должно, либо дамп с акб найдётся или я просто найду перебором, эмулятор обоих чипов у меня есть. >Поле серийника 1032 я знаю, вот код вывода на экран, туда он переписывается из 597E38h, вопрос немного в другом, как найти куда читаются сырые данные или наоборот откуда взялись готовые. .text:00404985 mov edi, [ebp+hWnd] .text:00404988 mov esi, ecx .text:0040498A lea eax, [esi+1A68h] ; указатель на буфер с серийником для вывода на экран .text:00404990 push eax ; int .text:00404991 push 408h ; int .text:00404996 push edi ; CDataExchange * .text:00404997 call ?DDX_Text@@YGXPAVCData......
Разные есть способы. Тебе повезло, что указатель формируется из базового адреса и достаточно большого смещения в какой-то структуре, можно просто найти все константы 0x1A68 и расставить там бряки.
это ничего не даст, я и так знаю как серийник попадает в буфер для вывода на экран .text:004056E1 push offset dword_597E38 ; буфер с серийником .text:004056E6 lea ecx, [edi+1A68h]; указатель на буфер с серийником для вывода на экран .text:004056EC call sub_402060 upd: я не нахожу кода который бы что то складывал в 597E38, или это делается нетривиально
Ну если уверен, что ничего не даст, наверное хорошо в этом разбираешься. Из инструментария у тебя есть бряки на память/хардварные на обращение к ней, просмотр листинга задом наперед (на предмет откуда берется базовый адрес) и следуя адресами возврата в предыдущую процедуру, перезапуская программу и наблюдая в какой момент в структуре появились эти данные. И наконец можно найти решение творчески, например в интерфейсных библиотеках в папке с программой есть отладочные сообщения, все они обычно передаются одной процедуре, поставив бряк в которую (условный/со счетчиком) можно поймать вывод нужного и проследить как данные, которые процедура вернула, обрабатываются.
творчески... да, программа умеет скидывать сырые данные данные в текстовый файл, можно попробовать поскать откуда она их берёт. спасибо за идею))
Вам нужно это из программы получить или непосредственно в железке где они лежат? https://www.chipfind.ru/datasheet/html/dallas/ds2438.html вот не это ли Вам нужно (64-BIT LASERED ROM)?
получилось найти сырые данные, программа выгребает 1, 2 и 3 байты серийника DSки... нужен совет по IDA, есть ли какой-то способ сопоставить абсолютные и относительные адреса? добавить каменты например, или как вы это вообще делаете? само собой хорошо бы автоматический поиск, а то вот такие вещи невероятно затрудняют поиски и находятся интуитивно .text:00411897 mov eax, [edi+46Ch] ; указатель на адрес с серийником DS .text:0041189D mov cl, [eax+1] .text:004118A0 mov dl, cl .text:004118A2 and dl, 0Fh .text:004118A5 mov byte_597D25, dl .text:00416BEC mov eax, dword_59829C ; указатель на адрес с серийником DS .text:00416BF1 mov cl, [eax+1] .text:00416BF4 mov dl, cl .text:00416BF6 and dl, 0Fh .text:00416BF9 mov byte_597D25, dl
Edi это первый аргумент процедуры, в 3 из 4 ее вызовов это один и тот же абсолютный адрес. Строго оно при статическом анализе не сопоставляется. Ручками конечно можно для удобства объявить, но не припомню чтобы в иде был солвер и она такое умела. Гидра может:
