Jump to content

nonspin

Members

  • Joined

  • Last visited

View Profile Find content

Posts posted by nonspin


    I'll make it short:

    DO NOT TOUCH THIS ADDON.

    Why? For example, have look into "NDP461-KB3154529-x86-x64.reg"

    This is just one sloppy piece which is capable of cross-contermining systems.

    The .reg contains ABSOLUTE PATHs, "C:\windows\". Now what will happen if

    you setup windows on D: -- next to your current one ?.
    How long will it take to screw up BOTH systems, because trying to clean the

    setup on D:\ also screws with c:\

    Now what are the odds, since the author couldn't be bothered to use %windir%,

    that everything else is as sloppy ?

     

    I'll advice everyone to setup chocolatey at at startup batching everything

    crucial - like "choco inst powershell" would deal with everything:

    removing wMF4, insfalling WMF5, DOTNET4.5 and Powershell 5..

     

    Using the "Downloads" from inside of your WinToolkit application to access - let's say ISO's,
    -> in an unregistered state -> ad.fly redirection is enabled.
    Once you have registered your copy of WinToolkit - those ad.fly redirects go away.

    However, ad.fly is just a 5 second advertising placeholder (watch the countdown at the top-right of your page).
    Once it hits "0" - you can proceed to the initial target.

    This is common practice and has nothing to do with malware or infected code.

     

    Congratulations © KEiGHT!  But there still seems to be some figuring out needed, since the original format of the date is MM/DD/YYYY, from looking at the images from abbodi1406, and the format you ended up with in the image above is DD.MM.YYYY, unless that is the format you always see and it is dependent on some local date setting of your machine?  Just curious and trying to get it perfect. :)

     

    Cheers and Regards

     

    The original format is <Highpart> & <Lowpart>

    From there - w32time - will convert it to whatever Location/Region is set.

    Each Location/Region has a defaul Format according to the Language.

     

    for example:

     

    Location: UK

    Default Format: English (United Kingdom)

    Short Date: dd/MM/yyyy

     

    Location: JP

    Default Format: Japanese (Japan)

    Short Date: yyyy/MM/dd

    ·

    Edited by nonspin

    You could skip all the tasks converting times. Simply copy whatever is inside <LASTMODIFICATIONTIME> and replace it with whatever is inside <CREATIONTIME>

     

    for example:

    copy the part in red to notedpad

     

    <LASTMODIFICATIONTIME>

    <HIGHPART>0x01CF83B1</HIGHPART><LOWPART>0xE5F87098</LOWPART>

    </LASTMODIFICATIONTIME>

     

    paste it to:

    <CREATIONTIME>

    <HIGHPART>0x01CF83B1</HIGHPART><LOWPART>0xE5F87098</LOWPART>

    </CREATIONTIME>

     

    This would also reflect the REAL time it was modified and not the value you have generated

    ·

    Edited by nonspin

    you mean Date/Time to Integer8?

    (remove .txt from attached file)

     

    Usage (from CMD)

    cscript DateToInteger8.vbs "06/09/2014 10:30:00 PM"

     

    result:

    Integer8 value: 130468194000000000 (decimal output)

    -> use calc.exe (programmer mode) to convert to hex (QWORD)

    -> 1CF842195DB5400

     

    highpart:01CF8421

    lowpart:95DB5400

     

    validation: w32tm /ntte 0x1CF842195DB5400

    151004 20:30:00.0000000 - 6/9/2014 10:30:00 PM

    DateToInteger8.vbs.txt

    ·

    Edited by nonspin

    In that case, why don't you include the ImageSource date in the title (Operating System) ?

    .. Or better yet, in the description field displaying after you hightlight the item.

    It's also the most promising to actually being editable since the extraction and modifying of the dates isn't that easy.

    Then you would have both types of information visible and not confuse anyone - including yourself.

     

    Editing the modification date to something only you know the means to isn't of much help or value.

    In a perfect world, you would edit the resources of setup and display both items - date created and date modified.

    ·

    Edited by nonspin

    And as I stated before there is no way that running executable would be able to delete itself in normal conditions, as file would be in use.

    There are plenty of ways to so:

     

    - On execution WinToolkit.exe you would spawn one addional process hooking ExitProcess for example

    waiting for the correct trigger and then deleting the file ..  i could come up with at least 5 more ways..

     

    , but i'm pretty sure it unpacks somewhere into 2 or more files and just waits for the child process to close it and dekete the file

    before executing the actual Wintoolkit.exe ... upload the file to VT and post the report

     

    ... or send me link to the file via PM and i'll analyse it and tell you exactly what it does and what it may have done to your system

     

    Something is still not right, though.

    I did a very simple integration job to narrow down the problem

    job: W7x64 ENT + USB3

     

     

    - en_windows_7_enterprise_with_sp1_x64_dvd_u_677651 (untouched)

    - Intel® USB 3.0 eXtensible Host Controller:  1.0.10.255

    - Asmedia_USB3_V11430_XPWin7 (official ASUS)

     

    No errors during integration.

     

    Asus Maximus-V Gene

    Test1: Booting from Intel USB3

    - Shows "CD/DVD Driver missing" aftrer LanguageSelection

    - Selecting "Browse" shows all HDD's and X:Boot (boot.wim)

    - The actual USB3 Drive is NOT present
    FAILED!

     

    Test2: Booting from ASMedia USB3

    - same as above

    FAILED!

     

    Test3: Booting from Intel USB (normal non USB3)

    - SUCCESS, but:
     

    In Windows7 -> DeviceManager

    the Interl-USB3 shows as "Unknown Device" even after pluggin a device to wake it up.

    Now, applying the very same Drivers, which WTK has "successfully" integrated the USB Hub wakes up.

    -> Manual Driver Installion via Device Manager (.inf)

     

    I suspect, that WTK separates the "Intel® USB 3.0 eXtensible Host Controller"

    from "Intel® USB 3.0 Root Hub" and stores one part in the boot.win - the other in install.wim.

    That's the only logical explanation i can come up with.