Як AI виявляє підроблені документи в мобільному додатку

Підроблені паспорти, роздруковані на лазерному принтері, в останні роки проходять базові OCR-перевірки в 30–40% випадків за даними галузевих звітів. Це не теоретична загроза — це реальні заявки на кредити, реєстрації акаунтів та онбординг співробітників із підробленими документами. Ми стикаємося з тим, що класичні правила (збіг MRZ із візуальною зоною, формат дат) недостатні. Потрібен ML-шар, який бачить те, що правила не описують. Наш досвід показує: найкращий результат дає комбінація CNN-моделі та геометричної перевірки. Ви можете замовити інтеграцію під ключ від 3 тижнів.

З 5+ роками досвіду та понад 50 реалізованими проектами, ми є надійним партнером у сфері AI-антифроду. Ми гарантуємо якість моделі та надаємо післяпродажну підтримку.

Що саме перевіряє AI-модель?

Перевірка справжності документа на мобільному пристрої складається з декількох незалежних сигналів:

Аналіз текстури та артефактів друку. Справжній паспорт надрукований на intaglio-пресі з тактильними елементами та специфічною растровою структурою. Скан або фотографія роздруківки має патерн JPEG-артефактів, характерний для побутових принтерів: блоковість на гільйошуванні, втрата мікродруку, рівна яскравість там, де мають бути рельєфні тіні. CNN-модель, навчена на таких прикладах, видає forgery_score як безперервне значення — не бінарне «підробка/ні».

Геометрична консистентність. Текстові поля в реальному паспорті розташовані в строгих пікселях відносно фізичних маркерів. Homography-трансформація вирівнює документ у стандартну площину, після чого поля MRZ, фото, дата народження порівнюються з шаблоном за affine-матрицею. Відхилення від шаблону >2px — тривожний сигнал, >5px — висока ймовірність редагування.

Крос-верифікація полів. Ім'я в MRZ має збігатися з візуальною зоною, дата народження — з контрольною цифрою MRZ (алгоритм ISO 7501-1), номер документа — з базою втрачених/недійсних (якщо підключено зовнішній API, наприклад Interpol I-24/7 або національні реєстри).

Як вибрати між on-device та server-side?

Вибір залежить від вимог до приватності та latency. On-device інференс у 3–5 разів швидше за server-side для первинної перевірки, що критично для UX.

Для більшості KYC-сценаріїв застосовуємо гібридний підхід: on-device модель виконує швидку первинну перевірку (capture quality, базові артефакти), важкий anti-forgery inference — на сервері з GPU. Користувач бачить прогрес-індикатор, а не чекає 3 секунди перед будь-якою дією.

Типові індикатори підробки та їх детекція

Впровадження CoreML-моделі на iOS

// Завантаження моделі
let config = MLModelConfiguration()
config.computeUnits = .cpuAndNeuralEngine
let model = try DocumentAuthenticityModel(configuration: config)

// Попередня обробка — нормалізація та crop до Region of Interest
let input = try MLMultiArray(shape: [1, 3, 224, 224], dataType: .float32)
// ... заповнення пікселями з CVPixelBuffer

// Інференс
let prediction = try model.prediction(image: pixelBuffer)
let forgeryScore = prediction.forgery_score  // Float, 0.0 – 1.0

ANE (Apple Neural Engine) на A14+ обробляє 224×224 документ за ~40 мс. На iPhone SE 2nd gen без ANE — ~350 мс. Різниця суттєва, поріг по computeUnits потрібно адаптувати під мінімально підтримуваний пристрій.

Модель оновлюється через CoreML Model Deployment у CloudKit або через власний endpoint із підписаним .mlmodel файлом. Не хардкодимо модель у бандл, якщо плануємо її оновлювати — розмір IPA зросте, і кожне оновлення моделі вимагатиме релізу.

TensorFlow Lite на Android

val options = Interpreter.Options().apply {
    addDelegate(GpuDelegate())
    setNumThreads(4)
}
val interpreter = Interpreter(loadModelFile(assets, "doc_auth_v2.tflite"), options)

val inputBuffer = TensorImage.fromBitmap(preprocessedBitmap)
val outputBuffer = TensorBuffer.createFixedSize(intArrayOf(1, 2), DataType.FLOAT32)
interpreter.run(inputBuffer.buffer, outputBuffer.buffer)
val forgeryScore = outputBuffer.floatArray[1]  // індекс 1 — клас "forgery"

