Closed brazdil closed 11 years ago
Finally!!! Managed to run the example and the answer is "all-or-nothing", i.e. if the array is too short, ArrayIndexOutOfBoundsException is thrown and nothing is overwritten.
Okey, so the compilation error still needs fixing...
Compilation error caused by not declaring FillArrayData as throwable. Fixed in 6bca81a.
Hmm, this isn't really fixed yet. Recompilation of a FillArrayData instruction works only when it is not surrounded by a TRY block. In that case, DexInstructionTranslator.translate
method takes the else if (successors.size() == 1)
branch and everything is fine, but when the if (successors.size() > 1)
branch is taken, translated instruction doesn't have any successors set. The reason is that the corresponding visit
method does not generate them. I'm, however, not sure how this should be correctly handled, so I'm positing it here. What doesn't make sense to me is that the compiler's FillArrayDataInsn
class returns empty catchers list.
There seems to be very little documentation about the actual semantics of instructions. I'm currently looking at the FILL_ARRAY_DATA instruction which stores constants into primitive arrays. However, I'm having trouble figuring out what happens when there are more elements provided to the instruction than what is the length of the array.
I've managed to run a short piece of code that does this and it (unsurprisingly) throws an ArrayBounds exception. The question is whether the data in the lower indexes were overwritten (i.e. it works like a loop; seems more likely) or not (i.e. all-or-nothing semantics), which affects the choice of instrumentation. I've written the following piece of code to decide which it is:
It has an array of length three, stores a tainted integer inside and then calls FILL_ARRAY_DATA with four elements which throws an exception. When that happens, the previously tainted element is retrieved and printed in the Log, which should show whether the value has changed or not.
However, pushing this through Dexter fails with this error:
which seems to be related to issue #13, though I am not sure whether this is a relevant piece of code or not, as it uses registers defined before an exception was caught. I've been trying to run this directly using
dalvikvm
command on the device, but I seem to have trouble running anything at all...