Results 1 to 14 of 14

Thread: Why won't Sice break?

  1. #1

    Why won't Sice break?

    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 ?

  2. #2
    King of Redonda
    Join Date
    Jul 2006
    Blog Entries
    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.
    <[TN]FBMachine> i got kicked out of barnes and noble once for moving all the bibles into the fiction section

  3. #3
    Naides is Nobody
    Join Date
    Jan 2002
    Planet Earth
    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.

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

    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?

  5. #5
    Naides is Nobody
    Join Date
    Jan 2002
    Planet Earth
    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. . .

  6. #6
    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...

  7. #7
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Blog Entries
    When in doubt read the instructions. I know, I know, real men don't read instructions

    From the Softice manual, Understanding Breakpoint Contexts:

    For Win32 applications, breakpoints set in the upper 2GB of address
    space are global; they break in any context. Breakpoints set in the lower
    2GB are context-sensitive; they trigger according to the following criteria
    and SoftICE pops up:

    SoftICE only pops up if the address context matches the context in
    which the breakpoint was set.

    If the breakpoint triggers in the same code module in which the
    breakpoint was set, then SoftICE disregards the address context and
    pops up. This means that a breakpoint set in a shared module like
    KERNEL32.DLL breaks in every address context that has the module
    loaded, regardless of what address context was selected when the
    breakpoint was set.

    Breakpoint contexts are more important for BPM-type breakpoints than
    for BPX. BPM sets an x86 hardware breakpoint that triggers on a certain
    virtual address. Because the CPU breakpoint hardware knows nothing of
    address spaces, it could potentially trigger on an unrelated piece of code
    or data. Breakpoint contexts give SoftICE the ability to discriminate
    between false traps and real ones.
    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.

  8. #8
    Naides is Nobody
    Join Date
    Jan 2002
    Planet Earth
    Fuck, the command was ADDR not mem. I am old, and Sice rusty, I apologize to GreyHound. . .

  9. #9
    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.

  10. #10
    Super Moderator
    Join Date
    Dec 2004
    Blog Entries
    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
    bp Winlogon!401234
    bp csrss!401234
    or "yourdebuggee"!401234

    etc etc

    hope you get the idea

  11. #11
    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!!

  12. #12
    Naides is Nobody
    Join Date
    Jan 2002
    Planet Earth
    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

  13. #13
    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.


  14. #14
    Naides is Nobody
    Join Date
    Jan 2002
    Planet Earth
    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.

Similar Threads

  1. IDA 2 Sice
    By Morgatte in forum Tools of Our Trade (TOT) Messageboard
    Replies: 19
    Last Post: November 3rd, 2006, 17:30
  2. break disabled after one break
    By hesho in forum The Newbie Forum
    Replies: 1
    Last Post: May 25th, 2005, 16:40
  3. HELP : Sice in Windows .NET
    By dreamweavermx in forum The Newbie Forum
    Replies: 2
    Last Post: April 13th, 2003, 02:44
  4. Sice + NUM-Key
    By SilberFuchs in forum Tools of Our Trade (TOT) Messageboard
    Replies: 0
    Last Post: January 6th, 2002, 09:26
  5. Sice / hmemcpy
    By Goat in forum Tools of Our Trade (TOT) Messageboard
    Replies: 0
    Last Post: April 29th, 2001, 21:05


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts