I have search the internet but could not found any help for mine problem.


I just installed softice 4.05 for nt. The installation looks OK, and I was able to start softice. I set up a breakpoint at MessageBoxA, brought up an APP, softice popped up at eactly the function MesssageBoxA. Everything looks fine except one thing that softice could not stop at the starting point of the APP. I tried with the module loader, after I opened the APP and loaded into loader, the softice never popped up. what could be wrong?

and one more thing, I set another break point BPX @esp after MessageBoxA, but softice seemed never went back to the caller function.

so the question is how I can start debugging from the begginng of an APP just like MSVC++.

appreciate for any help

1. Make sure that the Symbol loader settings, debugging tab has set the 'Stop at Winmain' box.

2. What is your OS? Sice 4.05 works BADLY in winXP and does not do a very good job in Win2k

3. Some apps, including protected, packed apps have weird SEH structures in the initial code and 'escape' from Softice break at entry system

4. Install Ollydbg and see if you have the same problem. Olly is usually more reliable in stopping at the entry point and may help you figure out what is going on.

First, Thanks for your help.

1. yes, I double checked the setting, it is setting correctly
2. OS is W2K
3. no sure how to do this
4. this APP I tested works fine under VC++

What follows is simple, systematic troubleshooting.

Load another, pehaps several programs in Softice Symbol loader. . .
Do they break at entry point?? if they do, the problem is in your program, not in Softice.
If they do not, there is something wrong with Sice settings.
Consider, first of all, getting a newer version of Sice.

As naides said, the problem is most likely your older version of Softice/SymbolLoader, in some versions the breakpoint at WinMain did not "stick".

However, there is a sure-fire way of tracing from the image Entry Point (EP) of an app using Softice which should work with all versions/OS. This includes apps which might alter/check the EP in other ways as naides intimated in point #3 (during DLL_PROCESS_ATTACH from a statically linked dll perhaps??)

This method is based on breaking during _BaseProcessStart and manually tracing into the EP, the normal route an app follows while loading.

Here is the path for Win2k, in kernel32.dll:


Note the NtSetInformationThread call just before the call to the EP. What the system does here is to *set* the EP value in the Win32StartAddress field of the ETHREAD block. This value was originally saved in the Context structure waaay back during process initialization (in BaseInitializeContext of CreateProcessW, but I digress). This is/becomes the value of EAX when the program begins execution.

Anyway, Zw/NtSetInformationThread is defined by:

ZwSetInformationThread(
IN HANDLE ThreadHandle,
IN THREADINFOCLASS ThreadInformationClass,
IN PVOID ThreadInformation,
IN ULONG ThreadInformationLength
);

where ThreadInformationClass is the enum value ThreadQuerySetWin32StartAddress, which is the PUSH 09 seen before the call.

Now you can't actually set a breakpoint on the ZwSetInformationThread syscall because this is in ntdll code and is not in a global context, but you can set a conditional bp on the ntoskrnl equivalent which will break whenever the specific ThreadInformationClass (9) is used:

BPX _NtSetInformationThread IF *(esp+8)==9 DO "dd esp"

Now if you trace through the call until the SYSEXIT/IRET (about 5 seconds of F10 tracing) you will return to the CALL [EBP+08], which will get you directly to the entry point of the app.

If you want to find the address of the CALL [EBP+08] (7C4E87F2 in my case), just open any app in OllyDbg and display the Call Stack immediately, the first stack address will be it.

With this breakpoint set (needs ntoskrnl symbols loaded), Softice should break when *any* application starts up. A bit of a roundabout route, but it does work for those "difficult" situations.

Kayaker

Edit:deconfused things...

many thanks to you all.

naides is right about softice. I loaded serveral different applications in the symbol loader, and none of them could stop at entry point. I guess the softice I installed was bad.

I tried with ollydbg, it worked fine. and it's UI looks nicer. I am going to try to learn ollydbg. I have not figured out how to load symbol with ollydbg yet. Anyone has a good tutorial? Thanks in advance.

Sorry Kayaker. Deeply sorry. I caused another defection to the Olly nation

