Providing additional information about entities (Procedure/Block/Instruction/Memory) ?

[nemerle]

Considering that heuristics are used in many places, and the fact that sometimes humans actually "know better" :smile: what would be a good way of passing usable additional information to the engine ?

Non-exhaustive list of things we might want to do manually:

• Marking procedure as _does_notreturn
• Marking procedure as _librarycode - thus it's code will not be decompiled
• Adding procedure preconditions ( assume ds==0xC000, assume sp==bp, etc )
• Adding block preconditions ( essentially same as procedure preconditions )
• Adding jump targets ( when automated indirect jump resolution fails )
• marking a piece of undecoded binary as data ( primitive and complex types ),
• marking a piece of undecoded binary as code ( essentially adding given address to scanner queue)
• marking data/code as undecoded in cases where scanner made some mistakes

This should help solving #9

[uxmal]

1. the ProcedureCharacteristics class has the property Terminates. No UI for editing it yet.
2. The serialization format class Procedure_v1 has a Decompile flag that is intended to control decompilation. No UI for editing it yet, and I don't think it is respected by the scanner. Should be easy enough to implement
3. Procedure preconditions were added yesterday. 4.
4. Require selection capability in the TextView class (see #30 for details)
5. Is implemented today. Try selecting a memory range and right-click on it, then select "Mark Type"
6. Is implemented today. Right click on the starting byte of the procedure in the memory view and select "Mark Procedure Entry"
7. Should be doable, but would need to be done carefully to make sure the call graph doesn't get horribly confused. So, if I have a procedure at address 0x1200 that contains call 0x1234 instruction, the scanner scans the procedure at 0x1234. If you then mark the code at 0x1234 as undecoded, what should happen to that call in procedure 0x1200?

[nemerle]

ad 7. Ah. 'fun' part -> we'd need a 'todo list' of conflicts :

- instruction at 0x1200 is a control transfer but target address (0x1234) is marked as unknown
- instruction at 0x1204 is a control transfer but target expression (ax+0x12) cannot be computed
- function (fun_1020) at (0x1022: call fun_1000), tried to assume (ds==0x5000) on (fun_1000) but it was already set to different value by a previous call from (fun_1010) at (0x1016: call fun_1000).

[uxmal]

1. Should be able to mark the signature of a call site, so that indirect function calls can be used in type inference. E.g. seeing the instruction call [eax+020] the user should be able to mark that as (function __cdecl (int, int) => float) to indicate the type of the virtual function being called.

[nemerle]

Unless we can mark eax as a pointer to vtable struct which has something like :

offset 0x20: -> float (*__cdecl virt_member_20)(int, int);

in it's typedef, and can handle this kind of things :smile:

[uxmal]

Yep, that would also work. Still depends on #30, i.e. being able to select a line of code and or register and give it an annotation.

[uxmal]

• [ ] the ProcedureCharacteristics class has the property Terminates. No UI for editing it yet.
• [ ] The serialization format class Procedure_v1 has a Decompile flag that is intended to control decompilation. No UI for editing it yet, and I don't think it is respected by the scanner. Should be easy enough to implement. Marking a procedure as a no-Decompile should probably require that the user enter the function signature.
• [x] Procedure preconditions were added yesterday.
• [ ] Setting block / instruction preconditions requires support from TextView (see #30 for details)
• [x] Marking a memory range and setting its type Is implemented today. Try selecting a memory range and right-click on it, then select "Mark Type"
• [x] Marking the entry of a procedure and scanning it implemented today. Right click on the starting byte of the procedure in the memory view and select "Mark Procedure Entry"
• [ ] Marking a section of memory and removing it from the data or code graph needs to be done carefully to make sure the call graph doesn't get horribly confused. So, if I have a procedure at address 0x1200 that contains call 0x1234 instruction, the scanner scans the procedure at 0x1234. If you then mark the code at 0x1234 as undecoded, what should happen to that call in procedure 0x1200?