Skip to content

README-Reverse-Engineering.md

Latest commit

 

History

History
38 lines (29 loc) · 2.94 KB

README-Reverse-Engineering.md

File metadata and controls

38 lines (29 loc) · 2.94 KB
Raw

Vedabase Reverse Engineering & Modernization Report

1. Analysis of .ivd File Format

Upon decompiling the APK to Java using JADX and analyzing the source code (specifically com.gopalapriyadasa.b.aj), I discovered that the .ivd file format is not a proprietary, undocumented format. It is, in fact, a standard SQLite Database. The application uses the built-in Android SQLiteDatabase.openOrCreateDatabase() to read it. Thus, no custom C/C++ native library (.so) or complex parsing engine is required. The rendering pipeline utilizes pure Java logic to read rows from this SQLite database and render them via standard Android Views (like EndlessTextView). Because no native code is present in the APK, the application is fully ARM64 compatible by default via the Dalvik/ART runtime.

2. Modernization & Compatibility Fixes

A. Android 14/15/16 Compatibility (targetSdkVersion 34)

The original app targeted Android 4.3 (API 18) and used requestLegacyExternalStorage="true". To modernize the application to run on the latest Android versions:

  1. Updated apktool.yml to set targetSdkVersion: 34.
  2. Updated AndroidManifest.xml to include the android.permission.MANAGE_EXTERNAL_STORAGE permission.

B. Scoped Storage / Storage Access Migration

Since the app relies on directly opening a 1.1GB .ivd SQLite file from the external storage (such as the Downloads folder), standard scoped storage (READ_EXTERNAL_STORAGE) limits direct java.io.File access on Android 11+. To preserve the 100% original behavior and SQLite compatibility without resorting to expensive copying or complex ContentProvider proxies, the app was patched to request "All Files Access".

Smali Patch in MainActivity.onCreate(): I injected Dalvik bytecode into MainActivity.smali to check if the device is running Android 11+ (SDK_INT >= 30). If so, it checks Environment.isExternalStorageManager(). If the permission is not granted, it fires an Intent to android.settings.MANAGE_APP_ALL_FILES_ACCESS_PERMISSION so the user can explicitly grant the permission required to read the .ivd database directly.

3. Build Environment

To ensure reproducible builds regardless of the host OS, I have provided a Dockerfile that packages:

  • Java 17 (OpenJDK)
  • Apktool 2.10.0
  • Android Command Line Tools (Build Tools 34.0.0, apksigner, zipalign)

Building with Docker

  1. Ensure Docker Desktop is running.
  2. Build the image: docker build -t vedabase-builder .
  3. Run the build: docker run --rm -v ${PWD}:/app vedabase-builder This process will securely compile the patched Smali code, zipalign the APK, and sign it with a generated debug keystore.

Rebuilt Artifacts Available Locally

  • app-patched.apk: A successfully rebuilt and signed APK, ready to be installed and tested on a modern Android 16 device/emulator.
  • decompiled_apk/: The complete, patched Apktool source project.
  • jadx_output/: The decompiled Java source code for reference.