search

Cisco-Talos / DynDataResolver

221 stars 29 forks source link

Skipping setup code tracing #3

Closed adamprescott91 closed 3 years ago

adamprescott91 commented 4 years ago

This may be user error rather than an issue but any advice and thoughts appreciated... I'm trying to use this tool with a Go binary and I have set it to do a full trace on the main functions first basic block. The binary seems to execute > 200000 instructions before it gets to the main function which is 10 times more than the 20000 recommended value and as a result the information to send back from the DDR server gets close to 1GB of data which is unwieldy... Is there any way to specify not to log any information about address ranges or only log information for the basic blocks? As I currently understand the tool I don't think I'd be able to use it for binaries that do any significant amount of initial setup. It would be good to be able to specify the logging to only log the selected blocks and have the instructions to process limit be the number of logged instructions rather than the total number of instructions executed.

hunterbr72 commented 4 years ago

yup, I agree, would be good to be able to hand over a start offset, but so far this is not directly possible. I ll add it as a feature request. As a workaround you could add the basic blocks after the initial code manually to the basic blocks list (Select/Add basic block to basic block list) and then run a trace for the basic block list.

adamprescott91 commented 4 years ago

Thanks for this, I've now got another query / feature request that would be a time saver... When tracing the basic block list the query puts the maximum trace number against each basic block. So if I have 7 blocks I am interested in and I set the limit to be 20 instructions then each block gets the limit of 20 put against it. If none of the blocks reach 20 instructions traced then the trace doesn't terminate. To counter this it would be great to do two things: 1 - Set a server side timeout. So if the sample has been executing for more than the server side timeout then the DDR server stops the trace and returns any information it has gathered so far. As the timeout is only client side at the minute if a sample doesn't max out the trace limit then a lot of the time the trace doesn't return anything even when extending the timeout for the client to large values. 2 - Set the instruction limit to be the total number of instructions traced for all blocks rather than for each block. If my block list has 7 blocks and each of them is relatively small I could quickly up the limits from 5/10/20/40 to get to a useful trace size with the blocks I'm interested in whereas currently I have to go work out how large the block in in instructions and how many times I am expecting the block to execute to set sensible trace limits which is a lot more manual effort than just running the trace 3 or 4 times and seeing if I have made it to all of the wanted blocks yet.

hunterbr72 commented 4 years ago

@adamprescott91 thx for the idea, I ll look into this after DefCon ! Pretty busy times itm ;)

hunterbr72 commented 3 years ago

@adamprescott91 check out the new features in 1.0.2. maybe not 100% what you were looking for but at least 80% hopefully. I will release a detailed blog about it this afternoon.