Syrius Wallet Mobile App

Development ╰ Funding | Submissions
,
270

@DrBlaze_21 I removed the old app and installed the new universal app from the repo, but I get the following error:

App not installed as package conflicts with an existing package.

This is the first time I’m getting this error.

Same is true for v0.5.1

However, when I install v0.5.0 I do NOT get that error, so it must be an issue introduced in v0.5.1.

271

This error appears when you try to install the app while the old version is still present. Please uninstall the old version before install v0.5.2.

The x86_64/universal version is for testing on an emulator (on a PC). Less than 0.1% Android devices support the x86_64 CPU architecture.

272

Yes I have uninstalled the app and I’ve tried x86_64 also. I get the same message. However, when I uninstall and reinstall v0.5.0 I do not get the message.

I am running this on a sandbox in graphineOS but this is the first time I’ve experienced this error when upgrading. I’ve tested every version on this sandbox the same way.

Can anyone else replicate this issue? I can blow out the sandbox and create a new one and try that

273

I was able to compile the app for IOS and deploy to my private TestFlight environment. There are a few configurations that I noted need to be updated for the submission process which I have documented. I will be working with @0x3639 to get it deployed and working within the actual organization account. Here are some videos (I apologize for the resolution - they were taken with an iPad).

1 Like
274

@tortcher any updates on progress? Also, any interest in joining the community on a weekly X spaces to talk about your work?

1 Like
275

I can report that we have been working on getting me to build and sign the iOS app. In order to eventually build the app in the GH repo I need to build it locally first and then add code to the repo for GhA actions to build automatically.

I’ve gotten through all the local signing issues we had and hopefully we are down to an issue with the xCode version. I hope to be able to build locally this weekend. If that works we will move to building in Github with the GhAs that @tortcher has developed.

Once we get the iOS app building in my repo we can move it to /zenon-network. I’ve been traveling and working a ton so unfortunately I don’t have a lot of time to spare.

4 Likes
276

I ran the latest .apk through this evaluation GitHub - d78ui98/APKDeepLens: Android security insights in full spectrum.. I’ve used Grok to summarize the results below.

To evaluate the security report for the Syrius Mobile application (version 0.5.2, x86_64 release), I’ll analyze the provided information, focusing on permissions, intents, database handling, and potential security concerns. The report appears to be a decompiled analysis of the APK, likely generated by a tool like APKDeepLens, providing insights into the app’s permissions, intents, and database interactions.

1. Basic Information

  • Package: network.zenon.syrius.mobile
  • Build: 34
  • Report Date: 14/07/2025
  • Android Version: 4001 (This seems unusually high and may be a typo or a custom versioning scheme, as Android API levels are typically in the 30s as of 2025. For analysis, I’ll assume it’s a modern Android version unless specified otherwise.)

2. Permissions Analysis

The app requests several permissions, some of which are classified as “dangerous” due to their potential to access sensitive user data or device features. Here’s a breakdown:

Permissions

  • android.permission.VIBRATE: Allows the app to control the device’s vibration. This is a normal permission with low risk, typically used for notifications or haptic feedback.
  • android.permission.INTERNET: Allows network access. Common for most apps but introduces risks if the app communicates with untrusted servers or lacks proper encryption.
  • android.permission.ACCESS_NETWORK_STATE: Allows checking network connectivity status. Low risk, commonly used to adapt app behavior based on network availability.
  • android.permission.LOCATION_BIOMETRIC: A custom or misnamed permission (not standard in Android). Likely intended to mean access to location data or biometric authentication. If it involves location, it could be sensitive; if biometric, it requires user consent and secure handling.
  • android.permission.CAMERA (Dangerous): Access to the device’s camera. This is sensitive as it could be used to capture photos or videos without user knowledge if not properly restricted.
  • android.permission.READ_EXTERNAL_STORAGE (Dangerous): Allows reading from external storage. This could expose user files (e.g., photos, documents) if not carefully scoped.
  • android.permission.WRITE_EXTERNAL_STORAGE (Dangerous): Allows writing to external storage. Paired with read access, this could allow modification or deletion of user files.
  • android.permission.USE_FINGERPRINT: Allows use of fingerprint authentication. This is a sensitive permission but generally safe if used for authentication with user consent.
  • network.zenon.syrius.mobile.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION: A custom permission, likely used to restrict access to specific app components. The “not exported” aspect suggests it’s internal, reducing external access risks.

