Bug creates overflow in processor.rs
GanbaruTobi opened this issue · 21 comments
When trying to solve the challenge:
https://github.com/angr/angr-doc/blob/master/examples/defcon2019quals_veryandroidoso/ooo.defcon2019.quals.veryandroidoso.apk
My code:
https://gist.github.com/GanbaruTobi/a01b31216e7dfc2c2e795b092eb290ca
creates a panic:
thread 'main' panicked at 'attempt to add with overflow', radius/src/processor.rs:712:17
stack backtrace:
0: rust_begin_unwind
at /rustc/7466d5492b2d28d2ba5114dbe71511a6502ac822/library/std/src/panicking.rs:584:5
1: core::panicking::panic_fmt
at /rustc/7466d5492b2d28d2ba5114dbe71511a6502ac822/library/core/src/panicking.rs:142:14
2: core::panicking::panic
at /rustc/7466d5492b2d28d2ba5114dbe71511a6502ac822/library/core/src/panicking.rs:48:5
3: radius2::processor::Processor::fetch_instruction
at ./radius/src/processor.rs:712:17
4: radius2::processor::Processor::execute_instruction
at ./radius/src/processor.rs:718:9
5: radius2::processor::Processor::step
at ./radius/src/processor.rs:742:13
6: radius2::processor::Processor::run
at ./radius/src/processor.rs:853:38
7: radius2::radius::Radius::run_until
at ./radius/src/radius.rs:467:9
8: dex::main
at ./examples/dex/src/main.rs:95:25
9: core::ops::function::FnOnce::call_once
at /rustc/7466d5492b2d28d2ba5114dbe71511a6502ac822/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
Is calling a native function possible in a dex/apk?
The pc 18446744073709551615 is in hex 0xffffffffffffffff
Is calling a native function possible in a dex/apk?
no not at the moment, though it is planned
Additionally there shouldn't be an overflow, i fixed that, however there is definitely something going wrong there. The DEX support is limited but invoke-static should work so I need to figure out why that pc address is wrong.
The method is native.
Else, its the only Method having a void return type.
Ok I see. I am looking at the challenge right now. Unfortunately the only way to do it currently would be to hook each of the native call invoke-static instructions and in those hooks create a new Radius instance loading "lib/armeabi-v7a/libnative-lib.so" (this has no vector instructions and should execute properly), then create a new call_state and run the right corresponding method with call_function. But this sucks and i would understand if you didn't want to do it that way. I will look into fixing this and making it all automatic (like in angr). that is my eventual goal
Alternatively you could use r2frida, and initialize a state from a hook in the odex code. i am not sure what the native calls look like there but hopefully everything should "just work" . if you have a rooted device you can run setprop dalvik.vm.dex2oat-flags -g and recompile the challenge app with pm compile ... and the odex code will contain debug symbols making finding the right methods much easier. let me know if you do this and are successful cuz that would be nice
I have a device and will try your suggestions. But i remember having trouble with achieving a hook from my tries with ESILSolve (radareorg/esilsolve#2). Having learned a bit more about the tools I will try again and will keep u updated.
Sadly i cannot help. Facing the same problem as last time, that the user apps are never compiled to everything (or speed) on my device. When reviewing the odex it has only used "verify". Having a Poco X3 NFC, with LineageOS 19.1 (Android 12) and i tried also with LineageOS 18 (Android 11).
you cant run pm compile -m everything ... ?
If i run it, i get the message "success" and the generated base.odex is only compiled with verify, as u can see above. I also verified this with oatdump. Same for other profiles like everything-profile, speed, speed-profile, .... Actually I also tried it last time with a friends phone, i think he has some newer google pixel and we had the same effect. The only phone we got it to work was a very old device, like Android 8 or 9. Sadly by all the searching i didn't find a solution for this for now.
So that is how it looks for me. No addresses on the classes (if that is a thing) and no methods at all.
And thats what the odex contains as info
damn thats annoying. yeah i think i originally did this on a pixel with android 9 so its not too surprising that it doesnt work anymore. you could try manually running dex2oat. that should definitely work
When building with dex2oat by hand and position the file in the correct path + chown:
dex2oat --dex-file=base.apk --oat-location=base.odex --compiler-filter=everything --oat-file=base.odex --oat-location=
/data/app/~~IaM0efaCbBd3dTr8RviWrQ==/ooo.defcon2019.quals.veryandroidoso-7_uDuvMOjOvpysBQW-fCOw==/oat/arm64/base.odex
--classpath-dir=/data/app/~~IaM0efaCbBd3dTr8RviWrQ==/ooo.defcon2019.quals.veryandroidoso-7_uDuvMOjOvpysBQW-fCOw== --cl
ass-loader-context=PCL[]{PCL[/system/framework/android.test.base.jar]#PCL[/system/framework/org.apache.http.legacy.jar
]} --instruction-set-features=default -g --debuggable --runtime-arg -Xdeny-art-apex-data-files --runtime-arg -Xtarget-
sdk-version:26 --runtime-arg -Xhidden-api-policy:enabled --runtime-arg -Xms64m --runtime-arg -Xmx512m
I can verify the filter was "everything" and the file is huge and should contain alot. But r2frida is not able to catch up information:
pulling the odex to local i can see stuff with r2:
So maybe the odex formatting changed somewhat and r2frida is not catching this with :icm, but I am just guessing. I don't know if thats interessting to someone, but i added the files:
base_files.zip
hmm the methods dont come up in r2frida with :is?
Oh sorry (got quite early here), yes that works, but is missing the Solver.solve function in both r2frida and r2.
I will try my luck later to find it manually
I just also checked with oatdump, and it says to not have compiled all methods, so maybe the ~6000 line method was too much...
Or every native method and method using native methods are missing.
yeah the native methods will still be in the native library, it wont pull those in. there are flags to set the max method size for dex2oat to compile though
I wasn't suspecting it to pull the methods in, but was thinking that maybe the native library will be linked. Since I dont see how to achieve that with the given parameters of dex2oat (the lib would be in the base.apk). I played with the max method size (--large-method... --huge-method...) and other reasonable parameters without success. Also i think that the "everything" profile is realy made to use all possibilities to compile (so I assume its using --large-methods-max=0 or whatever the max is). I think I will stop on this matter for now, but will for sure try if u manage to do the trick for apks we started this conversation with. thanks so much for all the support.
I will just leave a more parameter rich try here for documentation purposes:
dex2oat64 --dex-file=base.apk --oat-location=base.odex --compiler-filter=everything --oat-file=base.odex --oat-location=/data/app/~~IaM0efaCbBd3dTr8RviWrQ==/ooo.defcon2019.quals.veryandroidoso-7_uDuvMOjOvpysBQW-fCOw==/oat/arm64/base.odex --classpath-dir=/data/app/~~IaM0efaCbBd3dTr8RviWrQ==/ooo.defcon2019.quals.veryandroidoso-7_uDuvMOjOvpysBQW-fCOw== --class-loader-context=PCL[]{PCL[/system/framework/android.test.base.jar]#PCL[/system/framework/org.apache.http.legacy.jar]} --instruction-set=arm64 --instruction-set-features=default -g --debuggable --runtime-arg -Xdeny-art-apex-data-files --runtime-arg -Xtarget-sdk-version:26 --runtime-arg -Xhidden-api-policy:enabled --runtime-arg -Xms64m --runtime-arg -Xmx512m --runtime-arg -Xrelocate --android-root=/data/app/~~IaM0efaCbBd3dTr8RviWrQ==/ooo.defcon2019.quals.veryandroidoso-7_uDuvMOjOvpysBQW-fCOw== --huge-method-max=999999999 --large-method-max=999999999 --deduplicate-code=false --compact-dex-level=none
yes thank you for trying! i will try to get more dex code working and properly add native function calls so these kinds of workarounds arent necessary
Since this Issue was for the bug in the processor.rs and this is resolved, I will close this