Hi All,

Well, after some digging into the bowels of winice I found the source of the problem of why the DriverStudio versions of Symbol Loader don't break at WinMain. Rather than patching winice I found a spot to set a flag in Nmtrans.dll instead. I'll detail what's going on later, so it can be adapted to other DS versions, but for now I just want to make sure it works for others as well.

This patch is ONLY for the DS2.7 Nmtrans.dll version, file date 6/20/02, file size 544,853 bytes. I was working on Win98SE but I hope it works on Me and XP as well. Lemme know if it's OK...

EDIT: Updated patch compatible with all DS versions is in a later post.

Kayaker

Mr canoer, I am very proud of you and thank full for your efforts. your fix works for me in DS 2.7 winXP. I will let you know about DS 2.6 and W2000 in a few hours.
( I will try to understand what you did to DS2.7, that is what I mean)

Patch is ok on win2k!
Great work!
Looking forward to the explanation.

/Manko

All right, cool. It's a simple 3 byte patch, though the reason behind it is a little more involved. I'll explain some of the winice stuff later, but here's the patch point, which is universal in all versions of nmtrans.dll. Where the difference lies in DriverStudio is within winice.exe itself, but patching this takes care of that. The checkbox feature to turn breaking on WinMain on or off still seems to work as well.



Actually, I'll fix the patcher so it's universal for all DS versions, give me a few hours...

Well its about time someone figured this out congrats Kayaker! Some information on why eax = 1 is better than eax = 0 - ffff would be interesting and what eax represents here not to mention what the value typically is when it doesnt work and how it gets set in the first place hehe. Very nice work though its about time DS 2.7 works completely

Snatch

Edit: Well silly me I forgot to tell you that it worked and on WinXP Pro with SP1

nicely done.:-)
Unfortunately it didn't work on my system. (DS 2.7, and correct nmtrans.dll, winXP Pro with sp1 installed),

I have just tried it on WinME, still no luck. When I put a breakpoint on the adress where nmtrans.dll has been patched, softice doesn't even break. A possible solution or explanation would be nice...
Do you guys have symbols loaded in the loader when you run it? I have that on the XP system, but not on the WinmE system. Either way, Sice doesn't break at programstart.

All kinds of input will be appreciated...

regards,
hobgoblin

Very nice ,

Congrats to you kayaker.
For me its working great on windows XP corp with servicepack 1

lownoise

congratulations : nice one m8

works for me on win 2k sp3 ! many thanx

regards

Cheers,

I'm off to buy XP and DS 2.7 to test it... ()

jimmyclif, ltns

cool!, thanks and nice job !!

sorry, forgot to say its working fine on 2.6....

Shucks, if I had known it was going to be so popular I would have made it shareware! Oh hell, who am I kidding? With this audience? ;-)

OK, here's an updated patch which *should* be universal for all DS versions. It does a byte scan for the unique string immediately after the patch point
50 push eax
8B4DDA mov ecx, dword ptr [ebp-26]
51 push ecx
instead of using an absolute offset. This code is identical in DS2.7 and SI4.05, so I'm assuming it is for everything else in-between as well. Please let me know if you find otherwise or it doesn't work.

I also changed the patch itself slightly from the earlier one. Either instruction patch works OK, this 1-byte patch is just more 'logical' as you'll see, no need to update it if you don't want to. This updated file also contains the *brief* explanation to follow, as well as the patcher source if anyone cares to look at it.


Hobgoblin, I hope you can sort out what the problem is, hopefully comparing system notes with others might solve it. If not, and if you like, we can go through the Softice code and see if it's taking the proper "path", at least through this part of the code. I've got all the jumps and such logged, plus the proper way to get into the code, so we might be able to at least eliminate one source of the problem...

To Snatch, Oh Ye of the inquiring mind and many questions :-) I don't know if this explanation will answer all your queries. Perhaps a reversing + results session is in order. The good stuff starts with NmSymLoadExecutableEx where the PE file is mapped into memory and the entry point found in a usual manner. Let us know what you find

