forked from xoreaxeaxeax/sandsifter
-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question in the deeping algorithm when the instruction length changed #8
Comments
It may well be incorrect, Perhaps I'm just misunderstanding where the
confusion comes in.
```
if (result.length!=inj.last_len && inj.index<result.length-1) {
inj.index++;
}
```
This code checks if the return result.length (result_t struct) is not equal
to the last injected instruction as determined by the address estimate in
the fault_handler() {insn_length}
and also checks that the index is less than the result length -1
Meaning Instruction length has changed in the fault handler.
So it increments the instruction index.
Later it naively assumes that no more valid instructions are to be found in that set if this is no longer the case and moves on to the next. Like the comment says this is not ideal.
Let me know how you understand the depth search.
This is all part of the move_next_instruction() function which is called
recursively and needs to be improved anyway
Excerpt of comment in code:
```
/* not a perfect algorithm; should really look at length
* patterns of oher bytes at current index, not "last" length;
* also situations in which this may not dig deep enough, should
* really be looking at no length changes for n bytes, not just
* last byte. but it's good enough for now. */
/* if the last iteration changed the instruction length, go deeper */
/* but not if we're already as deep as the instruction goes */
//TODO: should also count a change in the signal as a reason to
//go deeper
```
But I need to take a close look at this (and really the entire project) and
run some assessments and compare against expected behaviour cases.
…On Fri, Dec 21, 2018 at 9:50 AM Billwyz ***@***.***> wrote:
in injector.c: (L995:)
if (result.length!=inj.last_len && inj.index<result.length-1) {
inj.index++; } inj.last_len=result.length; inj.i.bytes[inj.index]++;
According to this, when the last iteration increases the instruction
length, inj.index goes deeper only one byte and then do the increment
from this byte, which is different from the deep-first instruction search
algorithm described in the whitepaper that deeps to the end of the
instruction.
Is this implementation reasonable, and if so, how shall I understand the
principle of deeping only one byte no matter how long the instruction is
lengthened in the last iteration.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#8>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFc5bDQ0p33UlUZRd8mwza2GZj4-bcIrks5u7JK7gaJpZM4Zdh4e>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
in injector.c: (L995:)
if (result.length!=inj.last_len && inj.index<result.length-1) { inj.index++; } inj.last_len=result.length; inj.i.bytes[inj.index]++;
According to this, when the last iteration increases the instruction length,
inj.index
goes deeper only one byte and then do the increment from this byte, which is different from the deep-first instruction search algorithm described in the whitepaper that deeps to the end of the instruction.Is this implementation reasonable, and if so, how shall I understand the principle of deeping only one byte no matter how long the instruction is lengthened in the last iteration.
The text was updated successfully, but these errors were encountered: