Guys, new version of plugin which now can work with 3.0 beta and has some more tricks. Author announced beta-testing period. So we all are interested in making it our best.
You may download it from
hxxp://www.wasm.ru/toollist.php?list=10
or from Sten site.
THEN, PLZ, make you comments either here, or at exetools.com, or at wasm.ru ("link "Комментариев"" or writing directly to Sten.

Sounds good, just what i've been looking for, but the download on wasm.ru and also Sten's homepage still only seem to be version 0.25.

Hopefully new version will be available soon.

Downloaded and using it on xp (driversuite 2.7).

Hides si well (must say it tells it's version 2.5 ??)

(SSssttt... before alex adds it to his new aspr version)

SpeKK.

Sorry, guys!!!!
I corrected everything. Download it again! Sorry!

volodya !

Did you improve BPR! instruction with IceExt, when I last time spoke to Sten he said he wasn't satisfied with that, and that should be corrected.

Thanks for the updated link it now downloads version 0.30, i installed this and run it ok on softice 4.3.0 build 1126, but after leaving softice and using os for a few mins i got another KeBugCheck, what is best way for me to catch these and report info back, i have turned FAULTS ON command in softice and will add info if this happens again.

Thanks for all your efforts

--
bedrock

Hi All

Thanks for the update and this has been impressive ongoing work by Sten. The BPR command looks to be a work in progress still, but the basic functions seem to be there. A working BPR command raises some interesting possibilities to log all instructions executed within a range of code, similar to the Backtrace feature in Win9x.

The Int 0E page fault handler for the BPR function currently emulates the faulting instruction then pops up Softice and outputs CR2 (linear address that caused the page fault) and CR3 (page directory base address) to DbgPrint, before returning control.

If the function had a "T(race)" flag the handler could instead dump the cs:eip address of the faulting instruction to a file for example with the NT Kernel equivalent of IFSMgr_Ring0_FileIO. This dump file of addresses could later be disassembled in the same memory context as the program to provide a text output of the executed instructions. This is essentially how the Backtrace feature works, each traced instruction is dumped as 7 byte addresses (ring, cs, eip) to memory and disassembled later by Softice when you type SHOW.

This could even be done outside of IceExt by a small loader/disassembler application. If a duplicatable CRC check was done on the PE header or small section of the OEP code of the program being run, and written to the start of the file by a small procedure when the BPR "T" breakpoint was set, it could act as a check on the file when being opened by the external loader/disassembler app.

Ideally you'd like to record the opcodes at the instruction instead of the address, because this would ensure any code overwritten later by the program would not be lost during the (static) disassembly of the addresses from the file by the loader application, and you would get a true run-time disassembly of execution. But this implies having the disassembler function within the interrupt handler, which is far from ideal, or at the minimum recording irrelevant opcodes.

Instead of popping up Softice the handler would have to quietly emulate the instruction and return control flow to the program, after writing the address to file of course. If the BPR is still active it should break on the next intruction if it's also in the breakpoint range set, and the cycle continues. There would still need to be a way to popup softice so you could turn off the BPR trace manually and this would have to be handled by the user with a regular BPX breakpoint, which is the "end-point" of your Backtrace.

Having written a similar app with Clandestiny to disassemble the Win9x Backtrace output I feel this is a *very* viable option to be integrated into IceExt perhaps as a plugin, once the BPR command is confirmed working well. It will be interesting to see the development of this nice Softice extension..

Regards,
Kayaker

Well, thank you for the brilliant explanation.
I told to Sten about this topic, so when he has time, hopefully he will take a look at it.

thanks your great tool,it helps me a lot,but it still some mistake here
1 . dumpscreen error in my computer because of
if (sscanf(args, "%s", FileName) != 1)
{
// invalid parameter, display help
help_DUMPSCREEN();
return;
}
when i type !dumpscreen \??\c:\dump.bin, it always show me the help, and i just change it to
sscanf(args, "%s", FileName)
then all is ok

2 . still int 3 error here
BackDoor:
jmp [OsInt3] ; call ntoskrnl!Trap03 // we can't jump to there!!!

All_ok:
jmp [OldInt3] ; call ntice handler

if we jump to ntoskrnl!trap03, we will aways crach when we put a bpm on esp ( f7,then bpm esp, g, then system crash),and some time the bpr will crash too, so i changed si,di or ebp to fake the program,then jmp to ntice int3 handler

u can just use dillodump (v 2.50 or 2.55) to test int 3, when stop on EntryPoint ( if we already BPINT 3 ), just single step"t",then "bpm esp",then "g","g", serverial times later, we will met a system crash, it always happen

i don't know why, maybe because i modified others code cause this happen, but i still like to use !unhook to hide softice from UnhandledExceptionFilter check

thanks for you and your great tool, it help me a lot

Kayaker wrote:


If you are speaking about IceExt Int 0E page fault handler - currently it set the TF flag, turn some flag in SoftICE so debugger thinks it's tracing the faulting instruction and then returns control.
Faulting instructions is actually traced and SoftICE popups AFTER that instruction.

The only reason SoftICE popup is nessesary after every faulting instruction - SoftICE activates it's breakpoints when you are leaving the debugger. So I am able to activate BPR's again.

Your ideas are very interesting but at this point I am conserned about a method to skip the faulting instruction. The only working idea seems to write good ring-0 tracer that will deactivate BPR's, execute instruction then activate them again.

The _Emulate branch in int 0E handler currently never executes.

2pLayAr:
Thanks for your remaks.
I wrote
-----------
if (sscanf(args, "%s", FileName) != 1)
-----------
because new M$ super tool PREfast barked I must check the value returned by sscanf. Frankly speaking NuMega has an awful implementation of sscanf (yes sscanf located in ntice.sys).
I also had some problems with !dumpscreen.
I'll fix bugs your mentioned as soon as possible.

!unhook command does not intented to hide SoftICE. It removes almost every SoftICE hooks on system api. So you'd better use !protect command.

Hi,
I'm using WinXP pro and DS 2.7 .
I got blue screen when I tried to load IceExt v0.41

DRIVER_IRQL_NOT_LESS_OR_EQUAL

eax=ffffffc0 ebx=00000000 ecx=f5c846b1 edx=00000037 esi=f5c874bc edi=f5c87893
eip=f5c84760 esp=f9e78c4c ebp=f9e78c64 iopl=0 nv up di ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000086
IceExt+0x1760:
f5c84760 c600e9 mov byte ptr [eax],0xe9 ds:0023:ffffffc0=??

STACK_TEXT:
frames may be wrong.
f9e78c64 f5e0b14c f5c83000 f9e78c84 f5e0af72 IceExt+0x1760
f9e78c70 f5e0af72 f5c83000 81967198 e20bd09e NTice_f5d95000!ui64toa+0x15986
f9e78c84 f5ec75ce f5ec75c0 81967198 805acfe9 NTice_f5d95000!ui64toa+0x157ac
f9e78ce4 00000000 ffb3b4c0 ffffffff 01000100 NTice_f5d95000!adjust_fdiv+0x21cf6

The latest is 0.42. Maybe that will fix your problem

Same happend with v0.42

Hi,
I have changed my boot logo and my kernel filename is Logo.exe instead of ntoskrnl.exe . IceExt can't find the kernel , when I changed the kernel back to ntoskrnl.exe it worked . it should try another way to find kernel ...

Thanks, I do aware of this bug.

It seems BSOD occures when IceExt hooks something. But I cann't say where exactly error is (in fact I have no IceExt 0.41 anymore, so your report is useless . I decided to publish debug symbols with IceExt to help in debugging.