JimmyClif, you will let us know the "official" reason for DS not breaking at WinMain then? ;p

OK, here's the new patch, do what you like with it.

And the explanation:

Ever since the DriverStudio versions of SoftIce came out people seemed to be having problems with getting Symbol Loader to break at WinMain. As it turns out there is a small difference in the winice driver from earlier versions in the routine which sets the "CC" breakpoint on the program entry point. This patcher fixes the problem by making a small patch in nmtrans.dll and should be universal for all versions of DriverStudio. Here is a *brief* explanation of the source of the problem...

============================================
To start with, here is the patch in the DriverStudio v2.7 nmtrans.dll. By changing the 1 instruction we affect a variable used in winice, and *ensure* that Symbol Loader will break at WinMain.


==============================================


The nmtrans.dll function DevIO_SetWLDRBreak is used to communicate to the winice driver via a DeviceIOControl call that the user wants to break at the program entry point. The DevIO_ConnectToSoftICE function opens the vxd in the usual way with CreateFileA and returns a valid handle. Then DeviceIOControl is called, pushing the dwIoControlCode (9C40601C) for the proper function within the winice vxd to set the "Stop at WinMain" flag. For more info on the functioning of nmtrans.dll, see IceLoad by The Owl, G-RoM and Muffin.


This unique dwIoControlCode (9C40601C) in nmtrans.dll is our "ticket" into the correct function in winice itself. (All addresses are from DriverStudio v2.7)

...
_text:1001FFBD push 9C40601Ch ; dwIoControlCode
_text:1001FFC2 push esi ; hDevice
_text:1001FFC3 call dseviceIoControl ; communicate with winice


A search in winice.exe reveals the following code:

What all this boils down to is getting the correct Index value of 09h in ECX. The JMP statement address then becomes C0007E10 + [09h*4], which leads to:

:C0007E34 dd offset loc_0_C0000928 ; main function called by DeviceIO_WLDR

Following the code...

That middle variable, dword ptr [eax+8], is going to turn out to be the critical one. It is moved into CX, then later into a small buffer containing the name of the program to be loaded, the "CC", some other flags and the word WINMAIN.


Now comes the major difference in the code between DriverStudio 2.7 and Softice 4.05, and the how and why that patching that instruction in nmtrans.dll works. Basically all we are doing is duplicating the code that existed in the 4.05 version.




This is basically the crux of the matter, but certainly doesn't convey the complexity of the Softice code or give an appreciation of the true excellence of the debugger. Getting lost in the codewoods is the only way to do that ;-)

Enjoy the patch

Kayaker

So like why the value 0xffff? Besides that it's equal to v4.05 and (by luck?) works I don't see the explanation/reason why you want this value.

// CyberHeg

coool !!! but it doesn't work on my system xp pro with sp1 installed and Softice Driver suite 2.7. So I'll be enjoy to watch your log and try to fix this.

Okey.
I have traced the nmtrans.ll, and it passes over the patched area, the patched value is placed in memory, the program goes on to where the api DeviceIOcontrol is called at 1001FFC3 (kayakers address). But then the program starts, it doesn't halt at starting point. I'm not sure how to go from here. I guess I have to trace winice.exe from here, but how to enter it at the right place?

another thing: How did you get to dissamble the winice.ece in IDA? I mean, I tried it myself, but couldn't find any addresses below appr. c0000600. I certainly couldn't find the address you posted (from :C00007B0 and so on..)

hobgoblin

Give the new iceload a try, it comes with some patches for ntice.sys that may help you.
Did you make sure that you loaded the LE/VxD part into IDA and not the MZ stub only?

thanks for the tips.
The dissambling in IDA is now okey. I found the code I was looking for.
But I don't need iceload. I'm primarely interested in understanding why kayakers patch is working for almost everyone except me.:-) I have used Lordpe and bpint3 successfully earlier on to break at program start, and are mostly happy with that.
I will check it out though. Maybe there is something to be learned there too.
Now I just need to find out how to break into winice during runtime.
Maybe someone have a nice tip?

