Page 1 of 2 12 LastLast
Results 1 to 15 of 29

Thread: Microsoft starts to mess with Sysinternals tools

  1. #1

    Microsoft starts to mess with Sysinternals tools

    Well Boys and Girls:

    We knew it was bound to happen. M$ has started to "mess" with the original Systernals files. The following was posted in Exetools today by MarkusO:

    "Today I checked if there where any updates for one or several of my Sysinternals tools. To my suprise, all Sysinternals tools have been rebuilt on November 1st, 2006.

    I compared what was changed. It seems like most code is just a recompile with different compiler settings. Microsoft has also placed a giantic new EULA in each and every executable. (all *.EXE have about the 2x - 4x the size they had before)

    When Microsoft took over Sysinternals, they just packed the old executables together with new licenses. Now it seems they are messing around.

    If you still want to get the latest "Sysinternals" version of your beloved tools, you should do it quickly, since nobody knows how long the old links will be working."

    MarkusO then pointed out that:

    "Just go to the new Sysinternals homepage, grab a link (like<blabla>.zip) and replace "download" with "www". This way you can still get the old (working... ) versions of the tools."

    To make this process somewhat easier for those of you who might not have the patience to complie a list of the available files, here is one I put together from what others posted there and my additions to the list, comparing it to my own download of the Systernals site in August before they went M$ing. If you put this list in your favorite download manager, you can grab the files while they still remain available.

    AccessEnum v1.32 (SRC).zip
    AccessEnum -
    AdRestore v1.1 (SRC).zip
    Autologon v2.1 (SRC).zip
    BlueScreen Screen Saver
    CacheSet v1.0 (SRC).zip
    Ctrl2Cap v3.0 (SRC).zip
    DiskExt v1.0 (with SRC).zip
    Diskmon v2.01 for
    Diskmon v2.01 for
    FAT32 for Windows NT 4.0
    Filemon v7.03 for
    Filemon v7.03 for
    Fundelete v2.02 (SRC).zip
    Fundelete v2.02.exe -
    Junction v1.04 (SRC).zip
    Netstatp (SRC).zip
    NewSID - -
    NTFS for Windows 98 v2.0 (Read-Only).exe
    NTFSCHK v1.0.exe
    NTFSDOS Professional v4.01 (Read-Only).zip
    NTFSInfo v1.0 (SRC).zip
    NTRecover v1.0 (Read-Only).exe
    PendMoves and MoveFile
    Process Explorer v10.2 for
    ProcFeatures v1.1 (with SRC).zip
    PsLoggedOn v1.32 (SRC).zip
    Remote Recover v2.0 (Read-Only).exe
    SDelete v1.51 (SRC).zip
    ShareEnum v1.6 (SRC).zip
    Tokenmon v1.01 (SRC).zip
    Copy this list to your favorite text editor and copy all the URL's you want to a download manager and get them all (or all you want).

    Some of these files are outdated by updates which apparently work on multiple systems, such a Debugview, Filemon, and Regmon, but they are included for the sake of completion of potential files still available.

    By the way, M$ is offering a packed zip file of the "New" versions of these tools. This file contains all the individual (New Compiled, bloated) tools and help files:

    (notice the "download" where the "www" is/should be to get the "original" files.) The "" link is now part of M$ technet.

    You've been warned. Get em while you can.


  2. #2

    Who has them archived? Pre $MS perhaps.

    Send me a PM . I want to host these tools so that everyone
    can still have access to use them.


  3. #3
    Question one:

    Are you SURE you're using the correct link? Just one example, I just tried:

    again and it works file.

    Question Two:

    I have all the files from August and again from today. Sometime tonight or tomorrow I'll upload them to the Server. Do you want to create a folder you would prefer I upload into?


  4. #4
    Quote Originally Posted by JMI View Post
    To make this process somewhat easier for those of you who might not have the patience to complie a list of the available files, here is one I put together from what others posted there and my additions to the list,
    Thanks JMI for the headsup and the list.

  5. #5
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Blog Entries
    I have them all from the day after the "announcement" because, yes, "We knew it was bound to happen". I will double check they match my cache once it's all set up.

  6. #6
    King of Redonda
    Join Date
    Jul 2006
    Blog Entries
    Thanks, links work fine here. I don't know if and when I'll need them, but I'm sure it will come in handy.
    <[TN]FBMachine> i got kicked out of barnes and noble once for moving all the bibles into the fiction section

  7. #7
    There was some discussion about this on the Active Directory list, and Russinovich responded:

    "The growth is primarily due to the EULA. We've come up with a way to shrink
    it and so the sizes will decrease as we update the tools."
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  8. #8
    Heh, Russinovich releases new version of his tools and suddenly they've been "messed with by M$". Gotta love sensionalists.

  9. #9
    If you think files suddenly 2x-4x times larger is a "small" thing, you are, of course entitled to use the "new" versions of the software. And "of course" IF it were JUST THE NEW EULA, one would expect the "increase" to be relatively the same throughout the tools. Here's just a few examples:

    accesschk "original" = 53,248 kb vs. "new" accesschk = 156,712 kb.
    du "original"= 36,864 kb vs. "new" du = 154,424 kb.
    accessEnum "original" = 61,497 vs. "new" accessNum = 166,712 kb.
    LiveKD "original = 147,456 vs. "new" LiveKD = 383,800 kb.
    ShareEnum "original" = 159,795 vs. "new" ShareEnum = 260,976
    Strings "original" = 40,960 vs. "new" Strings = 154,424

    It sure smells like something is going on besides a "new" EULA to explain the varance in increase among these random examples, don't ya think? After all the EULA should be the same in each, isn't it????

    Mark's "original" EULA was 7,005 kb and a seperate file. You do the math. M$ EULA has got to be "over" a 100,000 kb but it should be the same, while these vary substantially.

    But hey, if YOU want to "rely" on M$ being trustworthy with these new tools versions, you go right ahead and just use the "new" ones.


  10. #10
    Well, why don't you check what exactly is different before accusing people out of blue? I've checked accesschk out of curiosity, and didn't find any substantial changes besides the EULA text (and yes, it's a 100KB rtf). If you seriously think Mark has inserted some harmful code just because his company was bought, how about proving it? That's a pretty serious accusation and I doubt he would risk his reputation by doing something silly like that.
    But then again, this is Internet, who cares about proof here... Just find a target big enough and you're suddenly a hero :/

  11. #11
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Blog Entries
    I seriously doubt anyone thinks the new versions might have harmful code in them. That thought would be ludicrous, what would be the point of running Windows at all then? The truly paranoid might think some 'features' or system information might be missing or now "hidden" by some of the utils now that MS has some control over them. I highly doubt that too, but if so, who really cares? Hedge your bets and make your own versions if you're all that concerned.

    The variability in size is probably also due to different compiler settings, and yeah maybe even updates (or downdates) to the code. While I'll stick with the "original" versions until I feel the need to do otherwise, I'd just as soon have any possible bugfixes and enhancements from the Sysinternals crew than worry about a EULA or few hundred KB size increase of these already small apps. Yes, it's just anti-MS sentiment rearing its ugly head again

  12. #12
    And some of us who are neither M$ haters nor paranoid might have reason to "prefer" smaller, more compact software which is not "bloated" with a 100,000 kb EULA. And it is neither paranoid nor M$ hating to suspect, now that M$ has some control over the products, that THEY will decide the ultimate direction of the tools into the future. Afterall, they DO own it now and get final say on what might be included and what might not be.

    This has nothing to do with concern they have put something evil in the software, only a "reasonable" concern that as things go forward they will more tightly control what may be included and what may not be included. This is the nature of how they operate with products they have acquired and not mere "speculation". The Boss gets to have his way, as it should be when the Boss pays the bills.

    It is consistent with this concept that the Systernals guys will not have the "same" freedom they had as independent developers to do whatever THEY want with their tools. If this were not true, all of us would have been rejoicing that their company was "acquired," especially if we truely believed they would now be MORE free to share M$ secrets with the "rest of us." But that is not the way of life, nor M$, or there would have been no need for Systernals in the first place.


  13. #13

    Reminds me of the old Asm vs HLL debate, in which one of the arguments on the HLL side was "compilers will eventually optimise code to such an extent that there will be no need to use Asm".

    Well, it seems compilers have gotten worse. Just look at the sizes of the runtime crap that gets injected into every executable, and compare between e.g. MSC '97 and the latest Visual Studio. I've seen a tenfold difference

  14. #14

    If I was getting paid the amount M$ pays to employees, and to "SPECIAL" employees like Mark, i'd not mind if my exe bloated to 200x. I mean, who has time to listen to the gripes of the users when i'd rather be relaxing in my Microsoft sponsered vacation in bahamas? Hey mark, if you're there try the "Beijing-Chan" hotel. You'll have to "search" for it though.

    have Phun
    Blame Microsoft, get l337 !!

  15. #15
    As I know, before join MS, all the Mark's tool was compiled with VC++ 6, and now they are compiled with native VC++ of VS 2005. Many security and native .NET code were added.

Similar Threads

  1. How to set a breakpointer on a button clicked mess
    By yokishiro in forum OllyDbg Support Forums
    Replies: 1
    Last Post: July 23rd, 2004, 02:46
  2. IAT resolver beta test starts now
    By tsehp in forum Advanced Reversing and Programming
    Replies: 31
    Last Post: January 13th, 2001, 09:10
  3. IAT resolver beta test starts now
    By tsehp in forum Tools of Our Trade (TOT) Messageboard
    Replies: 0
    Last Post: January 3rd, 2001, 06:22


Posting Permissions

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