Dangerous Permissions

The three dangerous permissions (CAMERA, READ_EXTERNAL_STORAGE, WRITE_EXTERNAL_STORAGE) raise potential concerns:

  • Camera: Could be used for QR code scanning (common in blockchain/crypto apps like Syrius) or other legitimate purposes, but misuse could lead to unauthorized photo/video capture. The app should clearly prompt for user consent and limit camera use to specific functions.
  • Storage Permissions: Access to external storage could allow the app to read or modify sensitive files. On modern Android versions (API 30+), scoped storage limits this risk, but the app must explicitly declare its storage access purpose and handle files securely.
  • Mitigation: Ensure the app requests these permissions only when necessary, provides clear user prompts, and adheres to Android’s runtime permission model.

3. Intents Analysis

The report lists numerous PendingIntent instances, which are used to allow one app component to perform an action on behalf of another. The repeated entries suggest extensive use of intents, likely for inter-component communication or launching activities.

Observations

  • PendingIntent Usage: Many PendingIntent instances are listed with context and intent parameters, but several have pendingIntent = null, which could indicate incomplete or placeholder code. This might not pose a direct security risk but could lead to runtime errors or unexpected behavior if not handled properly.
  • Intent Actions: Page 3 lists multiple android.intent.action.VIEW intents, commonly used to open URLs or view content in other apps. If these intents are used to open web links, they could pose risks if the app doesn’t validate URLs or allows untrusted content to be loaded.
  • Specific Intent: The android.clockwork.home.PDATE.ANDROID.NSAR.ACTION (likely a typo for UPDATE or similar) suggests possible integration with Wear OS or a custom action. Without clarity on its purpose, it’s hard to assess its risk, but custom actions should be protected to prevent unauthorized access.
  • Security Concerns:
    • Implicit Intents: If the app uses implicit intents (not specifying a target component), other apps could intercept them, leading to data leakage or unauthorized actions.
    • Exported Components: The custom permission DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION suggests non-exported receivers, which is good practice to prevent external apps from triggering them. However, the report doesn’t confirm whether all intents are restricted to internal use.
    • Mitigation: Ensure intents are explicit where possible, validate any data passed via intents, and avoid sending sensitive information (e.g., cryptographic keys) through intents without encryption.

4. Database Security

The report shows the use of SQLiteDatabase with encryption, which is critical for an app like Syrius, likely a blockchain or crypto wallet handling sensitive data (e.g., private keys, transaction records).

Key Observations

  • Encrypted SQLite Database: Page 4 shows multiple SQLiteDatabase constructors with EncryptionKey parameters, indicating the app uses encrypted storage. This is a strong security practice, especially for a crypto app, as it protects sensitive data like private keys or wallet seeds.
  • Database Schema: Page 17 shows an ALTER TABLE statement adding an event_id and bytes column to a transaction table, with a foreign key to an events table. This suggests a relational database for storing transaction data, with bytes likely holding serialized transaction data.
  • Security Concerns:
    • Encryption Key Management: The use of multiple EncryptionKey parameters (e.g., passwordKey, passwordKey2, passwordKey3) is unusual and may indicate layered encryption or poor key management. If keys are derived from user passwords, they must be securely hashed (e.g., using PBKDF2 or Argon2) and stored in a secure location (e.g., Android Keystore).
    • SQL Injection: The execSQL statement appears hardcoded, reducing SQL injection risks. However, if the app accepts user input for other queries, it must use parameterized queries to prevent injection attacks.
    • Data Integrity: The foreign key with ON DELETE CASCADE ensures referential integrity, but the app should validate data before insertion to prevent corruption.
  • Mitigation:
    • Use Android Keystore for secure key storage.
    • Ensure encryption keys are not hardcoded or exposed in logs.
    • Validate all database inputs and use parameterized queries.

5. File System Access