Later: I got it to work on WinME now. Seems like kayakers patch didn't do the job, because when I checked the instructions at the address 1001CD7A, it read mov eax, 00000001. After changing it to mov eax, 0000FFFF it worked.

Now, only XP remains unresolved...

hobgoblin

Probably talking rubbish here so don't have a go, did you patch both dll's?

Yes, I did.

hobgoblin

hobgoblin,

On my Xp box softice breaks on the winmain with the following configuration.


Make sure softice is not activated.

Start de symbol retriever and download the symbols for ntoskrnl.
Edit your settings so that by the softice initalization the symbols are loaded for ntoskrnl
apply Kayaker patch for driverstudio
Reboot your system and start softice. Now try breaking on winmain.

Hopes this helps

Lownoise

No, it doesn't work on my computer.
Thanks for the tip, though.

Looks like I have to do some debugging of winice.exe/vxd. I have tried a little bit, but can't find a way to enter the code. Tracing only leads me into an endless codestream of the system .dll's, but no winice.....
You don't happen to know how to get into winice itself, do you?

hobgoblin

No i don't know how to get in winice/vxd

Are there any other using XP and having the same problem or not?

Lownoise

Hiya,

You can use IceClimber to set breakpoints in winice code. It is available on protools.cjb.net.

Cheers,
Clandestiny

Hi Hobgoblin,

I was looking into this last night for the ntice.sys versions. I'm not at my home computer right now so I can't paste the exact details, but here's what I noticed. I unpacked the DriverStudio Data.cab file and saw there are 4 versions of the "winice" driver. Which one is installed on your computer I guess depends on your OS. There is winice.vxd, for Win3.1; winice.exe, for Win95/98, and 2 versions of ntice.sys, presumably for Me/XP/NT. I'm still using good 'ol Win98SE (where BPR and Backtrace still works, yeah! ;-), so the driver I was working with was winice.exe.

So I disassembled the two ntice.sys versions and noticed some differences and some similarities to what I saw with my winice.exe driver. To start with, the CMP instruction to the dwIoControlCode (9C40601C) is a direct one, instead of using the shr/and manipulations and a jump table. So a text search in IDA for '9C40601C' will give you a direct hit.

What I had done to break into winice code was to set a breakpoint on a very handy VMMCall that luckily happened to be just above the code I was interested in, called _EnterMutex. So basically I was using only 2 breakpoints, bpx DeviceIOControl, then bpx _EnterMutex. Return from _EnterMutex and you are directly in Softice code.

If you check your ntice.sys version, you'll see there is a similar call somewhere above the '9C40601C' cmp instruction. I forget the exact name of it right now but it's recognizable as a Mutex call (and pink in IDA). It's not a VMMCall per se, but it is an external call, so you may be able to set a breakpoint on it directly as well. In fact it may actually call down to VMMCall _EnterMutex and simply be a wrapper, I don't really know anything about how the WinME-and-above kernel is different from Win98, so that's only a guess. In any case, you could try setting a bp on this system call and see if Softice breaks.


It is a bit of a pain because you generally have to F8 through everything. For example if you try to F11 out of the _EnterMutex call back to winice code, you'll get the familiar "Breakpoints not allowed in Softice" message. Unless you've patched winice beforehand to allow breakpoints within its own code that is. Unfortunately Iceclimber only works on 4.05, but I've mentioned how that's done in another thread and you could probably apply permanently your own patch to your own version by following that idea. Even then, setting direct bps on winice code doesn't always seem to work, I've had both success and failures when it comes to that.

Also, F10-ing over calls may or may not work for you either. With 4.05 (which I had patched to allow breakpoints) I was able to F10 over any call it seemed, but with DS2.7 (which I hadn't) I found F10-ing over several calls simply started the program up, again as if Softice was unwilling to RET to its own code. (This didn't apply to system calls though...) And finally, I have no experience in single stepping through ring0 code in ME/XP, so I don't know if there are any hidden dangers lurking, heh.


