Hi,

I realise that I am going over some of the material that has been covered in the FAQ's, but there are some points that I don't fully understand and need to clarify ... so pls hang off on the flames until you've read the entire post ... (and if you think I should have been able to find the answer ... fire away)

I am a newbie and at the moment I can't get SI (SI405WNT in a W2K environment) to trigger any bpx that I set.

SI installed fine, and the exports work, I don't have any video issues - so I'm quite happy with my SI installion except for the fact I can't get my bpx's to work (not one!)

I have read the thread about DriverStudio (I gather this is a later release of SI - which is a package that includes the SI module), and I understand the concept of - if you like - "global" bpx via BreakInSharedMods, unfortunately my version of SI doesn't support this setting.

However there is also a discussion of setting the context via the addr command before then setting the bpx (in fact my SI doco talks about this - page 97 - but only briefly).

My version of SI does support the addr command, and I appear to be able to change contexts (I can see the context change). What concerns me though, is that when I exit (F5) and the return (Ctl-D) the context change is not "remembered".

Also where I have attempted to set the bpx after first changing the context with an essay (i.e. a known program and a known bpx) the bpx still doesn't trigger for me ... which means either:

A. I'm doing something wrong in setting the context and/or the bpx in that context ... or

B. Unfortunately SI405WNT doesn't actually work with W2K (it looks like it works, but it doesn't really).

(this is what I would like to clarify A. or B.)

My other options are:

1. Find DS3.1 ... yes well I've tried that - and for now I think it will be easier to work with SI405WNT (provided that this is in fact possible)

2. Switch to W95 / W98. Many of the essays I've read so far are based on this platform, so there is an argument for that, plus I would have access to hmemcpy ... however these platforms are really not my preference (they tend to go AWOL far too much IMO). Last resort option.

3. Maybe try NT4 (just thought of that now, writing this post)

Apologies for the long-ish post, if you're still awake, thank you for reading.

ss-2

If you break at the start of a program with the Sice loader (assuming you can), and set a breakpoint say a few lines down, either on an address or an API call - does SI break? It should. Make sure you set your bp *while in the context* of the app you want to break into.

This is irrespective of the ADDR command, which you shouldn't have to use since you're already in the correct context. In other words, don't expect to be able to just change the context with ADDR from the desktop and have a reliable bp set. If you do, you also need to specify the CS: portion of the address else you'll set up a bp with the wrong code segment.

If all else fails, you could try BPM x breakpoints, they can be more reliable than BPX bp's for "sticking". However, they especially should be set while *in* the context of the app.

Hi Kayaker,

Thank you for responding.


Yes, this works.


I don't follow you here. The only way I know to get SI into the correct context is via the ADDR command, SI initially always defaults to IDLE.

Also, when I switch into SI, SI is always in full screen mode - I can't access SI from the GUI (which is what I assume you mean when you refer to the "desktop".


Um, if this is important, can you clarify.


This would be a lot harder though, because wouldn't this mean that I'd have to "convert" my BPX breakpoints to BPM's (which means I'd have to locate the calls in the program)? ... I'm not sure that I'm following you correctly here.

The difficulty is that because I'm just starting out, I don't have a "baseline" for what is normal behaviour. So for instance when I am trying to follow an essay and the BPX doesn't work as it should, I don't know whether this is because I have goofed up somewhere (entirely possible at this stage) or whether it's because my configuration isn't working 100%.

Incidentally the other thing I noticed when I was setting the BPM as a test. The first thing I did was use ADDR to set the context to Notepad (which it did). Then I switched up to the Code window to scroll a few lines to find a Call, the ADDR context switched back to IDLE (i.e. each time I toggled to the code window the ADDR context changed ... which to me seems odd). Is it?

You probably were not expecting so many questions in my reply, sorry at this stage I'm still on a steep learning curve. The main thing I want to try and establish is whether SI appears to be working properly or not (I don't know enough to be sure one way or the other). It certainly is very stable, but I'm not sure that it is working the way that it should.

As Far as I remember:

1.SI 405 DID work inW2k. It is the NT version right????

2. The address context issues started being a problem with Sice 4.27 or SI 4.30. Before then, All API bp (like bpx messageboxA) were "global" ie address context independent by default.

3. I think your problem may be somewhere else.
4. Did you modif the winice.dat to include all the system dll modules? (just checking).

The test Kayaker sugests is:

Load notepad using the symbol loader,
Sice will break at the program entry point.
Place a bpx in an instruction just a few lines down, where you are SURE the program is going to go through. .
To avoid mistakes use the mouse double click to select the isntruction, it should change color, then type the command bl to make triple sure the bp is selected. . .
Then leave sice by pressing F5.
It should break in your selected inst right away...

