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

Thread: Microsoft's Rich Signature (undocumented)

  1. #16
    Super Moderator Shub-nigurrath's Avatar
    Join Date
    May 2004
    Location
    Obscure Kadath
    Posts
    430
    A thing I don't understand is why I cannot debug the linker with a Ring3 debugger..
    (`._.[*~-.,.-~* ŜħůβŇĝŕřāŧħ ₪*~-.,.-~*]._.)
    There are only 10 types of people in the world: Those who understand binary, and those who don't
    http://www.accessroot.com

  2. #17
    Registered User
    Join Date
    Jan 2008
    Posts
    163
    Blog Entries
    19
    Try...

    See for yourself.

    If you manage to do it, good for you! =)

    EDIT: ok maybe I haven't been clear about this. In theory it's possible, but first of all you have to recreate a working command line with all the libs etc. And that's something. Then you have to set the right environment, if you just try and run one of the tools in the bin directory it tells you that a dll is missing. You can take the dll from the IDE directory and place it in the folder but it's all horrible. Attaching the ring 3 debugger during execution time doesn't work at all, I can guarantee that. Using softice was just like paradise.
    Last edited by Daniel Pistelli; March 6th, 2008 at 13:10.

  3. #18
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    A little clarification about what Daniel is trying to say:

    The real problem with a "ring 3 debugger" in this case is that it does not normally trivially set system wide breakpoints, and since the linker is invoked in the background by Visual Studio (and also has a longish command-line and inherits and makes use of environment info from the parent process etc) and also only lives for a very short moment, the problem is to either catch it just as it is being started this way, or to emulate all these somewhat complex conditions when starting it stand-alone.

    So, it's not really the "ring 0" aspect that's wanted, but rather the system wide breakpoint aspect, or actually, rather just the ability to catch this background process on the fly in an efficient way, for which system wide breakpoints is one efficient method.

    How about the old spinning jump trick though, shouldn't that work pretty well? Did you try that Daniel? Is that perhaps what you mean by "attaching during execution", and in that case it is a little interesting why it wouldn't work?
    "Give a man a quote from the FAQ, and he'll ignore it. Print the FAQ, shove it up his ass, kick him in the balls, DDoS his ass and kick/ban him, and the point usually gets through eventually."

  4. #19
    Super Moderator Shub-nigurrath's Avatar
    Join Date
    May 2004
    Location
    Obscure Kadath
    Posts
    430
    I understand. I was thinking about some strange linking time optimizations involving drivers and things like that and was at all sounding strange. Now's clear, of course sice is handy. BTW the spinning jmp trick is the thing I would try for first, if I had time of course..-sigh-
    (`._.[*~-.,.-~* ŜħůβŇĝŕřāŧħ ₪*~-.,.-~*]._.)
    There are only 10 types of people in the world: Those who understand binary, and those who don't
    http://www.accessroot.com

  5. #20
    Registered User
    Join Date
    Jan 2008
    Posts
    163
    Blog Entries
    19
    How about the old spinning jump trick though, shouldn't that work pretty well? Did you try that Daniel? Is that perhaps what you mean by "attaching during execution", and in that case it is a little interesting why it wouldn't work?
    Oh yes. Of course, I tried that too. Doesn't work the process gets terminated. I guess by another thread which is checking the execution flow or the IDE. I don't knwo.

    Thanks for clarifying what I was trying to say, dELTA!

  6. #21
    Naides is Nobody
    Join Date
    Jan 2002
    Location
    Planet Earth
    Posts
    1,647
    A lazy man's trick:
    For capturing complex command-line stuff I have used in similar situations
    If you have Russinovich Process Explorer running in the background, you can catch the linker process being created and run in the background, as a child process of Visual C or whoever spawns it. If you right click on it and choose properties, you get, among other things, the command line in all its glory, that you can copy and paste for whatever use you please. If the Linker's lifetime is too short for you to "catch" it in Process Explorer, you can change the Proc-Explorer highlight duration option so that those lighting disappearing processes (This is conceived to catch sneaky malware processes usually) are kept visible and highlighted for 10 to 20 seconds after the process has finished, with all its plethora of information, including the folder where the executable is located, as well as the command line, available.

  7. #22
    Registered User
    Join Date
    Jan 2008
    Posts
    163
    Blog Entries
    19
    Well, I could've debugger the IDE to get the command line, but still I wouldn't have the environmnet set up for the linker. It's a nice trick yours, but in the end command line + environment settings is just too much work. A system wide breakpoint was an immediate solution. If only I hadn't had VM problems on Vista64.

    Thanks for sharing.

  8. #23
    If your using VS2005, it comes with "Visual Studio 2005 Command Prompt" which sets the env variables. Also in VS2005, the linker/compiler command line listing for a project/solution can be seen from Project->Properties->Configuration Properties->(C/C++ or Linker)->Command Line
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  9. #24
    Registered User
    Join Date
    Jan 2008
    Posts
    163
    Blog Entries
    19
    Didn't even remember there was a command prompt. I used the command prompt only with DDK which currently I don't have on my computer (otherwise I would have used that). I got the command line from the properties as you said, but as I didn't have the environment set I thought the command line was incomplete. Of course, it works with the environmnet set. But still, we get back to the main issue, I have to attach myself to the executed process, this time by cmd.exe (the command prompt of Visual Studio) rather than the IDE. It's just the same. Ok, maybe I am just lazy and never got used to work with ollydbg, but if the solution is the command prompt I could've used the IDE in the first place to run the linker.

    I am sure there is a way to attach myself to the process created by the IDE or the prompt, I was just too lazy to look it up. And with softice it took me 1 second to break into the linker's code.

    Anyway, good that you remembered us all that VS2005 comes with the command prompt like the DDK. I actually put the damn missing dll into the folder to run dumpbin. Now we now how to do that without being as stupid as I have been.

  10. #25
    Registered User
    Join Date
    Jan 2008
    Posts
    163
    Blog Entries
    19
    Update:

    http://ntcore.com/Files/richsign.htm

    Solved the meaning of @comp.id. It's just the compiler major and minor version.

    Just wanted to let you know so that the topic can be closed once and for all.

    EDIT:

    To make things easier, I wrote a little script to correctly display the data contained in the Rich Signature. Here's a little screen shot of the script's output:

    Last edited by Daniel Pistelli; May 3rd, 2008 at 11:33.

  11. #26
    Edit: I'm a little late to the party, but with regard to the business of attaching to the secondary instance of link.exe:

    If I understand the problem correctly, this is more of a problem with OllyDbg than anything else. Olly choses to DEBUG_ONLY_THIS_PROCESS, so you're somewhat screwed when devenv.exe launches the linker. But if you were to use WinDbg with 'Debug child processes also' selected (in the 'Open Executable' dialog), it will automatically attach to all descendent processes, and even be kind enough to break as soon as the new process is created, provided you set the event filters accordingly.
    Last edited by Admiral; May 3rd, 2008 at 12:05.
    www.ring3circus.com
    Diary of a programmer, journal of a hacker.

  12. #27
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,487
    Blog Entries
    15
    well if thats the problem one could simply compile and link seperately isnt it

    cl -c blah.c
    link blah.obj

  13. #28
    Registered User
    Join Date
    Jan 2008
    Posts
    163
    Blog Entries
    19
    blabberer: actually your suggestion wouldn't work, since that way you won't have the environmnet set for the compiler. We already went in this thread through the VS Prompt approach.

    Admiral is right about his solution and it's really time to start using windbg again. I used it to debug device drivers, but as some years have passed I forgot most of the how-to. Somehow softice was deeply buried in memory and I've been glad to use it again, maybe (who knows) for the last time.

  14. #29
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,487
    Blog Entries
    15
    dunno never much played with vs vc ides and its property thingies

    but with plain command line and bcc ive stepped through compilers

    just to see if i can still do it

    i opened up ollydbg

    Log data, item 13
    Message=Console file 'E:\Borland\BCC55\Bin\bcc32.exe'
    Log data, item 12
    Message=Arguments 'blah.c'

    runtraced the whole compiler process and logged it to a file 62020 kb long

    trapped it on createprocess of ilink32

    Code:
    0012FD84   0012FE18  |ModuleFileName = "E:\Borland\BCC55\Bin\ilink32.exe"
    0012FD88   009528FC  |CommandLine = "ilink32.exe  @turboc.$ln"
    0012FD8C   0012FE0C  |pProcessSecurity = 0012FE0C
    0012FD90   0012FE0C  |pThreadSecurity = 0012FE0C
    0012FD94   00000001  |InheritHandles = TRUE
    0012FD98   00000000  |CreationFlags = 0
    0012FD9C   00000000  |pEnvironment = NULL
    0012FDA0   00000000  |CurrentDir = NULL
    0012FDA4   0012FDC8  |pStartupInfo = 0012FDC8
    0012FDA8   0012FDB8  \pProcessInfo = 0012FDB8
    found whats the command line thats getting invoked from the temp file

    Code:
    E:\borland\bcc55\lib\c0x32.obj+
    blah.obj
    blah.exe
    /Gn/L"E:\borland\bcc55\lib\"/c/x/ap/Tpe
    E:\borland\bcc55\lib\import32.lib+
    E:\borland\bcc55\lib\cw32.lib
    spin jumped the ilink32

    Code:
    left the compiler looping on wait for single object 
    Handles, item 22
     Handle=00000064
     Type=Process
     Refs=  10.
     Access=001F0FFF SYNCHRONIZE|WRITE_OWNER|WRITE_DAC|READ_CONTROL|DELETE|QUERY_STATE|MODIFY_STATE|FFC
    
    
    0012FDA0   0049FC7C  /CALL to WaitForSingleObject from bcc32.0049FC77
    0012FDA4   00000064  |hObject = 00000064
    0012FDA8   FFFFFFFF  \Timeout = INFINITE

    here is a call stack

    Code:
    Call stack of main thread
    Address    Stack      Procedure / arguments                                                    Called from                   Frame
    0012FDA0   0049FC7C   <JMP.&KERNEL32.WaitForSingleObject>                                      bcc32.0049FC77                0012FF28
    0012FDA4   00000064     hObject = 00000064
    0012FDA8   FFFFFFFF     Timeout = INFINITE
    0012FF2C   0049F538   bcc32.0049F978                                                           bcc32.0049F533                0012FF28
    0012FF30   00000000     Arg1 = 00000000
    0012FF34   004A31FA     Arg2 = 004A31FA ASCII "ilink32.exe"
    0012FF38   0012FF54     Arg3 = 0012FF54
    0012FF3C   00000000     Arg4 = 00000000
    0012FF40   00000001     Arg5 = 00000001
    0012FF48   00401794   bcc32.0049F520                                                           bcc32.0040178F                0012FF44
    0012FF4C   00000000     Arg1 = 00000000
    0012FF50   004A31FA     Arg2 = 004A31FA ASCII "ilink32.exe"
    0012FF54   004A31FA     Arg3 = 004A31FA ASCII "ilink32.exe"
    0012FF58   004A3206     Arg4 = 004A3206 ASCII " @turboc.$ln"
    0012FF5C   00000000     Arg5 = 00000000
    0012FF70   004016E6   bcc32.00401738                                                           bcc32.004016E1

    attached another instance of ollydbg to the infinitely spinning ilink32

    00401000 >-EB FE JMP SHORT ilink32.<ModuleEntryPoint>

    runtraced through the linker process and logged it for an hour
    and got an 850 mb log file

    Directory of E:\Borland\BCC55\Bin

    05/03/2008 11:27 PM 63,507,544 rtrace.txt
    05/04/2008 12:27 AM 833,661,462 rtracelink.txt
    2 File(s) 897,169,006 bytes
    0 Dir(s) 10,716,741,632 bytes free

    the linker finished its job in one hour
    and i hit my break point at compiler

    Log data, item 0
    Address=0049FC7C
    Message=Breakpoint at bcc32.0049FC7C

    Code:
    0049FC6E  PUSH -1                                  ; /Timeout = INFINITE; Case 0 of switch 0049FC5C
    0049FC70  MOV EDX,DWORD PTR SS:[EBP-170]           ; |
    0049FC76  PUSH EDX                                 ; |hObject
    0049FC77  CALL <JMP.&KERNEL32.WaitForSingleObject> ; \WaitForSingleObject
    0049FC7C  LEA ECX,DWORD PTR SS:[EBP-4]

    saw what is the exit code for the newly created process

    Code:
    0012FDA0   0049FC8C  /CALL to GetExitCodeProcess from bcc32.0049FC87
    0012FDA4   00000064  |hProcess = 00000064
    0012FDA8   0012FF24  \pExitCode = 0012FF24
    let it delete the lnk file after checking var Do_NOT_DELETE_LNK_FILE

    Code:
    0012FF60   0049B528  /CALL to DeleteFileA from bcc32.0049B523
    0012FF64   004A3208  \FileName = "turboc.$ln"
    and let the compiler die

    it had created a blah.exe which greets you

    Code:
     Directory of E:\Borland\BCC55\Bin
    
    05/03/2008  11:26 PM                97 blah.c
    05/03/2008  11:39 PM               480 blah.obj
    05/04/2008  12:26 AM            52,224 blah.exe
    05/04/2008  12:26 AM           393,216 blah.tds
                   4 File(s)        446,017 bytes
                   0 Dir(s)  10,716,749,824 bytes free
    
    E:\Borland\BCC55\Bin>blah.exe
    hello Daniel Pistelli
    
    E:\Borland\BCC55\Bin>

  15. #30
    Registered User
    Join Date
    Jan 2008
    Posts
    163
    Blog Entries
    19
    The compiler of the visual studio needs certain environmnet variables set, that's why the direct cl bla.c approach won't work. Your procedure could be use when compiling through the VS prompt, but it takes certainly longer than just setting a system wide breakpoint or the very clean solution suggested by Admiral (which is certainly better than my one, as long as one remembers how to use windbg). Anyway, any method is imho valid as long as the job gets done.

    I'm a bit surprised that dELTA hasn't posted yet. He surely is interested in the latest findings which close the rich signature topic once and for all.

Similar Threads

  1. AMD processors "undocumented" debugging features and MSRs (DbgCtlMSR2 & al.)
    By Czernobyl in forum Advanced Reversing and Programming
    Replies: 51
    Last Post: December 1st, 2010, 07:31
  2. Microsoft Inline Assembler
    By OHPen in forum Advanced Reversing and Programming
    Replies: 5
    Last Post: January 25th, 2010, 17:32
  3. Windows undocumented native API, interesting article updated
    By dELTA in forum Advanced Reversing and Programming
    Replies: 2
    Last Post: November 29th, 2004, 12:02
  4. Microsoft C# and Basic .NET
    By fifthelement in forum Malware Analysis and Unpacking Forum
    Replies: 3
    Last Post: July 21st, 2004, 15:21
  5. Replies: 0
    Last Post: March 7th, 2003, 14:20

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
  •