Anyway, try breaking on that Mutex call (you should be able to see it in IDA), and set the bp *after* you've first broken on DeviceIOControl, else you'll probably get the wrong break. One thing you might want to check first is if DeviceIOControl is even returning the correct values. Set a bp on the address in nmtrans.dll immediately after the call, I think EAX returns 1 and EBX should be 0. This might be a bit of a wild goose chase. I don't really know *what* that FFFF flag does actually or what it stands for, just that it's associated with manipulating the "CC" and patching it seems to work (for most people anyway ;-)

Your problem could be further on as well, after returning from DeviceIOControl there are critical calls to CreateProcess then ResumeThread. I know these are the basis behind the idea of "code injection" for example, and I want to continue to trace within them to see, if possible, exactly how and where the "CC" is physically written to the entry point and how it all relates to the PE Loader. (There's an interesting call to CreateRing0Thread that I want to know what it's doing ;-)

Hope it works,
Kayaker

Hi Kayaker,
Thanks a lot for the input. I will dig into it and hopefully get deper into what's going on.
I'll get back to you (and others) with results later on...

thanks for taking the time pass on the information.

hobgoblin

The breakpoint at least for me is set by DR registers.
Tracing and disassembling with IDA both versions (9x and NT/2K/XP) shows a lot of similarities.
On 9x Im able to trace 100% with TRW2K and it certainly is a BPM X type For example set all 4 registers with BPM X before launchin file
(for example BPM 1 X, BPM 2, BPM 3 X, BPM 4 X )
and the internal_DRregs_table of ICE being full, the loader doesnt break at OEP.
Im not sure that if it doesnt try after seeing the table full(i.e. all 4 regs used) to put a CCh , but fails for some misc reasons

The flag you noted is newly used in structure modinfo (see iceload code).Im sure that the best would be to update iceload at iceload 1.8 beta with that flag set (modinfo.0x132 or 0x134 forced 1, as I remember).See iceload sources
Only if the stricmp with symbols winmain, winmain16 etc fails in ICE driver code they are used as I see now.

