Hi Kayaker/Clandestiny/Others:

I came across a reference to this tool and I wanted to take a look at it. Could you please tell me where I can dl a copy of it? I search the board and found "two announcements" (one in the Newbies and other in ToT by Kayaker) but unfortunately both does not have either an URL or a dl link.

If my reading is correct, and if the tool does what I *think* it does: bye bye nags and bye bye time-trials *lol*.

/me have an idea, i guess

Thanks,

Signed,
-- FoxThree

Patience my friend

LOL, actually we've been having discussions about the future of the backtrace disassembler in recent days. I've been neglectingly lax about it since I got back from holidays and fighting waning enthusiasm, while Clandestiny has been going great guns, school work be damned, and is doing some groundbreaking work on patching interrupts within the winice backtrace routine and using asyncronously linked lists for file I/O within an ISR to allow for potentially unlimited backtrace sizes.

Needless to say, the monster has grown, evolved and mutated, and still needs a bit of taming. Despite the fact this should be a vast improvement in the usefullness of using the Softice backtrace in Win9x, Numega has *still* not been forthcoming in providing us with funding, assistance or source code! Damn them all to hell anyway ;-)

"bye bye nags and bye bye time-trials"?

Quite likely with correct usage, since it should allow the user to conveniently compare codeflow of traced regions under the conditions of expired/not expired. The hope is it will be used as much as a research tool for documenting program execution, within the limitations of the BPR function, but that will be up to the end user of course.

Guess this means my ass has been kicked to get back to work Clandestiny , and you're now officially on the beta testing team Foxthree

Cheers,
Kayaker

LOL...

Hmm.. does it work on win2k, kayaker? My computer is itching for some BSOD as well :>...

Cheers mate ...Nice to have you back on the team Kayaker.



Sorry, binh81 but I have to report that win2k is not supported *yet*. If Kayaker and I still have enthusiasm and the first version is well recieved, we have plans to eventually offer win2k support. Being as the current implementation is a VxD and exploits ring 0 privlages, it would take a considerable reorganization of code to make this work on Win2k. As Kayaker mentioned, the code is actually in a state of flux right now.

If you're interested in a few of the gory implementation details that Kayaker alluded to, the winice backtrace buffer is circular and as such when the buffer becomes full, it "wraps around" back to the beginning. This can result in a loss of recorded trace information if you don't have a large enough allocated buffer size. What's more, the winice backtrace buffer is contiguous memory and the "requested" buffer size (in winice.dat) may not be able to be allocated, leaving winice to give you what it can based on the available contiguous memory on the system. I'm using interrupt hooks in winice code to intercept this "wrap around" condition and rescue the buffer "on the fly" by saving it out to disk.. (trace execution is suspended while in the ISR). Unfortunately, writing to disk is not allowed in an ISR so it becomes necessary to save the buffer in memory and request a callback event for the actual disk write. Unfortunately, winice is no longer suspended as soon as we leave the ISR and the actual disk write may not occur until some time later. To combat this, we're trying synchronize the callback with a queue of dynamically allocated linked lists that holds the saved buffer information. The callback works on writing the queue of saved buffer info out to disk and the fact that we're using linked lists (small memory chunks chained together) means we don't need a giant block of contiguous memory to save the buffer in which gives more latitude before the user runs out of memory. Even so, there is always the caveat... It is unknown weather writing to disk is slower than the execution time of the backtrace AND the time it takes to save the buffer into the linked list in the ISR. Since only a single callback can be running at a time writing the queue to disk (for synchronization reasons), it remains possible that we could allocate memory at a rate faster than we can write to disk and free it...

If this scheme works, it will actaully extend the winice bactrace buffer functionality because the user would be able to theoretically use an arbitrarily small buffer to dump unlimited size traces. Another interesting possiblity we've discussed is the potential for "real-time" buffer dumping using our int hook scheme. You see, it's possible we could rescue the buffer instruction by instruction and disassemble it on the fly rather than waiting until the trace is complete. This could potentially be useful in the cases of packed or SMCed targets where the prog overwrites some of its own address space. In these situations, not all of the addresses in the backtrace necessarily point to valid instructions because we are disassembling the dump after the trace is over and some of those aaddresses may have already been overwritten.

OK, I'm probably rambling here... It's gets very convoluted to try to explain BTW, this scheme is entirely experimental right now. Preliminary results are promising, but it will take much more testing and debugging to verify any kind of stability. Likewise, this is the first VxD either myself or Kayaker have ever written, so this whole project continues to be a "learn as we go"/ "learn from our mistakes" kinda thing You guys will be on our beta test list , but it may be a few weeks since I've got final exams next week and limited time to play RCE. School work can only be damned for so long

Cheers to all,
Clandestiny

Hi Kayaker/Clandestiny:

Thanks for sharing your thoughts on this and giving a "inside look" Ofcourse, glad to be a part of the beta test team always ... And Kayaker, you got me there when you mentioned about comparing code flows

Binh:

Greetz, friend.

Signed,
-- FoxThree