In previous versions of IDA, I could start the Android server, launch the Android app, and attach directly from IDA without loading any .so file or IDB. The process was responsive, and I could begin debugging immediately.
However, with IDA 9.0 SP1, if I try to attach directly from IDA without first loading a .so file or IDB, the entire UI freezes and becomes unresponsive. On the other hand, if I load the .so file into IDA before attaching, it works correctly.
Please try this on “good” and “bad” IDA versions: ida.exe -z10000 -LC:\temp\idadbg.log
(use a writable path for the log and different filenames for each run)
Then compare what’s different in 9.0 compared to the previous version. Hopefully it will give some clues.
Caching 'Choose process to attach to'... ok
process pid/tid: 904
INTERP: /apex/com.android.runtime/bin/linker64, SONAME: /system/bin/linker64
72E7F1C000: new dll /apex/com.android.runtime/bin/linker64 (soname=/system/bin/linker64)
Build ID 'bacf9941030f330f49c494fe0df1f09b' of '/apex/com.android.runtime/bin/linker64'
72E7F698F0: added shlib bpt (rtld_db_dlactivity)
Build ID '6c62557be5d4fc86476bf109a2f9cd20' of '/system/bin/app_process64'
70E55000: new dll /apex/com.android.art/javalib/arm64/boot.oat (soname=boot.oat)
..
DBG: PTRACE_O_TRACECLONE ability detected, will be used in debugging multi-threaded program
DBG: collect threads
DBG: 0 found 904 thread
DBG: 0 found 940 thread
...
Assuming __fastcall calling convention by default
E7F1B000: loaded [vdso]
E68A8000: loaded /system/system_ext/lib64/vendor.qti.hardware.audiohalext@1.0.so
E684D000: loaded /system/lib64/libpowermanager.so
...
70E55000: loaded /apex/com.android.art/javalib/arm64/boot.oat
E7F1C000: loaded /apex/com.android.runtime/bin/linker64
RNG:FF00000D: create_range 12C00000..32C00000
RNG:FF00000D: create_range 70A15000..70CA4000
...
RNG:FF00000D: del_range 8F8000 delcmt 1
Unloading IDP module C:\Program Files\IDA Pro 8.3\procs\arm.dll...
ida 9
process pid/tid: 30289
INTERP: /apex/com.android.runtime/bin/linker64, SONAME: /system/bin/linker64
72E7F1C000: new dll /apex/com.android.runtime/bin/linker64 (soname=/system/bin/linker64)
Build ID 'bacf9941030f330f49c494fe0df1f09b' of '/apex/com.android.runtime/bin/linker64'
72E7F698F0: added shlib bpt (rtld_db_dlactivity)
Build ID '6c62557be5d4fc86476bf109a2f9cd20' of '/system/bin/app_process64'
...
DBG: PTRACE_O_TRACECLONE ability detected, will be used in debugging multi-threaded program
DBG: collect threads
DBG: 0 found 30289 thread
...
DBG: 1 found 30809 thread
DBG: 1 found 30810 thread
72E7F1B000: loaded [vdso]
72E68A8000: loaded /system/system_ext/lib64/vendor.qti.hardware.audiohalext@1.0.so
72E684D000: loaded /system/lib64/libpowermanager.so
..
72E7F1C000: loaded /apex/com.android.runtime/bin/linker64
Debugger: attached to process /system/bin/app_process64 (pid=30289)
Build ID '96a2ad2581099975b8c7bb4ab40fb39a7086a166' of '/apex/com.android.art/javalib/arm64/boot.oat'
...
Build ID '05439b3fd79c7af99f197179ad59f15e' of '/system/lib64/libpowermanager.so'
Build ID '03157a4d5504abbd915c9e9e8bedc511' of '/system/system_ext/lib64/vendor.qti.hardware.audiohalext@1.0.so'
Hex-Rays Decompiler plugin has been loaded (v9.0.0.241217)
The hotkeys are F5: decompile, Ctrl-F5: decompile all.
Please check the Edit/Plugins menu for more information.
Hex-rays version 9.0.0.241217 has been detected, gooMBA plugin ready to use
dbg_bin_search 12C00000..32C00000
ida 9 seems to get stuck there and the line about attaching to app process seems strange, unless that is intended behavior, as I was attaching to another process.
Thanks! It is supposed to be fixed, but we used to have an issue in the rust plugin which was triggering an unintended search during debugging and I wonder if it reappeared in different circumstances. Can you try moving rust.dll out of the plugins folder temporarily and see if it fixes the problem?