Also studying icedump shows that the bug with first non executable section can be ported easily on NT version as it its very similar code.This would solve also the packed files which
have 1st sect marked as nonexec.I have patched DS 2.7 NT version and tested on XP (a la icedump9x) and works 100%.
Tested on the fly DS 2.6 on 2k and everything is ok.
Further studying inc files of icedump and nticedump, I realised that they contain a lot of info and I wrote 2 IDC scripts for IDA to parse them and propagate the info in disassembly.Very useful.
Also the easter egg in DS 2.5,2.6, 2.7 is obtained typing ver jim
in SICE.Being used by now with IDC scripts I wrote other 2 scripts to decrypt these strings in IDA disassembly.I will attach the scripts but please note (they are very bad hand coded not optimized etc.
but they simply work..this is the most important thing..
The bp seems is set via INT41H debbuger's interface.
I have tested DS 2.6 on 98SE , DS 2.6 on 2K, DS 2.7 on XP SP0
with all these and everything works as expected.
I can also upload the patch for DS 2.7 for nonexec 1st section but Im sure you can do it by using the scripts to auto comment code based on INC files of icedump, nticdump.

Attached are the IDC scripts.Use them to propagate the info from INC files in the correspondent disassembly version of SICE (9x/NT).

You have done a really gr8 job but its not nessacery all u need to do is change an option in symbol loader and u r done ill tell u where:

Load a Module
now go in the Menu to Module-->Settings

in General tab u should choose Load Executable and check Stop at WinMain,Main...

now in the Translation Tab choose Symbols and source code

Press Apply and ok and click on Ctrl+L now sometimes it wont ask u: "An Error occurd blablala. Load Executable anyway?" and ofcourse we enter yes and it will break, if this messsage doesnt appear just go again to Module-->Settings and press ok try Ctrl+L again should work if not go again to Module-->Settings press ok and Ctrl+L the max time i needed to go to Module-->Settings was 3 times so its not that bad give it a try Good luck and Kayaker u really have done a gr8 work 10x for all your efforts

Well, here I am once more.

I have patched ntice.sys so I can enter the file without getting the message "No breakpoints allowed...". I did follow Kayakers advice. I checked the return values of the call to DeviceIOControl, and eax returned 1 and ebx 0. I managed to get to ntice.sys through breakpoints on DeviceOIControl and ExAcquireFastMutex. A F11 after breaking on ExAcquireFastMutex brought me there. But when I try to set a bpx or bpm in the code immediately after the point where I entered the code, nothing happens. And when I try to trace (F10 or F8), my machine reboots after executing a couple of instructions (right after the call after the call from ntice.sys to ExAcquireFast Mutex).
Why does it reboot? And why doesn't breakpoints stick in the ntice.sys code? I know of the program that makes breakpoints in Sice possible, but as far as I know I can't use it on DS 2.7.
Any good ideas out there?

hobgoblin

Hi

Your whole system reboots eh? There was one very strange occurrence I had, which I didn't bother mentioning before (wasn't sure it'd come up , but in looking at the ntice.sys code I'm wondering if something similar isn't happening to you since it seems to occur at around the same place. There was a single mov [address], 01 instruction which froze my system if I tried to step over it. I actually had to nop it out to continue tracing. Once that single instruction was memory patched once, I was OK until reboot. Even if I tried to edit in '01' to the memory address the system froze immediately. For some reason this addy seemed unwriteable if you tried to single step over the instruction. The situation was identical with 4.05 or DS2.7, with the winice.exe driver on my Win98SE system.

There were no adverse effects to nopping it out and all other tracing was OK. The instruction occurs just after Install_Exception_Handler, where 01 is moved to the memory address, and is cleared with a mov 0 just before the same EH is removed with Remove_Exception_Handler. So it looks to be a fairly inconsequential flag.


Here's what it looks like, and since you said the problem was right after the call after the call from ntice.sys to ExAcquireFast Mutex, why I thought it might be the same.

winice.exe:

:C0000776 VMMCall _EnterMutex ; comparable to your ExAcquireFastMutex
:C000077C add esp, 8
:C000077F push esi
:C0000780 mov esi, offset dword_0_C0004497
:C0000785 VMMCall Install_Exception_Handler
:C000078B pop esi
:C000078C call sub_0_C002EB06; code here is *identical* to your call sub_0_46B18

:C0000791 mov ds:dword_0_C000448B, 1; problem instruction, must nop this out
...
:C00007B8 cmp edx, 9C40h ; dwIOControlCode



ntice.sys:

:00060229 call ds:ExAcquireFastMutex ; does this call include an Install_Exception_Handler function?
:0006022F call sub_0_46B18 ; *identical* code, as mentioned above

:00060234 push 1
:00060236 pop eax
:00060237 mov dword_0_B6547, eax ; looks like it might be the problem instruction?
...
:0006028F cmp ecx, 9C406014h ; dwIOControlCode


If you can understand what I'm getting at, does this sound like the problem spot? If so try nopping it out and see if you can continue tracing.

Out of curiousity, have you tried IceLoads new 'invlpg' ntice.sys manual patch yet which might just solve all your problems? Unfortunately all I can do is apply the patch, look at it in IDA, and gape in wonderment at the reasoning behind it and how the solution was sussed out ;-) But I'd be interested if it does indeed solve the breakpoints problem for others.

btw Toteu thanks for the useful information, though I'm nowhere near making use of your scripts yet

Kayaker

congratulation Kayaker, your really doing a good job.

Thanks. All the moderators are doing a good job. Hope this particular thread solved a nagging problem.

Kayaker

First of all i must say the patch works well on my system.
(win XP)

Only thing is that it doesn't break at some packed targets (like aspr). I know, just modify the section flags and it will stop.
But some targets simply check their prog if it is modified..so then we have to patch/skip that code bla,bla,bla....

So if you want a simple break on those targets hop to kernel GetCurrentDirectoryW and put a breakpoint at: call [ebp+8]
(some lines below) and step into it,..the first instruction is entry-point of your packed prog.

SpeK