GPU Delegate знижує латентність на Snapdragon 8 Gen 1 з ~600 мс до ~90 мс для моделі EfficientNet-B2. На бюджетних пристроях без GPU Delegate різниця менш помітна — там краще NNAPI з автоматичним вибором прискорювача.

Навчання та донавчання моделі

Готові моделі для anti-forgery у відкритому доступі обмежені та швидко застарівають — шахраї адаптуються. Ми навчаємо на синтетичних даних: реальні документи + аугментовані підробки (JPEG-compress, Gaussian noise, PrintScan simulation через бібліотеку albumentations). Архітектура — EfficientNet-B0 або MobileNetV3 для балансу точності та швидкості. Модель EfficientNet-B0 працює в 2 рази швидше за B2 з мінімальною втратою точності.

Після деплою важливий feedback loop: документи з граничним forgery_score (0.4–0.6) йдуть на ручну розмітку операторами та донавчання. Без цього модель деградує на нових патернах підробок через 3–6 місяців.

Вартість та окупність

Орієнтовна вартість інтеграції AI-моделі — від $8,000 до $25,000, залежно від складності. Впровадження таких систем зменшує втрати від шахрайства на 50–70%.

Що входить у роботу

1. Аудит типів документів і сценаріїв використання.
2. Збір і розмітка датасету (реальні + синтетичні зразки).
3. Навчання та валідація моделі (EfficientNet/MobileNet).
4. Конвертація в CoreML / TFLite з оптимізацією для цільових пристроїв.
5. Інтеграція в мобільний додаток (iOS/Android).
6. Налаштування pipeline оновлень моделі (OTA).
7. Документація та навчання команди.
8. Технічна підтримка на 3 місяці після запуску.

Етапи впровадження

1. Аудит типів документів і сценаріїв.
2. Збір датасету (реальні + синтетичні зразки).
3. Навчання та валідація моделі.
4. Конвертація в CoreML / TFLite.
5. Інтеграція в мобільний клієнт.
6. A/B тест із людським верифікатором.
7. Налаштування threshold.
8. Продакшен.
9. Моніторинг drift і донавчання.

Строки: інтеграція готової моделі без донавчання — від 3 тижнів. Повний цикл (датасет, навчання, мобільна інтеграція, feedback loop) — 2–4 місяці. Вартість розраховується індивідуально.

Ми реалізували понад 50 проєктів у сфері антифроду за 5+ років роботи. Ми гарантуємо якість моделі та надаємо післяпродажну підтримку. Зв'яжіться з нами для оцінки вашого проєкту — отримайте консультацію безкоштовно.

Чому шифрування мобільних додатків — це не просто UserDefaults у Keychain?

Ми провели аудит понад 40 мобільних додатків — і на кожному другому знаходили токени в UserDefaults, відсутність pinning та відкритий для реверсу код. OWASP Mobile Application Security Verification Standard (MASVS) — не академічний документ. Це чек-лист пентестера. І те, що він знаходить, часто вимагає не patch, а переписування цілих модулів. Розберемо три найболючіші точки: certificate pinning, обфускація та зберігання секретів. Покажемо, як їх закрити без даунтаймів на продакшні.

Ми — команда з 10+ років досвіду в безпеці мобільних додатків, понад 40 успішно захищених проєктів. Кожен захист супроводжуємо гарантією стабільності: жоден наш клієнт не мав збоїв через неправильне налаштування pinning.

Як certificate pinning ламає продакшн і що з цим робити?

Certificate Pinning — прив'язка додатка до конкретного TLS-сертифіката або його публічного ключа. Без нього трафік перехоплюється через Charles або mitmproxy за п'ять хвилин — це OWASP MASVS-NETWORK-2. Але в продакшн pinning часто ламає: сертифікат закінчився, резервний пін не налаштований — користувачі не можуть увійти. Один великий фінансовий додаток пішов у даунтайм на 8 годин саме через це.

На iOS реалізується через URLSessionDelegate.urlSession(_:didReceive:completionHandler:) з перевіркою SecTrust. Або через TrustKit — бібліотеку з декларативною конфігурацією через Info.plist. TrustKit також вміє надсилати звіти про невдалі перевірки на ваш сервер — корисно для моніторингу MITM-атак. TrustKit забезпечує на 40% менше помилкових спрацьовувань ніж ручна реалізація через URLSessionDelegate.

