Page 1 of 3 123 LastLast
Results 1 to 15 of 33

Thread: Microsoft's Rich Signature (undocumented)

  1. #1
    Registered User
    Join Date
    Jan 2008
    Posts
    163
    Blog Entries
    19

    Microsoft's Rich Signature (undocumented)

    In the last days I've been quite sick, so I decided that as long as I had to stay in bed I might at least use the time to do something useful (or quite so). What happened is that someone asked what the Rich Signature was. It might seems strange but in all these years I didn't even notice it, I just overlooked it as part of the dos stub (incredible but true). Unable to answer, I noticed together with this person that the subject was completely undocumented. It might not even be much important, but you might find it an interesting reading after all.

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

    Since information about this topic is non-existent, the reader might not know what I'm talking about:

    Code:
    00000070  6D 6F 64 65 2E 0D 0D 0A 24 00 00 00 00 00 00 00  mode....$.......
    00000080  E7 B3 9D E7 A3 D2 F3 B4 A3 D2 F3 B4 A3 D2 F3 B4  糝
    00000090  60 DD AC B4 A8 D2 F3 B4 60 DD AE B4 BE D2 F3 B4  `ݬ`ݮ
    000000A0  A3 D2 F2 B4 F8 D0 F3 B4 84 14 8E B4 BA D2 F3 B4  󴄎
    000000B0  84 14 9E B4 3A D2 F3 B4 84 14 9D B4 3F D2 F3 B4  :󴄝?
    000000C0  84 14 81 B4 B3 D2 F3 B4 84 14 8F B4 A2 D2 F3 B4  󴄏
    000000D0  84 14 8B B4 A2 D2 F3 B4 52 69 63 68 A3 D2 F3 B4  Rich
    000000E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    000000F0  00 00 00 00 00 00 00 00 50 45 00 00 4C 01 04 00  ........PE..L.
    The data between the dos stub and the PE Header. It ends with the word Rich. It is produced by microsoft VC++ compilers only and it is encrypted.

    To dELTA who has been hunting me down for this article for more than a week: I hope you're satisfied now! Damn swedish bloodhound! =)

  2. #2
    Registered User
    Join Date
    Dec 2005
    Posts
    216
    Blog Entries
    5
    My good sir,

    there is bored
    then there is BORED bored.
    and then there is HOW FUCKING BORED DO YOU HAVE TO BE TO DO THIS KIND OF LDFKJHNDFCKL? bored.

    Care to guess which category you fall into?

    But seriously, that was kind of an interesting (albeit long) read. Lot's of stuff I didn't quite understand that I'll have to look up. Good job

    -rendari

  3. #3
    Registered User
    Join Date
    Aug 2005
    Location
    Italy
    Posts
    133
    Blog Entries
    31
    Another great Work

    Congratz Daniel

    Have a nice Day,
    Evilcry

    http://evilcry.netsons.org (Repository)
    http://evilcodecave.blogspot.com
    http://evilcodecave.wordpress.com

  4. #4
    Super Moderator Shub-nigurrath's Avatar
    Join Date
    May 2004
    Location
    Obscure Kadath
    Posts
    430
    wondeful job mate, really interesting reading.
    (`._.[*~-.,.-~* ŜħůβŇĝŕřāŧħ ₪*~-.,.-~*]._.)
    There are only 10 types of people in the world: Those who understand binary, and those who don't
    http://www.accessroot.com

  5. #5
    Very impressive, I like it very much. I find very interesting all your reversing work, and of course, the way of deleting such useless information in the header of the file.

    Please, could you consider writting down some paper about .lib format? Many of us would find such document "a must to have" for facing any reversing task...

    Grazie tante!

    Nacho_dj

  6. #6
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,204
    Blog Entries
    5
    Excellent writeup and research Daniel, seems it was worth the wait after all!

    I also made a PDF of it and attached it to this post, for archival purposes.

    The reason for why I'm extra interested in this is that I was wondering about this same data many years ago too, when I was experimenting with building my own exe files. You can see a question of mine related to this here:

    http://www.woodmann.com/forum/showthread.php?t=4499

    I asked the same question over at the asmcommunity board at the time, which fortunately got some more attention than my local post here :

    http://www.asmcommunity.net/board/index.php?topic=11182.0

    What really made it interesting though, was that someone actually posted a reverse/documentation of this header in the following thread, which was subsequently removed completely, without a trace, which added even more to the conspiracy feeling:

    http://www.asmcommunity.net/board/index.php?topic=14699

    You can see my hunt for what happened to that data in those threads, even the "@comp.id" reference is mentioned in them once.

    So, I'm really glad that we can close this mystery once and for all (even though I guess it's not really closed until the real origin of the value from the compiler is traced/reversed by someone... )!

    Again, very nice work Daniel!
    Attached Images Attached Images
    "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."

  7. #7
    Registered User
    Join Date
    Jan 2008
    Posts
    163
    Blog Entries
    19
    Thanks to all you guys! Wasn't expecting so many comments!

    However, dELTA what was said in those threads about the @comp.id doesn't really apply. It seems that MASM was producing a fake signature (just comp.id string xored randomly). I think the guy voluntary deleted his own post when he noticed that they were not the real answer to the question. But initially, I have to admit, it added to the mystery. Why were those post canceled, by who? Now, we know the answer. They were just not true, because based on a MASM signature and most probably the owner of these posts deleted them. I can't find another answer otherwise. It's not like it's a big secret or something.

    rendari: I guess I would fall into the FOURTH category. The one you didn't mention. I was even more bored ahahah.

    Nacho: If I add support for the CFF Explorer I will surely write an article about those formats. That's a promise.
    Last edited by Daniel Pistelli; March 5th, 2008 at 06:37.

  8. #8
    iirc this was already partly covered in some cracking tutorial, there's also a tool called 'signfinder' which helps with patching the linker itself.
    still an interesting read, though

  9. #9
    Registered User
    Join Date
    Jan 2008
    Posts
    163
    Blog Entries
    19
    Thanks. It's funny but at the beginning I thought of patching the linker myself, but then I figured out that I would have to patch:

    x86 linker
    x64 linker on x86
    x64 linker on x64 (compiled in x64 i mean)
    IA64 linker on x86
    IA64 linker on IA64
    Arm linker for WinMobile
    etc.

    And this with every update!!!

    I figured out that it was way better writing a little script that does even something more than just removing the signature. But that's your personal choice.

  10. #10
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,204
    Blog Entries
    5
    I have seen references to a tutorial by "goppit" (ARteam member?) about the rich signature, or at least about how to remove its creation from the linker (I doubt anyone has done a nearly as thorough analysis/documentation as Daniel just did though), but I cannot seem to find it at the moment.

    Attached is the SigFinder tool (by Asterix) anyway, for reference. It contains a very small document about the Rich signature too (in Russian), but it looks to be meant mainly just to explain what the program does. Anyone who can read Russian is welcome to confirm that.

    Oh, and the SigFinder tool supposedly doesn't work for more recent version of the linker, which is just the problem to expect with such a solution, just like Daniel implies above.
    Attached Files Attached Files
    "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."

  11. #11
    Super Moderator Shub-nigurrath's Avatar
    Join Date
    May 2004
    Location
    Obscure Kadath
    Posts
    430
    oh well, given that this entire subject is going to be revitalized here something I can contribute, again thanks to goppit for the discussions on this subject, well we were talking of this more than an year ago, then things are quite "mature" now.

    quoting:
    What was known is that these rich information contains info about your computer (a "@comp.id" identifier) and some virus writers were caught because M$ used this info to prove that the virus had been compiled on thier computer.

    The "@comp.id" identifiers are XORed before being put into the stub:
    MS ML.EXE Ver.6.14.8444 -> comp.id is 1220FC(You can search: FC2012)
    MS ML.EXE Ver.7.00.9466 -> comp.id is 4024FA(search: FA2440)
    MS ML.EXE Ver.7.10.2179 -> comp.id is 0F0883(search: 83080F)
    MS ML.EXE Ver.7.10.3077 -> comp.id is 0F0C05
    (`._.[*~-.,.-~* ŜħůβŇĝŕřāŧħ ₪*~-.,.-~*]._.)
    There are only 10 types of people in the world: Those who understand binary, and those who don't
    http://www.accessroot.com

  12. #12
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,204
    Blog Entries
    5
    Hey Shub, interesting indeed. But was there any proof/documentation of that statement (i.e. the "info about your computer" part)? I'm asking since it does not seem to match the empirical results of Daniel's investigation above?

    Or do you mean that only the linker version is stored in that data, and not any further info about the computer than that (and that was enough to "catch" those virus writers)?
    "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."

  13. #13
    excelent work..

    as alwasy...

  14. #14
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,204
    Blog Entries
    5
    Some more info just posted at OpenRCE, as a result of Daniel's article being posted there too:

    Quote Originally Posted by igorsk
    I had a look at where @comp.id is generated, and its value is basically the compiler's build number (low word) plus some compilation flags (high word).
    I guess MS puts it into executable to be able to determine which compiler version(s) were used to produce it.
    Also, the following 29a article/analysis of the Rich signature (again, still less comprehensive than Daniel's) was referenced (http://mirror.sweon.net/madchat/vxdevl/vxmags/29a-8/Articles/29A-8.009), which funny enough references this board and some members of it :

    Quote Originally Posted by lifewire
    : things they didn't tell you about ms link and the pe header : lw, 7 july 2004 :



    * Introduction

    The linkers from microsoft store information about used compiler versions
    to create the object and library files in the EXE files they produces. This
    information is stored right after the DOS stub, and before the start of the
    actual PE header.

    Appearantly they wanted to hide it, since all this stuff is encrypted using
    checksums and other weird ways. I must say that I don't understand much of
    the way they built up the structure, it is inefficient and simply weird.

    Also I don't see much use of it, unless in some strange lawsuit or something
    where the question is: is this .exe file created by this compiler+linker?
    Or: are these .lib's used to create this exe file? Still then there is no
    good evidence, because only the used compiler versions are stored, compilers
    which are used by thousands of other people too. And why does microsoft use
    this strange encryption and such?

    Well, as you might see, enough questions about the reason why it exists -I can't
    tell you much about the use of it- but maybe I can tell you something in this
    article about the structure of this stored data though.

    * The Rich-Structure

    The name "rich" is used because of one field of the structure, which contains
    the ASCII values that form "Rich". After the DOS stub the "rich" structure is
    stored. This structure is created by the ms linker and consists mainly of compiler
    id's which are gathered by the linker from the used .obj and .lib files. These
    compiler id's are stored in the files by the ms compiler in the 'comp.id' fields,
    and contain the version number of the compiler. Newer linkers from ms also add
    their linker id to the exe file.

    The "rich" structure is in the following format:

    a, b, b, b -- identification block / header?

    compid^b, r^b -- from 0
    .. -- :
    compid^b, r^b -- to n

    'Rich', b -- terminator

    padding

    Where all variables are dwords. b is the checksum i'll describe later, and
    a=b^0x536e6144. This value is a hardcoded value and appearantly always used.
    compid is the compiler id and b is the number of times it was encountered
    over all the lib/obj files (that is an assumption, i'm not 100% sure). And
    n is number of stored compid's. compid's are dwords too, the lower word is
    the minor version number (0-9999 decimal), the high word is the major
    number. i don't know how the high word is encoded, but 13.10 appears is
    encoded as 0x60, and 7.10 as 0x5a. and yes, i see that 0x60-0x5a is the same
    as 13-7 decimal, but where did the 0x53 (0x60-13decimal) came from? and where
    is the 10 from the verison number stored?

    The size of the "rich" structure is ((b/32)%3 + n)*8 + 0x20 bytes. the unused
    space is padded with zeroes.

    b is calculated in these steps:

    b=sizeof(dos_stub) // (almost always 0x80)

    then the checksum of the dos_stub, with the pointer to the PE zeroed out, is
    calculated in the following way:

    for(int i=0; i<sizeof(dos_stub); i++)
    {
    b += dos_stub[i] ROL i; // ROL is the x86 rotate over left operation.
    }

    when the default dos stub of 0x80 bytes is used, b contains now 0x884f3421

    next, a checksum over the various compiler id's is calculated in this way:

    for(int i=0; i<n; i++)
    {
    b += compid[i] ROL r[i];
    }

    as stated above, r appears to be the number of times that compid is
    encountered in the libs/objs.


    * Conclusion

    The linker doesn't store your the MAC address of your NIC nor your DNA profile,
    but better remove it anyway . You can write a very simple tool that will
    zero out the rich structure given an exe file, or patch your linker so that it
    won't get written at all. For my investigation I used the Microsoft Visual C++
    Toolkit 2003 with the "same compiler and linker that ship with Visual Studio
    .NET 2003 Professional!" which you can download for free from microsoft.com,
    google for "VCToolkitSetup.exe". You can locate the interesting parts of code
    by searching link.exe for the string 'Rich' or in the function starting at
    0x459090.

    * Some additional last minute notes:

    Disavowed told me on the RCE board that the constant 0x536e6144 is equal to
    Dan^ in ASCII, and Silver had an some additional information about "Dan":
    Dan Ruder, Mechanics of Dynamic Linking, Microsoft, MSDN Library 1993, as
    referenced by patent 6253258 filed by Symantec for "Subclassing system for
    computer that operates with portable-executable (PE) modules". Well, that must
    be "our" magic Dan, shouldn't he?

    Thanks goes out to my good friend malfunction for making me interested in the
    Rich stuff, to StarZer0 for a lot of things, and to a lot of other guys who
    make the scene a nice place to be.


    If you have anything to tell me, don't hesitate to contact me.


    :lifewire / ikx - lifewire$mail.ru - ikx.cjb.net:
    "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."

  15. #15
    Super Moderator Shub-nigurrath's Avatar
    Join Date
    May 2004
    Location
    Obscure Kadath
    Posts
    430
    @dELTA
    no direct information. I just reported what I know..

    Most of the thread were reporting wrong conclusions or just partial. On openRCE there's also this nice link I didn't know: http://mirror.sweon.net/madchat/vxdevl/vxmags/29a-8/Articles/29A-8.009
    nothing much more of what Daniel wrote.

    on the google cache version of this page: http://www.donationcoder.com/Forums/bb/index.php?topic=11956.msg101196 (no more directly available) you can also find an old interesting discussion. It seems to me that no one really found what those informations are placed for and used a conservative approach, just skipping them totally.

    The real final proof is to compile the same program on two machines and compare.

    Edited: seems like me and dELTA likes to post the same thing at same time ^_^
    Last edited by Shub-nigurrath; March 6th, 2008 at 04:30. Reason: seems like me and dELTA likes to post the same thing at same time ^_^
    (`._.[*~-.,.-~* ŜħůβŇĝŕřāŧħ ₪*~-.,.-~*]._.)
    There are only 10 types of people in the world: Those who understand binary, and those who don't
    http://www.accessroot.com

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
  •