-
Posts
30 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Events
Posts posted by nonspin
-
-
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.
-
SecureBoot and all the CSM functionality doesn't have any effect on Win 7.
Also UEFI-Boot doesn't work on any other than FAT32.
UEFI doesn't do anything to your Boot-functionality
(other than forcing it into FAT32) and it does not
magically turn your USB into a magic carpet.
Therefore - rethink your approach and opt for compatibility
-
http://www.wincert.net/tips
has no index or 301 redirect set - therefore ends in 404Everything below is fine:
http://www.wincert.net/tips/microsoft-windows -
-
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
-
How much of a difference (MB) is there ?
-
When closing WTK via TaskManager, sometimes temp-files get stuck in a corrupt state. After executing WTK,
it looks for previous configs .. also trying to process the corrupt one(s) - which it doesn't like and commits suicide
-
That's why i use a service to handle 3rd-party/custom themes - rather than patching the files. ;D
-
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
-
Had a look into wimlib ? I think it's an alternative worth considering.
-
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
-
w32tm /ntte 0x1CF83BD00A67400
151004 08:30:00.0000000 - 6/9/2014 10:30:00 AM151004 08:30:00. <- GMT
...
6/9/2014 10:30:00 AM <- relative to GMT (system setting > GMT+2)
-
Highpart/Lowpart explanation:
Highpart: Date
Lowpart: Time
convert/verify: w32tm
example:
<CREATIONTIME><HIGHPART>0x01CB88D1</HIGHPART><LOWPART>0xDB7CCA61</LOWPART></CREATIONTIME>
syntax: w32tm /ntte 0xHIGHPARTLOWPART
Open DOS-Box: (Win+R) CMD
w32tm /ntte 0x01CB88D1DB7CCA61
149707 16:42:02.2122081 - 11/20/2010 6:42:02 PM
-
ahh, now it makes sense here. Thing is, that i never had issues with the displayed date, because i always apply
a custom boot layer to get my USB3 to work properly. Therefore it never showed the wrong date in the setup.
-
probaply, but when someone update that image with latest updates, tweaks.. etc, he would want the image to have new date
Whenever i add updates it reflects that in showing the date i added them. Hence "date modified"
-
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.
-
CreationTime is not what you want to edit and expect any results. LastModified or LastModificationTime
is the entry that gets displayed.
Maybe it's just me, but why would you even want to edit it ? It is the one visible information that tells you how old
the image is you are about to install.
-
The 7z-SFX compression strength is not relevant - it's the self-test verification and a present encryption.
Most authors use "protect SFX (with password)" to prevent manual unpacking .. Now, it would use the password
as an encryption key .. Makes sense, right ?
Upon execution it would first decrypt large chunks in your RAM and verify the contents ...
-
Try Attribute Changer -> http://www.petges.lu/home/
If doesn't work this way, you have to edit the PE_Header or the .xml entry<LASTMODIFICATIONTIME><HIGHPART>0x01CF6C3D</HIGHPART><LOWPART>0x3FF13CBB</LOWPART></LASTMODIFICATIONTIME>
example:
0x538A7B10 = June, 1st 2014 01:00:00 AM
-
If "Allow 3rd Party Themes" is used, does WT patch the .dll's or do you add a service to handle unsigned themes ?
-
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
-
"The application in 0xfc62xxx" is most likely a windows .dll (most likely shell32 or explorerframe)
.. Since it says "written" and your Windows is german - it looks like the Themepatch applied something wrong..
Boot into safe-mode with prompt and run SFC /scannow
-
-
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.
Microsoft .NET Framework 4.8 for Windows 7
in Win Toolkit Addons
Posted
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..