|
From: Howard C. <hy...@sy...> - 2010-01-28 16:51:11
|
I have a chunk of obfuscated code that I'm trying to unravel. There are layers and layers of misdirection piled onto it. It struck me that I could use memcheck to cut through a lot of the BS - I can invoke the obfuscated function with explicitly uninitialized input data, and then let memcheck's validity tracker keep track of everywhere the input data actually got referenced. Ideally I'd like to have a trace printed of every instruction that touched a bit of input, and so get a record of every step that actually contributed to the bits in the output. Currently memcheck doesn't nag about every uninit reference, and it sets the V bit to avoid repeated nagging after a flow-control event. It seems like it should be pretty trivial to tweak it to do what I want. Was just wondering if anyone has done this before, or is interested in it. I'm thinking of adding a client request to enable this behavior. (I don't want it at startup, because there's a lot of crap in libc etc. that I want to stay out of sight.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ |
|
From: Howard C. <hy...@sy...> - 2010-01-29 06:50:41
|
Howard Chu wrote: > I have a chunk of obfuscated code that I'm trying to unravel. There are layers > and layers of misdirection piled onto it. It struck me that I could use > memcheck to cut through a lot of the BS - I can invoke the obfuscated function > with explicitly uninitialized input data, and then let memcheck's validity > tracker keep track of everywhere the input data actually got referenced. > Ideally I'd like to have a trace printed of every instruction that touched a > bit of input, and so get a record of every step that actually contributed to > the bits in the output. > > Currently memcheck doesn't nag about every uninit reference, and it sets the V > bit to avoid repeated nagging after a flow-control event. It seems like it > should be pretty trivial to tweak it to do what I want. Was just wondering if > anyone has done this before, or is interested in it. I'm thinking of adding a > client request to enable this behavior. (I don't want it at startup, because > there's a lot of crap in libc etc. that I want to stay out of sight.) > Well, the initial approach was a dead end. The 2nd uninit reference is doing a table lookup based on the input bytes, and those values are constants so the trail of uninit'd accesses ends there. I guess I may need to write a custom tool for this purpose instead, tracing the chain of events from an input byte thru all of the actions triggered by it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ |