Ниже — структурированное техническое описание (анатомия) всех способов проверки Android-телефона, которые фактически обсуждались и были проверены в этой сессии, с указанием стеков, режимов работы, ограничений, применимости для доказательной базы и вариантов расширения сторонними инструментами.
Это не «учебник», а отчёт об инженерном прогрессе сессии.

1. БАЗОВАЯ КЛАССИФИКАЦИЯ СПОСОБОВ ПРОВЕРКИ ANDROID

Все методы делятся по состоянию телефона и уровню доступа:

№	Состояние телефона	Root	Канал доступа
A	Включён	❌	ADB (USB debugging)
B	Включён	✅	ADB + su
C	Выключен	❌	BootROM / Preloader (MTK)
D	Выключен	❌	EDL (Qualcomm)
E	Выключен	❌	Fastboot
F	Любое	❌/✅	Пользовательские APK

В этой сессии фактически применим и корректен вариант A.
MTK-варианты (C) мы разобрали и признали непригодными для включённого телефона.

2. ОСНОВНОЙ РАБОЧИЙ СТЕК (ФИНАЛ СЕССИИ)

✅ СТЕК ДЛЯ ВКЛЮЧЁННОГО ANDROID БЕЗ ROOT


Windows PowerShell
└── adb.exe (фиксированный путь)
    └── ADB protocol
        ├── getprop
        ├── /proc/*
        ├── dumpsys
        ├── pm / settings
        └── sysfs (/sys)

Используемые подсистемы Android

Подсистема	Назначение
`getprop`	Идентификация сборки, SoC, бренда
`/proc/cpuinfo`	Реальный CPU (архитектура, ядра)
`/proc/meminfo`	Фактическая RAM
`/proc/version`	Ядро Linux
`dumpsys`	Аппаратные сервисы (battery, sensor, camera, telephony)
`pm list packages -f`	Предустановленные APK
`/sys/class/thermal`	Тепловые зоны
`df`	Реальный объём хранилища

Важно:
Этот стек НЕ читает ядро напрямую, но читает данные, которые ядро публикует пользователю — этого достаточно для доказательства фейка.

3. ЧТО ИМЕННО ПРОВЕРЯЕТСЯ ЭТИМ СТЕКОМ

3.1. Аппаратная идентичность (ключевая часть)

CPU / SoC

/proc/cpuinfo
ro.board.platform
ro.hardware
ro.soc.*

Цель:
Обнаружить несоответствия вида:

MT6580 ↔ «Snapdragon 8 Gen 3»
ARMv7 ↔ заявленный ARMv9
4 ядра ↔ заявленные 8–12

Это юридически значимое доказательство.

RAM

/proc/meminfo
MemTotal

Позволяет доказать:

заявлено 12 GB → фактически 2 GB
эмуляция RAM на уровне build.prop

Накопитель

df /data
df /system
df /sdcard

Позволяет выявить:

«1 TB» → реально 32–64 GB
подмену размера через framework

3.2. Система и ядро

Источник	Что даёт
`uname -a`	Архитектура и версия ядра
`/proc/version`	Кто и чем собирал
`ro.build.tags`	`release-keys` vs `dev-keys`
Security Patch	Дата патча безопасности

Флаг фейка:

Android 13 + patch 2023 + kernel 3.x
dev-keys на «коммерческом» устройстве

3.3. Радиомодуль и идентификаторы

IMEI (через service call)
Serial
Android ID
MAC Wi-Fi / BT

Используется для:

отчёта
сопоставления с коробкой / продавцом
фиксации в видео

3.4. Предустановленные и подозрительные APK

Метод:


pm list packages -f

Фильтрация по ключевым словам:

factory / aging / engineering
mtk / demo
adups / fota
spy / miner / backdoor

Почему это важно:

фабричные тестовые пакеты ≠ пользовательское устройство
adware/spyware → нарушение правил торговли

4. ВИЗУАЛИЗАЦИЯ (ДЛЯ ВИДЕО И ОТЧЁТА)

4.1. CLI (Command Line)

Используется:

Write-Host -ForegroundColor
строгий лог в .txt

Цель:
Видео, где видно:

команды
реальные значения
невозможность «подделать на лету»

4.2. HTML-отчёт (offline)

Используем:

PowerShell + here-string
HTML + CSS
HtmlEncode для безопасности

Почему HTML допустим для защиты потребителей:

неизменяем
читаем
прикладывается как файл

5. MTKCLIENT / MTK.PY — ПОЧЕМУ ОТКАЗАЛИСЬ

Что это такое

mtkclient работает через:

BootROM
Preloader
DA (Download Agent)

Ограничения

Фактор	Реальность
Телефон включён	❌ не работает
Требуется выключение	✅
Пользовательские данные	❌
Подходит для отчёта	❌ (не consumer-friendly)

Вывод:
MTK-инструменты — это forensics / unbrick, а не проверка включённого устройства.

6. СТОРОННИЕ ПРИЛОЖЕНИЯ / БИБЛИОТЕКИ (ТЕОРЕТИЧЕСКИ)

6.1. Пользовательские APK

Инструмент	Проблема
CPU-Z	Не юридически значим
Device Info HW	Зависит от API
AIDA64	Коммерческий

Можно использовать только как дополнительный визуальный слой, не как доказательство.

6.2. Python + ADB

Возможен стек:


Python
└── adbutils / pure-python-adb

Минусы:

меньше контроля
сложнее для видео
всё равно упирается в ADB

7. ЮРИДИЧЕСКАЯ ЦЕННОСТЬ СТЕКА

Наиболее сильные доказательства:

/proc/cpuinfo
/proc/meminfo
df
несоответствие SoC ↔ модель
dev-keys
factory / engineering APK

Именно этот набор принимается:

маркетплейсами
consumer protection
платёжными спорами

8. ИТОГОВАЯ КАРТА ПРОГРЕССА СЕССИИ


❌ MTK выключенный телефон
❌ динамический поиск adb
❌ парсинг через regex

✅ фиксированный adb
✅ ADB device detection (правильный)
✅ /proc + dumpsys
✅ CLI + HTML
✅ отчёт + видео

Финальный вывод

Как прийти к правильному инженерному стеку.
Проблемы были не концептуальные, а реализационные (PowerShell + ADB detection).

Если хочешь, следующим шагом я могу:

структурировать текст официальной жалобы на основе этих данных,
или дать чеклист “что именно снимать на видео”,
или подготовить короткое техническое резюме на 1 страницу для Alibaba / китайской защиты потребителей.

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

Анатомия одной проверки и сам скрипт в свободном доступе

Как проверяли Android-устройство и почему путь оказался важнее результата

Введение

Проверка подлинности современного Android-смартфона на первый взгляд кажется тривиальной задачей. Достаточно открыть «О телефоне», посмотреть модель, объём памяти и версию Android. Однако именно с этого наивного уровня и начинается большинство ошибок. Производители фейковых устройств давно научились подменять пользовательские данные, маскировать сборки и эмулировать характеристики.

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

Этап I. Иллюзия простоты и первые ошибки

Первые шаги выглядели логично:
ADB, PowerShell, автоматические скрипты, попытка собрать «паспорт устройства» в одном запуске.

Однако почти сразу проявились системные проблемы:

нестабильное обнаружение устройства,
конфликты версий adb server,
динамический поиск adb.exe,
попытки писать универсальные скрипты «на все случаи».

Главная ошибка этого этапа — переоценка автоматизации и недооценка среды выполнения. Скрипты ломались не потому, что идея была неверной, а потому что:

ADB — это не библиотека, а протокол с состоянием.

Пока это не было осознано, любые улучшения оставались косметическими.

Этап II. Попытка уйти «глубже»: MTK и BootROM

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

Так в поле зрения попали инструменты MTK:

mtkclient
mtk.py
BootROM / Preloader

Теоретически — мощнейший уровень доступа: память, eFuse, GPT, флеш.

Практически — фундаментальное противоречие:

MTK-инструменты работают только с выключенным телефоном.

Это сразу делало их:

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

Этот этап был важен не результатом, а выводом:
не каждый “более глубокий” метод лучше.

Этап III. Осознание ключевого условия: телефон должен быть включён

Критический перелом произошёл в момент явной формулировки требования:

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

Это автоматически отсекло:

MTK BootROM
EDL
fastboot-дампы
кастомные recovery

И сузило стек до одного-единственного жизнеспособного варианта.

Этап IV. Финальный стек и возвращение к ADB — но уже осознанно

Именно здесь ADB перестал быть «временным костылём» и стал основой архитектуры.

Финальный стек выглядел так:

PowerShell
└── adb.exe (фиксированный путь)
    ├── getprop
    ├── /proc/*
    ├── dumpsys
    ├── pm
    └── sysfs

Ключевое изменение — отказ от доверия Android UI и переход к данным, которые:

публикуются ядром Linux,
используются самим Android для работы,
не предназначены для подмены маркетологами.

Этап V. Проверка как расследование, а не как сканирование

Проверка перестала быть списком команд и стала аналитическим процессом:

/proc/cpuinfo против заявленного SoC
/proc/meminfo против «12 GB RAM»
df против «1 TB storage»
ro.build.tags = dev-keys на «коммерческом» устройстве
factory / engineering APK в прошивке

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

Этап VI. Визуализация как доказательство

Отдельное внимание было уделено не сбору данных, а их подаче:

цветной вывод в CLI — для видеофиксации,
текстовый лог — для неизменяемого архива,
HTML-отчёт — для удобства чтения третьими лицами.

Важно:
ничего не «рисуется», всё генерируется из реального вывода ADB.
Видео демонстрирует процесс, а не результат.

Перспектива развития

В дальнейшем этот подход может эволюционировать в:

стандартизированный «consumer forensic kit»,
автоматическую генерацию сравнительных таблиц «заявлено / фактически»,
библиотеку сигнатур фейковых сборок,
видео-шаблон для жалоб на маркетплейсах,
полуавтоматический отчёт для регуляторов.

Проверка телефона — это не вопрос инструментов.
Это вопрос правильных ограничений.

Когда ограничения сформулированы верно,
даже «простой» ADB становится мощнее любых низкоуровневых дамперов.

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

ВИДЕО всего процесса проверки

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

как приготовить щелочной электролит. Сколько нужно добавить щелочи в воду чтобы получить электролит

- декабря 06, 2021

Далее...

Техническое описание всех способов проверки Android-телефонов, на примере китайского клона самсунг. Разоблачение, полная диагностика