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

Thread: FLEXNet

  1. #16
    <script>alert(0)</script> disavowed's Avatar
    Join Date
    Apr 2002
    Posts
    1,281
    Quote Originally Posted by nikolatesla20
    EDIT: I just downloaded a new version of Hex workshop and it does open physical disk now so I'll play with it
    w00t

  2. #17
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    For a cleaner way than "run and compare", wouldn't it be possible to hook CreateFile and pals, then once the program opens something suspicious (like a drive or partition), breakpoint all file writing functions from that point on, and as soon as it writes something to the handle in question (conditional breakpoint, anyone?) check what offset the file pointer is located at (if nothing else, inject a SetFilePointerEx() call with the correct arguments, and check the return value).

    And to once again ask the obvious, did you monitor it with FileMon or the likes? FileMon normally reports offsets for all I/O operations it logs.

  3. #18
    : Code Injector : nikolatesla20's Avatar
    Join Date
    Apr 2002
    Location
    :ether:
    Posts
    815


    I watched the thing with filemon too but no success.

    I found it now guys, no new trix here at all. Still writing to sector 32 on the hard disk, just like SecureROM did in +Tseph's tutorial. I just used Hex Workshop (the newest version) to open the physical drive and I cleared to zero all sectors from 1 thru 62 (NTFS boot sector is sector 63, and MBR is sector 0). Re-imaged and then re-installed the program, and it's all back to normal again.

    Basically it's really the only part to write on a drive safely, is in that sector buffer area between the MBR and the first partition. In this case there were 61 sectors available that anything could be put in...

    Thanks for the support and the new ideas. Unfortunately nothing new here (well, that may be a good thing since it didn't drive me insane !)

    -nt20

  4. #19
    So it still writes to sector 32. I'm surprised they're still doing that. If your first partition's boot sector began at sector 1 (it's completely possible, and it does work), would the software blindly write over sector 32, destroying what used to be there (FAT or other filesystem data)? This is indeed a highly dangerous software protection system.

  5. #20
    : Code Injector : nikolatesla20's Avatar
    Join Date
    Apr 2002
    Location
    :ether:
    Posts
    815
    no, I think it would work ok because it clearly looks up the MBR and partition table, I saw it read it into memory, so no doubt they are caculating it. But MBR's are always sector 0. And every comp. I've seen so far - the first partition is way above sector 32 (every one I've seen with Win2K or XP start at sector 63).

    -nt20

  6. #21
    : Code Injector : nikolatesla20's Avatar
    Join Date
    Apr 2002
    Location
    :ether:
    Posts
    815
    Learned some more:

    Each time program is run, it creates a "random" GUID and inserts it into the CLSID registry table. This is normal for most protections, however this one puts in valid data into that HKLM\Software\CLSID key so it's impossible to tell that it's fake. Only by watching it with a registry logger (a snapshot of before-after) can you see the new key it inserts.

    When program starts up it deletes the old CLSID key from last time and creates a new one. It also adds a GUID registry key under HKLM\Software\Microsoft\ActiveSetup as well, each time deleting the old one and creating a new one.

    Program has one license file and one license registry entry, both encrypted. Each time program starts, the file gets updated.

    On first run of program it also inserts data into sector 32 of hard disk - to prevent a OS wipe and re-install of product.

    If you delete the license file the program fails to start. If you delete the license file and the license reg key and temp files, AND clear sector 32, the program still fails to start.

    BUT: if you delete the license file, and the license key reg, and the temp files, and clear sector 32, AND delete the 2 registry entries mentioned above (CLSID and "ActiveSetup" Key), program will again start over fresh.

    THEORY:

    One would say, clearly the program must know, if it's using the registry entry under the CLSID, and it changes it every time it starts, it must keep track somewhere what the key was to check for it next time. This is not true however since I deleted every license file and license reg, and sector as mentioned above, but the program still failed to start (still said expired). BUT when I did all of that AND deleted the CLSID and ActiveSetup keys it made, it DID start.

    What that means is the program must just contain an internal list of CLSID's ahead of time that it can use. A nice big list. A list of GUIDS and keys that look real. It then could just enumerate thru the list upon startup. If it finds a CLSID key in its list , but no license files and no license reg key, it can assume expired. If it finds a CLSID key and a license file both, it assumes continue trial (only if encrypted data in license file is ok). If it finds no CLSID key or ActiveSetup key AND no license file AND no license reg key, it assumes brand new and starts over. (Confused yet? ) A pointer to this theory possibly being true is running RegMon during program's startup and watching it enumerate every key under the known universe. No wonder it starts up so slow.

    The hard part of course is knowing which CLSID & ActiveSetup key it's looking for. Before the expiration you can track that..but after I don't think it's possible.

    I've verified the deletion works by moving the calendar back up to 4 days with success. Perhaps a loader which disallows the program to write to CLSID and then of course take care of the other deletions.

    Of course you can always re-image and clear sector 32 and you will also be ok again.

    Just some observations...

    -nt20
    Last edited by nikolatesla20; October 7th, 2005 at 15:15.

  7. #22
    Is it possible that ActiveSetup keeps track of the previous CLSID state ? I assume you compared the ActiveSetup key everytime you start the app. I find quite strange that the app actually incorporate a list of valid CLSID because I presume the CLSID needs to have the time information in it.

    Nevertheless, great work (as usual)

    nathan

  8. #23
    : Code Injector : nikolatesla20's Avatar
    Join Date
    Apr 2002
    Location
    :ether:
    Posts
    815
    I dont think it tracks it that way since the key in ActiveSetup contains only normal text values. No guid strings (except for the keyname itself) and no encrypted strings. I think the protection enums the registry and compares each key to its internal list. That way it never reveals the list.

    I thought of a way to elimiate possibly the CLSID - make a program which scan's CLSID's, and if InprocServer has an entry than open up the file mentioned and verify the key's GUID is indeed in the file. Of course you have to parse the Type Library, but there have been tools for that. Basically it would detect invalid GUIDS in the CLSID tree instead of the other way around like most tools do (most tools detect invalid InprocServer paths, or missing info, etc.). If the GUID is not in the file, or the file has no type library, it's pretty safe to delete the GUID...of course testing on Virtual system would be prudent

    Don't know of a good way to detect an "invalid" ActiveSetup key as of this moment tho.

    If this is really what the protection does, which is what it appears to be doing to me right now, then it's actually pretty well thought up as far as leaving a trail behind which no one can really detect easily.

    -nt20

  9. #24
    I quickly went through the ProgRef and I think you are right, infact, the licensing rights are contained in the so called "Trusted Storage" (fancy, isn't it ?).
    Trusted Storage implements the machine Binding:

    "Binding is used to lock license rights to a machine and prevent them being transferred illegally to another machine. This is implemented by storing identities obtained from the machine in trusted storage. Each time trusted storage is accessed these binding identities are checked and compared with the values held in trusted storage."

    Binding identities are described in the first attached table and a note states the following:
    "Note: Machine serial number, HID_MSN, is only available if anchoring is in use. If there are no anchors in use, then there is no machine serial number. The security of the machine serial number is dependent on the level of security provided by the anchors in use."

    Finally, you can see in the second table that evil Win has more than one anchor ! In particular FIle, Registry and HW based (i.e., track 0) are supported !

    I guess you are right then !

    Good job!

    nathan
    Attached Files Attached Files

  10. #25
    : Code Injector : nikolatesla20's Avatar
    Join Date
    Apr 2002
    Location
    :ether:
    Posts
    815
    Just an example of log files from RegShot.

    Running the software after moving 1 day forward:
    (the files are larger than this but here I am showing the example of the "rotational registry entry")

    This reg file is also created by : Snapshot the system, run the software, exit the software, snapshot the second shot, compare.

    Pay attention to the "Keys Deleted" and "Keys added" sections.

    Code:
    ----------------------------------
    Keys deleted:5
    ----------------------------------
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{2084A42F-F56F-A557-3D48-40C4A91E8802}
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{2084A42F-F56F-A557-3D48-40C4A91E8802}\InprocServer32
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ComPlusMetaDataServices.ActorBvr.2
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ComPlusMetaDataServices.ActorBvr.2\CLSID
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{985439F5-7D1B-A579-B006-63B56A5243A6}
    
    ----------------------------------
    Keys added:6
    ----------------------------------
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{BCA1D4E1-2737-3808-B570-CFCEA624E3EE}
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{BCA1D4E1-2737-3808-B570-CFCEA624E3EE}\InprocServer32
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CDO.Recordset.3
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CDO.Recordset.3\CLSID
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{B9912A09-9F8C-3CF0-F471-D3C73433AF15}
    HKEY_USERS\S-1-5-21-1177238915-789336058-1060284298-500\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Extensible Cache\MSHist012005100820051009

    Now, after exiting the software, setting the day back again (back one day) and running the program again letting the program expire when it warned me it was about to expire because the date was wrong:

    Code:
    ----------------------------------
    Keys deleted:5
    ----------------------------------
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CDO.Recordset.3
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CDO.Recordset.3\CLSID
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{BCA1D4E1-2737-3808-B570-CFCEA624E3EE}
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{BCA1D4E1-2737-3808-B570-CFCEA624E3EE}\InprocServer32
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{B9912A09-9F8C-3CF0-F471-D3C73433AF15}
    
    ----------------------------------
    Keys added:5
    ----------------------------------
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{200DE769-9342-C3B3-E88B-A960D23604B0}
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{200DE769-9342-C3B3-E88B-A960D23604B0}\InprocServer32
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CCWU.DHTMLSafe.2
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CCWU.DHTMLSafe.2\CLSID
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{614DB443-757A-CBDE-C691-B4082CCB9E91}

    As you can see under "keys deleted", it deletes the keys upon startup, that it had created last time upon startup. So each time it starts it deletes the old key it used to start last time, and creates a new key. Unfortunately this key is valid in structure. Also, I found no location where this keyname was stored so it knew where to look next time. I thought perhaps is was encrypted in the license file, but I deleted the license file and everything else I could find, but yet upon startup it still found the correct key to delete ! So 2 options: either it's storing the keyname somewhere else yet that I have yet to find, or it has an internal list of GUIDS that it uses over and over and just fills with valid data. It then Enums the reg. looking for these GUIDS and if found it knows it's been here before - then it checks license file.

    However, I would beg to argue no doubt the GUID is completely fake (the module it indicates no doubt does not contain that GUID) but I haven't looked at that detail yet. But since the key is complete and looks valid it's impossible to track down without knowing, before the program expires, what it put in the registry. Unless of course: I can find the "hidden" area that it's keeping track of the last registry entry it used - OR - find that internal list.

    These are the only things I can think of right now..

    Very well done I shall say.

    -nt20
    Last edited by nikolatesla20; October 10th, 2005 at 10:17.

  11. #26
    Very interesting discussion.

    Can you tell me what exactly is stored in those reg entries? I assume they must contain some information about the expire date.
    If no "non normal" information is stored I would guess that it keeps information about the application as a part of the GUID string.

    One important question... When you posted a string like "{2084A42 F-F56F-A557-3D48-40C4A91E8802}" are there spaces in it or is it a typo? I am asking because a normal GUID would not have spaces as far as I know. This is also interesting for another matter. What would happen incase of collision?
    Lets say (theoretically) that you have a generated GUID which already exists. Then either the program must bail out or it would find another way to solve the problem. Overwriting the GUID would mean doing some destruction on the system.

    Would it be possible to post a sample of how this algorithm might look like?

    Btw. FLEXNet is a new name for a combined FLEXlm and Safecast. So from what it sounds like here, it's a discussion of what was known as safecast before.
    http://www.macrovision.com/products/flexnet_publisher/promotional/index.shtml
    This is (most likely) the promotional licensing module. The reason is that it only works under Win32 as described on the website.

    Thanks in advance.
    Last edited by cyberheg; October 21st, 2005 at 12:10.

  12. #27
    cyberheg,

    for sure flexnet works under Linux as well (since I have the beta version).

    nathan

  13. #28
    Quote Originally Posted by nathan
    cyberheg,

    for sure flexnet works under Linux as well (since I have the beta version).

    nathan
    FLEXnet is splitted up in different modules. So yes you're right and yes I am right. You have the license manager (former known as flexlm) right?

    http://www.macrovision.com/products/flexnet_publisher/licensing/overview/index.shtml

    These are different products. Or are you saying you have the same functionality as what is discussed here in linux? (I doubt that).
    Once you'll tell which module you're referring to, it'll be clear we're talking about two different products.
    Last edited by cyberheg; October 21st, 2005 at 15:52.

  14. #29
    The linux version definitively has the publisher (not only the license manager AKA flexlm).
    I haven't tested it, yet (since I'm focusing (in my little spare time) on the Win version).
    However, what is not going to be the same is the so called "Trusted Storage" (which also uses the registry info under Win). If I'm not wrong the linux version will be file based instead of registry based.

    nathan

  15. #30
    Quote Originally Posted by cyberheg
    One important question... When you posted a string like "{2084A42 F-F56F-A557-3D48-40C4A91E8802}" are there spaces in it or is it a typo? I am asking because a normal GUID would not have spaces as far as I know.
    Theforumsoftwareputsspacesintoreallyreallyreallyreallyreallylongwords.

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
  •