Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 40

Thread: newbie's question about softice

  1. #16
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,113
    Blog Entries
    5
    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/index.php/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

  2. #17
    Naides is Nobody
    Join Date
    Jan 2002
    Location
    Planet Earth
    Posts
    1,647
    Quote Originally Posted by WaxfordSqueers
    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.
    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

  3. #18
    <script>alert(0)</script> disavowed's Avatar
    Join Date
    Apr 2002
    Posts
    1,281
    Quote Originally Posted by WaxfordSqueers
    the entry point being the very first byte of an app's code the system encounters when it loads the process.
    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.

    Quote Originally Posted by Kayaker
    EP = PE->OptionalHeader.AddressOfEntryPoint
    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.

  4. #19
    Quote Originally Posted by Kayaker
    I'm glad disavowed brought me to task on my misuse of the term.
    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.

  5. #20
    Quote Originally Posted by naides
    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.
    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.

  6. #21
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,113
    Blog Entries
    5
    Quote Originally Posted by WaxfordSqueers
    I think disavowed was testing to see if we were awake
    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).

  7. #22
    Quote Originally Posted by disavowed
    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.
    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.

  8. #23
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    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.

  9. #24
    <script>alert(0)</script> disavowed's Avatar
    Join Date
    Apr 2002
    Posts
    1,281
    Quote Originally Posted by WaxfordSqueers
    With reference to 'he' above, I presume disavowed is a he.
    You've presumed correctly. See http://www.woodmann.com/forum/showpost.php?p=41952&postcount=13

    Quote Originally Posted by WaxfordSqueers
    I also don't understand how DllMain's can be executed before being called by the app to which they are attached.
    See 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 - Section 6.7. By creating a TLS callback for DLL_PROCESS_ATTACH, one can execute code before the EP.

  10. #25
    Quote Originally Posted by dELTA
    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.
    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.

    Quote Originally Posted by dELTA
    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.
    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.

  11. #26
    Quote Originally Posted by disavowed
    You've presumed correctly.
    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.

  12. #27
    [QUOTE=disavowed]See [url="http://www.security-assessment.com/Whitepapers/PreDebug.pdf"[/QUOTE]

    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?

    Quote Originally Posted by disavowed
    Regarding TLS....
    I didn't even know there was a TLS section in the PE header. Thanks for the heads up.

  13. #28
    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,
    Attached Images Attached Images
    JMI

  14. #29
    Naides is Nobody
    Join Date
    Jan 2002
    Location
    Planet Earth
    Posts
    1,647
    Quote Originally Posted by WaxfordSqueers
    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.
    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++ .

  15. #30
    Quote Originally Posted by JMI
    I googled just "PreDebug.pdf" (without the quotes) and got a number of sources. The second one---snip---produced the pdf file and I'm attaching it.
    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.

Similar Threads

  1. Hi newbie here Had a question.
    By magus in forum The Newbie Forum
    Replies: 0
    Last Post: August 10th, 2012, 09:41
  2. newbie question
    By zombie in forum The Newbie Forum
    Replies: 5
    Last Post: November 22nd, 2008, 05:55
  3. A newbie question.
    By DaddyJTHC in forum The Newbie Forum
    Replies: 3
    Last Post: March 2nd, 2004, 06:30
  4. softice for a newbie
    By cornel in forum Tools of Our Trade (TOT) Messageboard
    Replies: 8
    Last Post: January 13th, 2002, 17:26
  5. softice for a newbie
    By cornel in forum Malware Analysis and Unpacking Forum
    Replies: 8
    Last Post: January 13th, 2002, 17:26

Bookmarks

Posting Permissions

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