Page 20 shows the app accessing external storage via getExternalFilesDir and getExternalCacheDir. These are standard Android APIs for app-specific storage, which are safer than unrestricted storage access due to scoped storage on modern Android versions.

Security Concerns

  • Storage Permissions: The READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions suggest the app may access files beyond its scoped storage. This could be for backups or exporting wallet data, common in crypto apps, but increases the risk of exposing sensitive data if not handled securely.
  • Mitigation:
    • Limit file access to app-specific directories.
    • Encrypt any sensitive data (e.g., wallet backups) before writing to external storage.
    • Clearly inform users when accessing or modifying external files.

6. Potential Security Risks

Based on the report, here are the key security risks and recommendations:

  1. Dangerous Permissions:
    • Risk: Camera and storage permissions could be abused if not tightly controlled.
    • Recommendation: Implement runtime permission checks, limit usage to specific features (e.g., QR scanning for camera), and provide clear user prompts.
  2. Intent Security:
    • Risk: Extensive use of PendingIntent and android.intent.action.VIEW could lead to data leakage or unauthorized actions if not properly validated.
    • Recommendation: Use explicit intents, validate URLs, and ensure sensitive data isn’t passed unencrypted.
  3. Database Security:
    • Risk: Poor encryption key management could expose sensitive data like private keys.
    • Recommendation: Use secure key derivation and storage (e.g., Android Keystore), and ensure all database operations are secure against injection.
  4. Network Security:
    • Risk: The INTERNET permission suggests network activity, likely for blockchain interactions. Insecure connections (e.g., HTTP instead of HTTPS) could expose sensitive data.
    • Recommendation: Use HTTPS with certificate pinning, validate server endpoints, and encrypt all sensitive network traffic.
  5. Biometric/Location Permission:
    • Risk: The LOCATION_BIOMETRIC permission is ambiguous and could imply sensitive data access.
    • Recommendation: Clarify its purpose and ensure user consent for any biometric or location data access.

7. Overall Assessment

The Syrius Mobile app appears to be a blockchain or cryptocurrency wallet, given its package name (network.zenon.syrius.mobile) and features like encrypted SQLite storage and QR code scanning (implied by camera permission). The use of encrypted databases is a strong security practice, but the app’s extensive permissions and intent usage raise concerns that require careful implementation to mitigate risks.

Strengths

  • Encrypted database storage for sensitive data.
  • Non-exported custom permission, reducing the risk of unauthorized component access.
  • Use of app-specific storage directories, aligning with modern Android security practices.

Weaknesses

  • Dangerous permissions (camera, storage) require strict justification and user consent.
  • Ambiguous LOCATION_BIOMETRIC permission needs clarification.
  • Extensive PendingIntent usage with potential null references could indicate code quality issues or incomplete implementation.
  • Lack of clarity on network security practices (e.g., HTTPS usage, certificate pinning).

Recommendations

  1. Permission Management: Clearly document the purpose of each permission in the app’s UI and request them only when needed. For example, camera access should be limited to QR scanning with explicit user prompts.
  2. Intent Security: Use explicit intents where possible, validate all data passed via intents, and avoid sending sensitive information unencrypted.
  3. Database Security: Ensure encryption keys are securely derived and stored, and use parameterized queries for all database operations.
  4. Network Security: Implement HTTPS with certificate pinning for all network communications, especially for blockchain transactions.
  5. Code Quality: Address potential issues with PendingIntent null references and clarify the purpose of custom permissions like LOCATION_BIOMETRIC.
  6. User Transparency: Provide clear privacy policies and in-app explanations for sensitive permissions and data handling.

8. Limitations of Analysis

  • The report is incomplete (e.g., truncated code, missing details on intent actions, and unclear Android version).
  • Without access to the app’s source code or runtime behavior, some assumptions (e.g., QR code scanning for camera) are based on common patterns in crypto apps.
  • I cannot perform a web search to gather additional context about the app’s purpose or known vulnerabilities, as per the instructions.

If you need a deeper analysis of specific components or have additional questions about the report, please let me know! For example, I can focus on specific code snippets or permissions if you provide more context or a specific query.