御盾御盾
Technical articles
English
简体中文繁體中文English日本語한국어DeutschFrançaisEspañolPortuguêsРусскийالعربيةBahasa Indonesia
Yudun console

Protect Native algorithms without sacrificing launch or compatibility

Yudun designs protection around SO, JNI, dynamic-library dependencies, and valuable Native functions, then validates loading, launch, and real invocations on each target ABI.

Request an app hardening testView public assessments

Are these problems holding back your app?

  • Symbols and strings still reveal the valuable algorithm inside SO
  • JNI methods disappear after export or loading changes
  • A third-party Native SDK conflicts with the protection policy
  • arm64-v8a works while another target ABI fails to launch

How Yudun handles them

  • SO VMP and Native protection

    Choose protection for valuable Native functions, symbols, strings, and constants without blanketing every path.

  • JNI and load-chain review

    Review registration, dependencies, load order, and third-party SDKs so invocations remain verifiable after protection.

  • ABI compatibility testing

    Test installation, launch, library loading, and a critical JNI flow on each target architecture.

Public assessment: an SO filename did not prove the Native container was directly readable

The Yudun S21-R43 assessment reviewed both release structure and a debug runtime smoke test instead of judging Native protection by filenames alone.

View the Native assessment

What the assessment disclosed

  • Reviewed stripped Native state, assets containers, and the proxy entry chain
  • Placed static structure and runtime loading observations in one record
  • Separated candidate evidence, smoke testing, and final release status

Scope: The result covers this candidate and the executed smoke scope, not a full device, ABI, or performance matrix.

From assessment to delivery

See the delivery method
  1. 01

    Map Native assets

    Provide libraries, JNI entry points, target ABIs, dependencies, and valuable functions.

  2. 02

    Choose the protection mix

    Configure SO and VMP protection around value, function invocation frequency, and loading constraints.

  3. 03

    Accept every architecture

    Run real paths on target ABIs and OS versions, record failures, and keep a rollback configuration.

Questions customers often ask

Native Protection

Why Map JNI and ABI Before SO Hardening

Define the SO protection scope by analyzing ELF dependencies, JNI registration, loading sequences, NDK API floors, and ABI artifact matrices to minimize application launch failures and compatibility issues post-hardening.

View details
View all articles

Questions before purchase

Can SO hardening affect JNI invocations?

Yes. Registration, symbol visibility, load order, and third-party dependencies require verification on every target architecture.

Is removing symbols enough to protect an SO?

No. It removes one class of clues. Strings, constants, control flow, loading, and runtime material remain separate concerns.

Why is ABI a hard gate?

ABIs differ in instructions, linking, and dependencies. Results from another architecture cannot establish compatibility.

Which functions should SO VMP cover?

Prioritize valuable native functions with clear inputs, outputs, and independent regression paths. Avoid blanket coverage of initialization and frequently executed paths.

Security standards and platform references

  1. Android NDK ABI guide

    Native architectures, ABI packaging, and compatibility

  2. Android security best practices

    Android application security design and release boundaries

  3. OWASP MASVS

    Mobile application security controls and verification scope

  4. Android app signing

    Signing identity, upgrade continuity, and release integrity

  5. Play Integrity API

    Server-side decisions and the limits of application integrity signals