Log in

View Full Version : Softice - updating code in memory ?


Neitsa
January 4th, 2005, 12:43
Hello,

When I'm debugging my drivers, I'm breaking on their code with an INT3 embedded in the code and typing I3HERE command.

If my driver has some bugs (well they are all buggy ) I'm compiling again my driver's code, but the code remain the same in Softice when loading it again.

The only way I've found to update the code in softice is to reboot the O.S...

Is there another way to update the memory than rebooting ?

Reading the Softice manual it seems that it 's possible to do it with the softice loader, but as I've said before, I'm not using the Softice loader to break on my drivers.

Thank you very much.

Regards, Neitsa.

Opcode
January 4th, 2005, 13:26
Hi Neitsa,

Strange behaviour!

I do the same, I always put a INT3 instructions in my drivers to debug with
SoftICE but my code is always updated when I run it.

I don't know if this is important, but I'm using Windows XP SP1 and to load my drivers I'm using the Four-F KmdManager.

Regards,
Opcode

Neitsa
January 4th, 2005, 13:44
Thank you Opcode for your reply.

Hmm yes it sounds strange since some of my friends have the same problem as mine.

I'm using Win 2k and D.S 3.1. Generally I'm using an SCP (service control program) to load my driver which have a user-mode counterpart (or Osrloader/Kmdmanager from four-f if no SCP).

This problem is in fact the same as the 'A' (assemble) command in softice on windows NT, when the changed code remains "sticky" (this is explained in the Softice command manual at the 'A' command).

Well I dunno what I'm doing wrong...I'll investigate...

Thank you very much.

Regards, Neitsa.

Kayaker
January 4th, 2005, 14:48
Hi Neitsa,

You write buggy driver code too hey?

That does sound a bit strange. The only problems I've had is when I forget to update the .NMS file after recompiling, and the SRC and disassembly don't match.

If your driver isn't UNloading properly then your newly compiled version shouldn't load at all, but you *should* be receiving (or have incorporated) some kind of error message in that case .

The other issue that can happen after a driver development bug crash (not BSOD) is a conflict with the existing driver name in the registry. I have had the problem of not being able to reload my driver after a crash and had taken to re-naming development versions incrementally after a crash. After a reboot all was OK again. Renaming is better than rebooting but usually means changes to several modules and later cleaning up of the registry.

The reg entries are of course here:
HKLM\System\CurrentControlSet\Services\<DriverName>
(removed on uninstall)
HKLM\SYSTEM\ControlSet\Enum\Root\LEGACY_<DriverName>


For the record I use I1HERE breakpoints and have converted from ASM to VC6++ for driver writing. I don't mind using ASM for GUI stuff, I love the size/efficiency benefit, but for drivers C/C++ just seems so much cleaner than ASM (sorry Opcode )

Kayaker

Opcode
January 4th, 2005, 15:17
Quote:
[Originally Posted by Kayaker]but for drivers C/C++ just seems so much cleaner than ASM (sorry Opcode )


No problem, I'm doing the same

Regards,
Opcode

Neitsa
January 4th, 2005, 20:06
Thanks for your replies, I'll see if I can solve my problem with your hints.

Maybe the problem is due to remote debugging (I'm testing my drivers on a target system with a 2k box on a VMWare system as target).

BTW, I'm currently looking to switch to C to have more readable code too...Asm is great for low-level stuff but source code can sometimes be a real pain to maintain (on the other hand it is very easy to debug).

That's trully a hard choice...

Thank you very much.

Regards, Neitsa.

Kayaker
January 5th, 2005, 01:26
Btw, Neitsa. I've read your remote debugging with VMWare tutorial in French, it is a very useful reference. You've got a nice little site there, too bad I had to search for it to Peer inside it...

I'd encourage a link to it hint hint...

JMI
January 5th, 2005, 02:49
Mon Dieu. Le Kayaker lit des Français. L'eau est aujourd'hui très froid, n'est pas lui.

Regards,

Neitsa
January 5th, 2005, 12:04
Hello,

Quote:

You've got a nice little site there, too bad I had to search for it to Peer inside it...


Thank you very much ! this is trully nice, especially coming from you.

We do not have many reversing tutorials/websites in French (or they are from "old" reversers like TheAnalyst or Christal, etc.). I don't think my site will be interesting for non-english speakers since there is many very good sites out there... And maybe as you've seen there not so many things in mine...making tutorials takes time and this is time that I can't spent on reversing engineering.

Anyway, thanks again for your cheers !

Quote:

Mon Dieu. Le Kayaker lit des Français. L'eau est aujourd'hui très froid, n'est pas lui.


OMG !!! JMI is talking french !!! (BTW, there's some mistakes in it..., but I know how it is difficult to learn french [even for us, natural speakers]).

Regards, Neitsa.

JMI
January 5th, 2005, 12:44
Neitsa:

Blame it on Systran Translator. I last "studied" French in the 1960's, followed by a few years of German, and then 1400 classroom hours of Vietnamese, all in one year. But well spoken French is a very pleasant language to hear spoken. Much more melodic than English or German. And most westerners have trouble with the tonal languages like Chinese and Vietnamese. But at least Vietnamese had no verb declensions or articles to match to the proper gender and/or grammar case.

Regards,

TQN
January 5th, 2005, 23:19
Wow, JMI had learnt Vietnamese. "Ban con nho va noi duoc tieng Viet khong ?"
Chuc mung nam moi (Happy New Year in Vietnamese)

FrankRizzo
January 5th, 2005, 23:58
All I know about Vietnamese is that Pho Kim Long in Las Vegas is a good restaurant..
I wondered if they had another one called Pho Kim Hard!

(For the uninformed, Pho is pronounced like FUH, and refers to a beef-broth based soup with noodles, and all kinds of greenery in it.. VERY tasty!)

roocoon
January 7th, 2005, 15:41
That problem used to happen some time ago and I guess it still does.
From what I remember, it used to happen if you exited a debugged application while software breakpoints were still set, modified the app and restarted it under SoftICE. The old memory image was still used in this case.
The fix was to disable breakpoints before exiting the app, modify it, restart it, and enable the breakpoints again.
If you only have the hardwired CC codes, the above shouldn't apply but maybe I'm wrong.