Hi Naides,


That's correct.



If you're right about that, then I definitely have a different problem. Hopefully someone else will clarify this point though.

In the SI manual it states the following:

.."For WIN32 applications, breakpoints set in the upper 2GB of address space are global; they break in any context. Breakpoints in the lower 2GB _are_ context sensitive" ...

On this basis my guess is that context are not global (as I don't have 2GB of memory), and it's unlikely to be paged either.


Yes, I understand that, and I have.


Actually I don't know that I did this exactly. I loaded notepad, then switched into SI. How would I "load notepad using the symbol loader?" ... do I need the nms files - because I don't have them I'm just exporting dll's.

I did this bit OK, but we tested a BPM (not a BPX).

I think the easiest test might be to a BPX on something that is easily reproduced, for instance the OK button in the "About" dialog box in Notepad. If that works, then my SI is functional, if it doesn't - then SI is broken. I have tried a few BPX's already that haven't worked (but that could be because I'm not checking for the correct API for the button)

The upper 2GB addresses are assigned to the system modules and services. The lower 2GB addresses are where your app main module and the specific dll it loads are located. This is the way memory is mapped. it is virtual memory, and has nothing to do with the actual RAM you have installed in your computer. Taht is the size of the memory space your application addresses at a time.




in the Numega or compuware folder, you will find severeal files, including one exe file named symbol loader, and several pdfs on using softice. Read the helpon those files.
symbol loader allows you to load an exe file: notepad.exe, then click on module-> load, it will complain about a mistake,, just keed giong then, if you set up the option "break on winmain" in Symbol loader program, Sice will break.

Hi Naides,


Yeah the trouble is that the doco is assumes that the reader is well acquainted with debugger concepts, which is fair enough SI isn't a newbie program, but I'm a newbie to debugging so I read the doc and try to follow it.

I did this OK, the "break on winmain" option was selected by default. When I then "load the currently open module" Notepad starts as normal. Now given that the "break on winmain" option is selected, shouldn't I break into SI straight away? ... I don't, I stay in the GUI with Notepad running 'business as usual'.

I also tried loading another program via the symbol loader and then setting a bpx on a known api for that app, and it still doesn't trigger either?

ss-2

Hi Naides / Kayaker,

I decided to setup NT4 and install SI on that and see if it made a difference, it did, and now SI works properly (finally bpx works!).

Ironically, as I mentioned when I originally installed SI under W2K I didn't have any setup problems, and I have noticed in my troubleshooting that a number of people have had issues getting SI to work properly (mostly under WXP).

With SI installed under NT4, the system hangs as it loads the GUI if the startup mode is anything other than manual. I tried using the standard VGA, but it didn't make a difference. It doesn't really matter anyway, manual startup will do. Also I noticed that the version I am using is supposed to work under W2K ... who knows ... shit happens.

Appreciate your assistance, thank you.

Hi

This advice seems to contradit the FAQ on ADDR at http://www.woodmann.com/fravia/rce-faq.htm
e.g. > A simple 'addr process-name' should work.

// Introduction:

I am a long time amateur user of Softice on 9x who has recently attempted to debug/reverse an app which only runs on 2k onwards. Serious problems have ensued ...

Installing on XP would in theory work except that I have never, nor have I ever met anybody who has ever succeeded in getting Softice to do anything with XP except crash it one way or the other.

The only version I could get working at all on Win2k was 405. (The later versions with DS 2.7 and 3.1 had dire keyboard and video problems on Win2k which despite numerous patches and days of rebooting, i was unable to circumvent.)

After several days (no exaggeration) of attempting to get SI running on 2k, several OS installs, and hundreds of reboots, I am now on Win2kProSP4 5.00.2195, with SI Ver 405 build 334 and a decent set of NMSs and exports loaded. (even now, I only have video working with SI in Boot mode, any other startup setting crashes ....).

A comment which I believe justified at this stage is that Softice is an extremely buggy application in sofar as its support for both Win2k and XP users is inexcusably atrocious. It literally does not do what it says on the tin under these OS's. This is alpha-quality software. Heaven help anyone who actually pays for it.

// End Intro/rant

I notice that breakpoints do seem to work if I double-click in the Code window in code that already happens to be running when I press CTRL-D (Usually somewhere in HAL.) However, setting BPXs in any other way seems to fail.