I still think, (and no I haven't taken the time to learn how to use it), that the logical successor to Sice is Windbg - It's specifically written for the XP environment - I'd love to see some good tuts - maybe I'll search a little deeper.

SiGiNT

Kayaker: regarding your post above, s/OEP/EP

Sorry disavowed, I'm not quite sure what you mean. Did I fup something?

And yeah, I know naides, I can't fight the current any longer..

No need to search further. Check What Mark Russinovich says about it. In case you don't know, he's the coding guru who has made Filemon, Regmon, and all the other free goodies available to us from Sysinternals.

Read his commentary here: hxxp://www.windowsitpro.com/Windows/Article/ArticleID/5314/Windows_5314.html And BTW, if Russinovich is not having problems with Softice, or anyone else it seems, why are we in this forum having so much trouble? Are we hackers, or what?

BTW...he says "The only alternative debugger on the market is Compuware NuMega's SoftICE for NT..."

I don't see the point in having one debugger for Ring 3 and another for Ring 0. As I said before, I have no reason to knock Olly, I just don't understand the problems people are having with Softice.

This thread is an example. Instead of trying to understand the issues, we are all throwing our hands up and running off to Ollydebug. I thought reversers were made of sterner stuff.

In symbol loader, has anyone noticed that the option for Softice starting is Winmain? Winmain is NOT start of code. Has Compuware perhaps changed that option? It seems to me there used to be an option to stop at start of code. If I remember correctly, Softice puts a CC at some point in the code so it can break on it. Maybe that CC is being put in the wrong place.

When an app is compiled, the linker adds startup code before Winmain which eventually calls Winmain. This code does housekeeping, like getting environment variables and setting up memory so the process can be loaded. When you trace into the startup code, you have a long ways to go before Winmain is called. When you trace through a packed app, the point you are seeking is this start of code, not Winmain.

Let's not forget as well, that many apps these days are marking the app as 'not' executable in the PE header. Is it C0000060, or something like that? That has to be examined in an app like Lord PE and changed to executable. Otherwise, symbol loader wont stop at the start of code or anywhere else.

There's no need for you to fight anything Kayaker. You've proven to be one of the elite reversers, and if Softice is good enough for you, it's good enough for me.

BTW...thanks for the dissertation on Win 2000. I knew where to stop in K32 for Win 98 before the startup code, but on XP I thinks it's even different than in 2000 and 98. It reminds me of the transition from 16 bit apps to 32 bit apps. We're on a learning curve right now with the sudden emergence of true 32 bit OS's.

You know, these OS's and apps are getting more complicated all the time and are not for the faint of heart. I was reading through some stuff by Yates the other day and the guy is remarkable in the way he gets right under the hood. If we don't make the effort to understand how these OS's work, and the tools like Softice, I'm afraid we're in for a rough ride.

All of your references to the "OEP" should really be references to the "EP". There's a big difference.


I have no problems getting SoftICE to work. I just prefer using OllyDbg because IMHO it has a sleaker interface, is easier to use, allows me to easily multitask while I'm debugging something, etc.

I assume you're referring to packed apps. I wasn't paying too much attention to the semantics, and I do tend to think one thing and say another. I got OEP stuck in my head from referring to tutes written by others. I assume it means Original Entry Point. Would that not mean the entry point before the app was packed?

I was actually referring to 'entry code' above with the entry point being the very first byte of an app's code the system encounters when it loads the process. My understanding of OEP in reference to that is the original point of entry in the code of an app by the system. Once it passes that point and calls Winmain, it never returns to that entry code.

Of course, in a packed app, there's a wrapper around the entry code of the original app and it has it's own entry point. Is that the distinction you're making? I'm not sure they are the same thing, however, since the linker adds the EP, or OEP, or whatever you want to call it, to the real app. The packer doesn't use a linker. It just takes the original app, mangles it, and presents a pseudo entry point to the system.



I'm not knocking anybody for preferring Olly. It's just that in the past few weeks I've seen suggestions that people should abandon Softice because it doesn't work in XP. I find that frustrating because I can't see specific reasons for it. It's like people keep asking the same question over and over as to why Ice wont break at the EP and there's plenty of info in the archives to indicate why.

I see what you mean. It always used to screw me up (apparently still does) when people spoke of OEP, EP, and even PEP. I'd gotten too used to using the phrases interchangeably. C compilers at least will add all kinds of startup code before WinMain, as Waxford mentions, so to clarify then, you're saying

EP = PE->OptionalHeader.AddressOfEntryPoint

I'm with Waxford here, so what exactly is OEP and should it be used exclusively when speaking of packed apps and finding the ever elusive "original" EP?

Fair enough, I'll accept the definition of the Reverse Engineering Wiki:

-------------
OEP is an acronym for Original Entry Point. Every executable file has an entry point that tells the operating system where to begin program execution. When data compression is applied to an executable, the original code is compressed and a decompression routine is attached. The entry point of the executable is changed to start program execution at the decompression routine. During runtime, the decompression routine restores the original software code. After all the original code has been restored the decompression routine will jump to the entry point of the restored code, this is called the Original Entry Point. Using a debugger you can analyze the program execution and stop the flow at the OEP. The original executable can then be recovered through memory dumping and import rebuilding.

http://wiki.reverse-engineering.net/OEP
--------------

I'm glad disavowed brought me to task on my misuse of the term.

/tongue firmly implanted in cheek
To avoid such confusion in the future I propose using the more descriptive terms Image Entry Point (IEP) or Program Entry Point (PEP) to define the EP proper.

When dealing with packed applications the original entry points would be referred to as OIEP or OPEP, but only in the case of "wrapper" style packers which discharge their payload in a virgin state.

More complex packers may have modified certain instructions of the original image to access high memory locations (in packer memory), either for IAT redirection or to retrieve certain variables. These instructions can be designated as Packer Modified, i.e. PMIAT's or PMV's, and the high memory locations they refer to as Packer Image Memory Pointers or PIMP's.

I think that should clear things up immensely

Wax, I am a diehard user of SoftIce. Out of tradition or perhaps inertia, I learned to use it 7 years ago and just know more of its tricks (Never to the level of our guru Kayaker)

Olly helps, and is not question of choosing . . . I take both!!
Olly appears to have been designed by reversers for reversers. There is an active community of people contributing to it and adapting it to new challenges.
Sice intended use is different and Compuware has no incentive in making Sice more user friendly in RCE applications (like debugging apps without source code)

The point is: do not use a cannon to kill a mosquito.
SoftIce (and IDA) power comes with responsibility and a steep learning curve

Well, not necessarily. If TLS callbacks are present, they can be executed before the EP. Also, DllMain from modules in the Import Table are executed before the EP.


Yes, this is the correct definition.

Simply put, the OEP is the value of PE->OptionalHeader.AddressOfEntryPoint before a packer/protector/etc. was applied to the program.

Actually, I got caught out on that one, answering a question aimed at you. I think disavowed was testing to see if we were awake. I just noticed he used a quote from you and one from me. Of course, in my usual bleary-eyed state, I answered your quote. Sorry about that.

With reference to 'he' above, I presume disavowed is a he. I know that's rather sexist and I got caught on it in a newsgroup. There were nyms like 'elvis' and I naturally asssumed elvis would be a guy. Wrong!! The ng was run by women, many of whom had male names.

I've said a couple of times that I'm not anti-Olly. In fact, I downloaded it a while back with the intention of learning it. I started out, as many did, on wdasm. IDA was intimidating, especially with it's terse help files. I persevered, though, and now all I use is IDA. Possibly I'll become a convert to Olly in the same way.

I do like the fact that it's free, not because I'm cheap, but because I'm into that. I like the approach of the Linux crowd, and if Olly is anything like that, I'm for it. Also, I take my hat off to the author of Olly.

It was just a silly mistake, but you see, it's a problem of having done too much unpacking in one's youth. Nothing else exists but the quest for the OEP, then the term becomes blindly ingrained and you begin to use it loosely. (careful kids, this is your brain on Asprotect).

you've got me on the finer points of the theory and perhaps you could expand on that if you have the time/interest. I realize there's a difference between the app image on disk and the image loaded into memory. Obviously, execution can't start till the image is in memory. I'm sure the system takes direction from what is embedded in the PE header on the disk image.

Are you saying there is information present in the PE header that initiates thread execution before the actual image in memory is executed? I'm not clear on that. My understanding is that the system reads from the EP which is tacked onto the programmers code by the linker. I'm aware that some packed apps sneak code into the area between the MZ header and the PE header, so I assume the system can be directed to start reading code anywhere.

My point, however, was that a program, as written by the programmer, begins at Winmain, and that the actual entry point comes before Winmain is called. In IDA, Winmain is labelled 'Start', but you notice that point is usually well into the code. I assume by 'start', that Ilfak means the actual program starts here.

I'm wondering if the TLS callback to which you refer is aimed at system level threads as opposed to those created by the program itself. I also don't understand how DllMain's can be executed before being called by the app to which they are attached. That would present an interesting scenario for reversing if that was the case.

All statically linked DLLs (i.e. the ones in the import table of the PE executable) are loaded by the system loader before the program begins execution (contrary to the ones that are dynamically loaded with LoadLibrary). Each DLL will execute its DLLMain as soon as it is loaded, i.e. in the case with statically linked imports, before the program hits its exe entrypoint.

The TLS callbacks are another example of such a thing, of which the details I can't run off the top of my head though.

The "code between the MZ header and the PE header" has nothing to do with normal 32 bit execution, but will rather only be seen (and executed) by operating systems that only recognize 16-bit MZ-only executables and don't not know what a PE header is at all. In short, it's for backward compatibility only.

You've presumed correctly. See http://www.woodmann.com/forum/showpost.php?p=41952&postcount=13 ("http://www.woodmann.com/forum/showpost.php?p=41952&postcount=13")


See http://www.security-assessment.com/Whitepapers/PreDebug.pdf ("http://www.security-assessment.com/Whitepapers/PreDebug.pdf")

Regarding TLS, see http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/pecoff.doc ("http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/pecoff.doc") - Section 6.7. By creating a TLS callback for DLL_PROCESS_ATTACH, one can execute code before the EP.

I have no problem with what you're saying with respect to these dll's being loaded before the main app executes. I'm scratching my head a bit over them executing their own code. I'm no expert, however. A dll is a library to me, hence must be static (i.e. can't execute by itself). My understanding is that certain dll's can be run by a module like rundll32.exe, but I've never heard of them running on their own. In fact, when you come down to it, even executables don't run themselves.

I have some excellent books on win 32 systems by Matt Pietrek, Jeffrey Richter and Mark Russinovich (with Solomon) and I've only read enough to make myself dangerous. The loading process, from the time you click on an exe file, till it is up and running, is becoming exceedingly complex, especially in Win 2000/XP. It's amazing to me that all this can be accomplished in the bat of an eye. In fact, the speed is many orders faster than the bat of an eye.

Being (or having been) an electronics/computer technician (I've downgraded to 'electrician') it amuses me how programmers talk about programs as if they have a life of their own. That's taken to an absurd level by OOP programmers who talk about programming 'objects' being representative of the real world. Some will condescend to grudgingly admit that an object is a piece of code. When did we stop talking about code being code and start refering to it as objects, containers, etc. Was that necessary?

Anyway, the processor is the heart of code execution...always has been, always will be. It starts itself through a bootstrap process, which obviously depends on a voltage being present. In fact, the entire notion of 1's and 0's is represented in the real world by +5 volts and 0 volts, although the +5 is now down to about 3 volts. Once started, the processor depends on an external clock, which is a crystal shocked into oscillation by a voltage. It's by sub-dividing the gigahertz frequency of this self-oscillating clock that the time-slicing computer operates.

From that standpoint, no code ever executes on its own, it is the processor executing it. We all know that the code is represented in memory as 1's and 0's, which is represented in RAM by +5(3)/0 volts held in cells. These bits are clocked in and out of the registers of the processor, and the codes represented by the bytes, give direction to the processor. But, the program is essentially inert.

I try to imagine from time to time which is which. I do that partly because I'm a wierdo, and partly because it interests me (which makes me even more of a wierdo). It's amazing to me that on an Intel chip, the paging is actually a function of the chip. I'm sure Microsoft would like people to think it is the code doing it, but it was built into the processor by Intel. What I'm trying to say in this long-winded diatribe, is that technically, even executables don't execute themselves.

I'm not trying to make a big deal out of this, I'm just trying to understand the process. it wasn't till you mentioned dll's executing themselves, that I started thinking it through. Even at that, I'm still mightily confused.



I know there's a tiny bit of code in there for the MZ portion, but I've heard of additional code being inserted into the blank spaces of the MZ header.

I tried to follow your URL's but was blocked by requirements of registering. Don't have time now, but I'm intrigued. I had no knowledge of your history and I hope I didn't raise your hackles in any way. My mention of he/she was totally inadvertant.

Interesting stuff. Your URL can't be reached directly as specified above, if anyone else wants to read the article. I plugged the entire URL into Google and it returned an HTML as well as a PDF. I couldn't get the PDF but got the HTML.

The article talks about a debugger. Is it possible to do this under normal loading conditions?



I didn't even know there was a TLS section in the PE header. Thanks for the heads up.

I googled just "PreDebug.pdf" (without the quotes) and got a number of sources. The second one, at:

www.packetstormsecurity.org/papers/attack/PreDebug.pdf

produced the pdf file and I'm attaching it.


Regards,

each module's dllmain gets called right after the system loads the module, before the main app gets going. The objective is to do a variety of housekeeping, initialization chores, like finding out what the windows version, loading the default settings for any windows it displays, organizing resurces etc (disassembly a couple of dll and you will see the sort of boring stuff dllmain does).
Even if you coded the dll yourself, most of the dllmain stuff is taken care by the compiler/linker, so you would never know that this action is taking place behind courtains.
On the other hand, you can take control from the dllmain and execute any code , function, or even a dirty trick you choose to execute.
If I remember correctly you use those compiler directives like "pragma" to achieve that if you are coding in a dll module in C or C++ .

Thanks JMI. I should have dug a little deeper but the HMTL wasn't too hard to read. I d/l'd your attachment anyway...thanks again.

thanks for the advice. The pdf that JMI posted, that came from disavowed's URL, goes into that too. It's an interesting read. Also, author Jeffrey Richter is good at going into what compiler switches can do. I found it really interesting that the compiler can tell by the kind of Main( ) function you use, whether it's a 32 bit Windoze file, a 16 bit or a DOS app. Also, it can tell whether it's ANSI or Unicode. Pretty smart critters them thar compilers.

I find it interesting too that authors/programming gurus like Richter and Pietrek are really reversers at heart. Richter seems to like sub-classing and hooking functions. It's worth reading one of his books on 32 bit Windoze.



I've got barely enough knowledge about C/Assembler to write a basic program...if I had to. It is amazing how much goes on between the source code and the final exe, though.



that's what the pdf article goes into but it's related to a debugger taking control in a normal process. The article talks about malware intercepting the dll.

Hmm... it's a URL to another page on this site. Are your cookies enabled?


Don't worry about it

Yes, it is. The debugger has nothing to do with it. It just allows you to more easily see what's happening.

It wasn't the URL's you gave for this site, it was: http://www.security-assessment.com/Whitepapers/PreDebug.pdf. JMI tracked the pdf file down elsewhere on the net.

I finally got around to following up your link at Web4Lib. You were in pretty heady company there with them librarians.

I remember when I first went on a hacking/cracking site how paranoid I felt. I could just imagine a bunch of evil-looking hackers waiting for me to connect, and what they could do to my system. The average John Q. Public out there must think the most Machiavellian plots are being hatched on even sites like ours. Paranoia is a peculiar property of the human brain, if you take it in the purest sense of it's meaning, i.e. fear of fear itself.

just a plug for my ollydbg plugin that deals with TLS and Dllmain entry stuff
you can try downloading this plugin for ollydbg
(it comes with source as well as two sample programs that have tls enabled stuff
and they too come with source)
http://www.reversing.be/article.php?story=20050603193932184

also browse through this thread in exetools for some insights into tls stuff
http://forum.exetools.com/showthread.php?t=7363

A short article on TLS callbacks from Ilfaks blog:

http://www.hexblog.com/2005/10/tls_callbacks.html

Not very detailed, but still maybe something for the novice...

Thanks for URL, Delta. Unfortunately, Ilfak didn't go into the TLS Callback in detail but your URL lead me to his blog. I'll d/l his sample and try to run it through the IDA debugger once I learn how to use it.

I read some of the other articles with great interest. If the IDA debugger is stable, it will surely be a major contender with softice and Olly. I like the fact that you can modify the debugger behaviour using plugins, and although it seems that's already plausible with Olly, IDA had a big headstart with respect to plugins.

Thanks for info blabberer. Unfortunately I'm somewhat Olly-challenged at the moment, although I intend learning it. You might follow Delta's URL in the next post to yours to see how IDA is coming along with it's debigger (Clouseau, or spelling???) using plugins.

I remember stepping through the SEH minefield in an Asprotected app and found it interesting that the IDA debugger can bypass the SEH's using plugins and features of the debugger. Makes you want to say...hmmm.

well 2.some console version didnt have a debugger and neither 4.3 freeware gui version has one yeah i read that article some time back and it seems the disassembler too can identify tls callbacks it seems havent tried it yet i am deadlist challenged

as far as side stepping seh minefield you can try options -->debugging options-->
pass following custom exceptions to program in ollydbg so that some exceptions like
eedfade badbabe 2badbabe deafbabe deadbeef exceptions can be passed to the program apart from standard int3 singlestep and access violation exceptions