Android SDK - Infatica

1. Introduction

Infatica engaged Halborn to conduct a code review assessment on their repository, beginning on July 15th 2025 and ending on July 17th 2025. The security assessment was scoped to the private repository that Infatica shared with the Halborn team.

2. Assessment Summary

The Halborn Team was allocated three days for this engagement, during which one full-time security engineer — expert in blockchain and security — conducted a comprehensive audit of the in-scope components related to Infatica repository. This engineer possesses advanced skills in penetration testing, web application security assessments, and an in-depth understanding of multiple blockchain protocols.

The primary objectives of this audit were to:

• Verify that each component performs its intended functions accurately and reliably.

• Identify and assess potential security issues within the source code, particularly those that could impact the privacy and protection of PII (Personally Identifiable Information).

Additional objectives included evaluating adherence to industry best practices, ensuring robust security measures are in place, and identifying opportunities for further strengthening the security posture.

The source code review of Infatica repository revealed several weaknesses demanding attention.

In the course of a comprehensive source code review of the Infatica SDK, four distinct security shortcomings were identified that merit prompt attention. First, the SDK’s Android test application was configured to permit cleartext traffic, thereby exposing user data and control communications to interception on untrusted networks. Second, numerous third‑party libraries were found to be outdated or comprised known vulnerabilities, potentially undermining the overall security posture of any integrating application. Third, the release build configuration omitted code minification and obfuscation, leaving internal implementation details readily accessible to reverse engineering and intellectual property theft. Finally, the SDK’s logging routines were observed to record network configuration information, such as DNS server addresses, which could inadvertently disclose network infrastructure data.

It is recommended that these areas be addressed holistically to elevate the security baseline of the Infatica SDK. Enforcement of encrypted communications, regular dependency management, activation of build‑time obfuscation, and adoption of secure logging practices will collectively ensure that the SDK remains robust against emerging threats and integrations uphold the highest standards of confidentiality and integrity.

Finally, based on the review of Infatica SDK, it can be confirmed that the code did not collect, process, or store any end‑user personal data (PII - Personally Idenfiable Information) beyond IP addresses and an anonymized UUID used solely for routing.

3. Test Approach and Methodology

Halborn combined manual and automated security testing to strike the right balance between speed, thoroughness, and precision within the scope of the penetration test. Manual techniques were employed to reveal nuanced logical, procedural, and implementation-level flaws, while automated tools broadened the assessment’s reach—rapidly pinpointing common vulnerabilities across the entire solution.

Throughout the engagement, we progressed through, among the following —but not limited to— phases (when applied), leveraging both targeted tools and bespoke techniques:

• Content & Functionality Mapping
  Cataloging every feature and endpoint exposed by the application.

• Technology-Stack & Public Code Review
  Identifying known vulnerabilities in frameworks, libraries, and any publicly accessible source repositories.

• Software Version Analysis
  Detecting outdated or unpatched components.

• Sensitive Data Exposure
  Hunting for leaks of critical or private information.

• Business-Logic Testing
  Uncovering flaws in workflows, transaction flows, and access controls.

• Access Control Assessment
  Verifying correct enforcement of permissions and role-based restrictions.

• Authentication & Authorization
  Stress-testing login flows, token handling, and privilege escalation paths.

• Input Validation & Handling
  Ensuring all user inputs are properly sanitized and parsed.

• Fuzzing & Parameter Injection
  Applying randomized and structured payloads—SQL, JSON, HTML, command-line, directory path injections—to provoke unexpected behavior.

• Brute-Force & Rate-Limiting Tests
  Validating defenses against credential stuffing, account-lockout bypass, and throttling evasion.

• Response Manipulation
  Tampering with server replies to detect insecure assumptions or client-side vulnerabilities.

• Deep Source-Code Review
  Manually inspecting critical modules for hidden flaws and backdoors.

4. Caveats

5. Scope

The initial commit ID was 90abe642305d4e9d141c3eb4324ea9e41aa3858b

• https://git.infatica.io/infatica_golang/android_sdk/-/tree/90abe642305d4e9d141c3eb4324ea9e41aa3858b

However, after two days of the engagement, the commit was updated to 89afb4413271db462a729201af63a0b2128fbdb0 because there were many issues during the compilation process.

• https://git.infatica.io/infatica_golang/android_sdk/-/tree/89afb4413271db462a729201af63a0b2128fbdb0

6. Constrains & Limitations

It was not possible to compile the provided source code due to persistent build errors encountered during the assessment. Although the Infatica team kindly supplied an updated version on the second day of our three‑day review, the revised code likewise failed to compile. Consequently, Halborn was unable to execute or test a functional, compiled SDK during this engagement.