Regarding the question in this thread about Symbol Loader, I *never* was able to get any app to break on load under 9x using Symbol Loader. The only prog that would ever do that for me was the modified IceLoad version, which worked perfectly. Under Win2k I find neither Iceload or Symbol Loader will break Notepad on starting it.

Similarly to the comments above I am unable to set the Environment variable to enable global breakpointing (SI reports the var does not exist, apparently it is not in this ver 405)

Using Notepad as an example, I receive an unusal error in Symbol loader:

=========================
G:\WINNT\NOTEPAD.EXE opened successfully
Translating G:\WINNT\NOTEPAD.EXE. . .
Error: Unexpected exception

I select the option to Load Anyway. Notepad loads and is available under ADDR although the default context is set to IDLE.

My attempts to set BPs on system functions have also failed. SI appears to be broken in its breakpoint function

I would be very grateful if anyone could explain how to go forward re. breakpoints in this scenario.

I have tried
addr System
bpx _CreateFileA

but that never fires.

Perhaps there is some other test I could use in order to make some progress towards enabling a working BPX functionality in this scenario?

The target app is an NT service which does not run from its .EXE file and only runs when started from its Services entry. I can see it in ADDR, I can set ADDR to its context, and even better the author was nice enough to leave a .PDB file next to it therefore I have translated to NMS and have a full set of symbols accessible via TABLE and SYM. Perhaps if I could identify the Code Segment for the app, I could manually enter this into the BPX command?

Thanks in advance for any suggestions or clarifications.

I have to apologize for the rust, I haven't done this for some time. Also, the following may not be entirely accurate, although it's in the ballpark.

The addr instruction is not something you should have to use under normal circumstances. If I get correctly what Kayaker is saying, it's that the context refered to must be the app you're debugging.

The term context, in the way it is used in Sice, means a memory space.
If you watch the process as Sice works, it begins in the app you're debugging. Then it might go off to dll's like MFC42.dll, or other dll's not belonging to the app, returning to the main app when those routines are finished. Where it goes off to is another memory address, where those dll's are loaded. That's mainly what is going on as an app executes. The operating system, and the underlying processor support, are contunually swapping code and data in and out of memory and to and from the hard disk.

Those are different contexts because they belong to different programs, hence a different memory space. But, the physical memory space is common, and an area of physical memory could be shared. I'm not talking about the logical memory here, in which each app has it's own space. Logical memory has to be mapped to physical memory, and that is done in a transparent manner to the user or the programmer.

If you set a bpx while your in another dll, that memory space could be reassigned by the time Sice gets around to executing the bpx, because the main app has no control over that. So, if an app is addressing a memory space (context), then you set a bpx in that space, that memory must be under control of the app. If it's not, there's no guarantee that memory to which the bpx is assigned, will be valid next time the app executes.

When an app is loaded into memory, it is assigned it's own memory space, which remains consistent throughout the execution of the program. That is the app's context, and that is the only context in which you can reliably set bpx's...in it's own memory space. When Sice executes a BPX, the address pointed to by the bpx must make sense. If it points to a memory address that was good when you set it, and which doesn't exist when time comes to execute it, the bpx wont trip.

My understanding of bpx's, as related to Sice, is to set them according to the window you are in. Look at the bottom of the code window and it will tell you which program the code belongs to. That, to me, is the context. There's no point in me setting a bpx on the very first instruction of a program if I set it from within the app while it's running. It will never reach that instruction. The only way I can do that is to set it from within the Sice loader.

Someone mentioned earlier in the thread that they set it to winmain. That is not the first instruction in the program. There's a lot of code before winmain, and you need to be right at the beginnng of the proggy sometimes in order to trace into it. That's especially true for self-modifying code and packed programs. When you use the loader, tell it to stop at the first instruction. When you do that, it often looks like something messed up. Just trace into the app one step and the code will straighten itself out.

Certain dll's are always found in the same memory space. System dll's likie kernel32, user32, etc. are always in the same space. However, if you set a bpx in them, in the wrong context, the bpx will trip erratically. For example, if you set a bpx in kernel32 while you're in an app, then you reload the app, the bpx will trip any time another app calls kernel32.

All the other apps use kernel32 as well. So, as you reload your app, any app used in the reloading process, that uses k32, will trip the bpx. The context in which you set the bpx was in the context of your app while it was running. Once you exit the app, in order to reload it, the context has changed. K32 will be accessed from a different context.

You have to be really careful to get into the correct context before you set the bpx. Sometimes you have to set other bpx's to get the app to run to a certain point before setting the bpx you want.

Thanks for input. To debug the running service I gave up on ice and went for Visual Studio debugger which seemed better. I have started a new topic/question about it.