I'm working on a program that was packed with AS Pack V2.1
I ran ASP Die on it and I now have a working program several times bigger than the original as you'd expect. I looked at this unpacked prog with a Hex viewer and located a whole load of strings including "Registration Failed" at 00446700.
I did a dissassembly using WinDasm and found the following code:

0040C332 PUSH 00446700

There is only one reference to this string.
I set a breakpoint (BPMD 0040C332 rw) ran the program and entered a wrong serial number but Sice did not break.
I can get Sice to break if I use BPX messageboxA but this is far too general.
What am I doing wrong? Is the prog detecting that Sice is there ?

I haven't used sice for ages and I'm not sure why it won't break on read, but you might want to try one of:
BPX 0040C332
BPMD 0040C332 x
Maybe the D for dword is the problem?
BPMB 0040C332 x
BPMB 0040C332 rw

Just some ideas.

If I am correct in my guess, This has to do with the memory space issue of Soft Ice. You have to be "standing" in the target process Memory when you setup the BP.
Search the Board circa 2000 to 2001.

Hi Guys, Thanks for the replies.
I tried setting BP as fr33ke suggested with the same result.

Naides:
I have not done an exhaustive search (yet) for 2000/2001 but did find stuff on Sice with XP sp1, but that seemed to be related to import of symbols from windoze API's.

Ok what I'm doing is entering registration details, CRTL D breaking into Sice, Set a BP MessageBoxA, F5,
press the register button and Sice breaks as below.

004295FD call [user32! MessageBoxA]

I'm not really understanding this memory space issue, are you saying that it is quite possible that Sice will break on MessageBoxA because it is located in an instruction at 004295A which it is 'seeing' correctly but wont break on 0040C332 because it cant 'see' anything there?

From the foggy memory:

SoftIce can see the memory of all processes, all at the same time. Every Process has an address 00400000 and every process has an address 04295FD. How come they don't interfere with each other?? The OS handles this and gives each process the illusion of owning 4 gigs of memory space. So when you place a bp in Sice, for it to be located in the "right" 04295FD, you have to be standing in the memory space of you app. look at the lower left corner of your Sice and you will see the process name. To switch around processes and memory spaces, learn to use the Sice commands PROC and mem ADDR.

Olly does not have this problem because, being ring 3, it already sees only the memory space context of the debugee, and nothing else. . .

use addr <pid/process_name> and then set breaks. addr switches cr3 so you get valid memory space... Also for easier debugging with softice, forget about tuts where you see press ctrl+d (keep pressing) untill you are in the context of your target... Write loader which will start process and set break on it's entry point (you will need bpint 3 or i3here on in softice), at least that's how I do it...

When in doubt read the instructions. I know, I know, real men don't read instructions

From the Softice manual, Understanding Breakpoint Contexts:



What this means is that you can't just Ctrl-D into Softice and set a breakpoint willy nilly on anything other than a global system module. To set a bp in a user application, you *must* be in the context of that application.

To be in the proper context you can:

Load the app with Symbol Loader with Break on WinMain option set.

Set a breakpoint on an API you know the application will call, such as 'bpx MessageBoxA', trace back into the application from the system code, then set the user breakpoint.

Ctrl-D into Softice and type
ADDR notepad
You will then be in the context of notepad. You will see the name in the lower right hand corner.


BPM type breakpoints should only be used for in-Context tracing purposes. If you CTRL-D / F5 out of Softice the BPM will be unreliable. Do not use them as "global" breakpoints. You should delete the BPM and reset it again when back in context.

Fuck, the command was ADDR not mem. I am old, and Sice rusty, I apologize to GreyHound. . .

I'm still confused, deroko is right in his summation of how I've been using Sice with the approach they use in the Tuts.
I'm going to show my ignorance here so please be patient. I re-read the 'great softice how to' and did even look at PROC and MEM32 in the driver studio manual.
The 'processes' are these the same windows processes that you can list with task manager?
When the program is run I understand that it calls functions that are part of the operating system. Like MessageBoxA is part of User32.dll. which in turn is part of XP. I dont know much about the XP operating system, but it seems like your saying that when this program runs it uses some of the processes or code that makes windows explorer or notepad work. Then in order for the breakpoint to work I need to be where this code is? Clearly I need some more info and practice on this.

im no sice expert not even a newbie

but i can answer the logic behind the answers posted by several members

first point to remember sice is ring 0 debugger it is the king the EMPEROR the absolute authority when it is working

so it can see anything and everything in the system it is running

second point to remember
the system when it is running at least will have 13 14 critical process runnning
lsass,csrss,svchost,winlogon, etc wtc apart from your debugee

and lsass can call MessageBoxA
csrss can call MessageboxA
winlogon can call MessageBoxA
and your debuggee can also call messageBoxA


MessageboxA resides in user32.dll
and windows basically shows an illusion in every process that user32.dll is owned by that specific process

but in reality these system dlls are simply shared section (every process that are running are sharing the same user32.dll)

so when you are setting ("bp"+"whatever" MessageBoxA
sice will break when any of the running process called MessageBoxA and when sice broke it will in the CONTEXT of the process that called MessageBoxA

luckily many of the times only your debuggee calls the api that you breakpoint

now you can apply the same logic i tried to explain to your 401234 whatever address

lsass can have 401234
csrss can have 401234
winlogon can have 401234
and your debuggee can have 401234


so when you press ctrl+d
sice will break arbitrarily anywhere (mostly it will be in the hal idle spinning loops )

and without you explicitly setting a breakpoint in your debuggee's context

sice has no way of knowing you want to break in your debuggee's 401234

it will break on the first 401234 it encounters or in the first 401234 it encounters in the context where you set the breakpoint


so you have to set bp in yoour debuggee's context

so one pseudo notation of breakpoint could be

bp# Notepad!401234
or
bp Winlogon!401234
or
bp csrss!401234
or "yourdebuggee"!401234

etc etc

hope you get the idea

Some of this stuff is beginning to make sense. I used PROC without any parameters and got a list of all processes, the Process ID of MYPROG.exe is (69C) I'll go and read up on the ADDR command and try it out.
Not sure how but I did get softice to break on the right breakpoint and it even displayed reference to the dialogue "registration failed". I find this stuff heavy going but if it was easy everyone would be doing it!!

In this example,
this is what you should do:
In softice command line type:

PROC [enter]

Now you know that MYPROG.exe Process ID is 69C (It will change with every run)

now type

ADDR 69C [enter]

Look at the left lower corner of SoftIce. You will see your Process Name.

Now you are "standing" in MYPROG.exe memory space.

If you type

BPX 0040C332 [enter]

the BPX will be placed on the right address

Actually if you type

u 0040C332

you should see your MYPROG.EXE code right on the code window, with the BreakPoint set and highlighted

Thanks to all who replied, I'm now on the way. Does the PROC ID change each time because different processes may be running and these may be in a different order? So I should run PROC each debug session to identify the PROC ID then use ADDR to set the context then set the BP when I'm "standing" in the code. Hope I got that right.

Regards.

the Process ID code is assigned by the OS every time an instance of a process is created, and is not assigned necessarily in sequential order, so Yes, in every debugging session is a better idea to run PROC to find it out. WHILE MYPROG.EXE has not quit and restarted, Process ID should not change.