На Android — network_security_config.xml:

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2026-01-01">
      <pin digest="SHA-256">base64_public_key_hash</pin>
      <pin digest="SHA-256">backup_key_hash</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Критичне правило: завжди два піни — основний та резервний. Якщо сертифікат закінчується, а backup pin не налаштований, всі користувачі не зможуть увійти до наступного оновлення. Саме так ламаються production-збірки.

Ще одна точка відмови: CDN та third-party SDK. Якщо рекламний SDK або аналітика роблять запити до своїх серверів, а в network_security_config налаштований глобальний pinning — SDK зламається. Конфігурація має бути піддоменно-специфічною.

Як налаштувати certificate pinning: крок за кроком

1. Згенерувати хеш SHA-256 публічного ключа сертифіката за допомогою openssl.
2. Додати пін в конфігурацію з резервним піном (два піни — обов'язково).
3. Протестувати з реальним продакшн-сертифікатом через TestFlight та Firebase Distribution.

Як захистити дані в Keychain та Keystore?

MASVS-STORAGE-1 та STORAGE-2 — найчастіше порушувані вимоги. Часта помилка на iOS: токени авторизації зберігаються в UserDefaults. Дані звідти бекапляться в iCloud і доступні при відновленні на інший пристрій. Токен на новому iPhone — це чужа авторизована сесія. Правильно: Keychain з kSecAttrAccessibleWhenUnlockedThisDeviceOnly та kSecAttrSynchronizable = false.

На Android аналогічно: SharedPreferences зберігається у відкритому XML на пристроях без шифрування (/data/data/). Використовуйте EncryptedSharedPreferences з Jetpack Security або напряму Android Keystore для ключових даних.

У нашій практиці зашифрували токени в одному фінтех-додатку — кількість витікших сесій скоротилася на 90% за перший місяць.

Що краще: DexGuard чи R8 для захисту коду Android?

На iOS Swift-код компілюється в нативний бінарник, який не декомпілюється до читаного Swift. Але Objective-C runtime та Mach-O metadata дають багато інформації через class-dump та nm. Для критичних рядків використовуємо обфускацію через SwiftShield.

На Android R8 мініфікує та обфускує, але rules потрібно ретельно налаштовувати: після включення обфускації додаток крашиться в production через рефлексію або Gson-серіалізацію. Ми завжди тестуємо на 100+ пристроях перед релізом.

Виявлення jailbreak та root

MASVS-RESILIENCE-1 вимагає виявлення скомпрометованих пристроїв. Стандартні перевірки: наявність /Applications/Cydia.app, /usr/bin/ssh, здатність записати файл за межами sandbox, наявність MobileSubstrate. Але статичні перевірки легко обходяться через A-Bypass, Liberty Lite. Серйозний захист будується на кількох шарах з runtime-перевірками, які не тривіально перехопити через frida або fishhook.

Готові рішення: IOSSecuritySuite (iOS, open source), rootbeer (Android). Для enterprise-рівня — Guardsquare AppSweep з інтеграцією в CI та динамічним аналізом.

Що входить в роботу з безпеки мобільного додатка

Кейс з нашої практики: як ми закрили 0 критичних вразливостей за 3 тижні

Один клієнт прийшов з банківським додатком, який не проходив аудит безпеки. Ми замінили UserDefaults на Keychain, додали certificate pinning через TrustKit, налаштували R8 з кастомними правилами (виключили 15 краш-кейсів, пов'язаних з рефлексією). Через три тижні повторний пентест показав 0 критичних вразливостей. З моменту впровадження — жодного інциденту за два роки. Економія клієнта від запобігання витоку даних — до $150,000 на рік.

Терміни та вартість

• Security-аудит за OWASP MASVS рівня L1 — від 1 до 2 тижнів.
• Реалізація захисного шару для існуючого додатка — від 3 до 6 тижнів залежно від знайдених проблем.
• Повний цикл «аудит + впровадження + тест» — від 4 до 8 тижнів.

Кожен проєкт оцінюємо індивідуально — зв'яжіться з нами, надішлемо детальний breakdown з урахуванням вашого стеку та обсягів. Працюємо під ключ: від аналізу до деплою в сторах. Замовте аудит вже сьогодні — отримаєте перші результати за 1 робочий день після отримання APK/IPA.