AutoPatcher XP x86 Hotfix Depot
Posted 23 June 2011 - 06:19 PM
Posted 23 June 2011 - 10:09 PM
about someone else, for sure that it's required. the url123 issue is back and the last time that someone fixed that thing we had the worst spammer attack that i can remember. worst: i was unable to raise anyone to the rank that could help with that
Posted 24 June 2011 - 01:01 AM
It looks like you can reach the ftp once again, you updated XP_SP3_Enu, the XP users will appreciate this.
I was hoping to get you before you did the update, I wasn't sure if you noticed I had moved a few files to a separate download:
In case you update Extras, I did something similar. The files that get updated the most are Flash, Shockwave, and Silverlight so I moved these 4 apm files to their own archive, again, for me it was a snap - you can change back if you want.
I have emailed Frank about the redirect issue, I'll give him some slack about not getting right back, he's recently moved, from one state to another so I'm sure he's trying to get things together in a new place. I'll try and keep an eye on the spam until Frank gets a new PM, hopefully it wont get out of control like last time.
Posted 24 June 2011 - 02:18 AM
but the xp script seems to be lacking certain files or there's some kind of problem with certain updates. i've noticed that certain updates that i've listed are present in the script and they also show as installed when running ap. so, the problem could be related to wu not detecting that the update already is in place (what a news...) or there's an new version of those. in any case, i've downloaded each one and i will check it the file that wu downloaded is the same. but first i will wait until the pain get easy. at least, this one doesn't last for more than 3 days (usually)
Posted 24 June 2011 - 02:41 PM
wmp 11: 20100622
it may be an silly idea, but seems that all those are deployed before wmp11 and still wu is asking for those, then wmp11 may be ignoring the new files and creating again the need for those updates, that must be deployed after wmp11 be in place. the problem: those updates work for all wmp versions, including the one that arrives with xp. given so, possible solutions:
- edit the wmp11 module, to deploy those after himself, doesn't matter if those are in place or not;
- edit the wmp11 deploy date, to make wmp11 be deployed before those;
- change the detection of those modules be certain key files that are put in place with those updates. so, if any update deploy an older version, the deploy status will return to the "not in place" status and the user will be allowed to deploy them again or not
Posted 24 June 2011 - 04:51 PM
"Module:\wmp11-windowsxp-x86-enu.exe" /q:A /c:"setup_wm.exe /Q /R:N /P:#e /DisallowSystemRestore /SetWMPAsDefault"
"autopatcher:\modules\Critical\__WMP_critical\KB973540_xp_x86_enu.apm_files\WindowsXP-WindowsMedia-KB973540-x86-ENU.exe" /quiet /norestart /overwriteoem
"autopatcher:\modules\Critical\__WMP_critical\KB954155_xp_x86_enu.apm_files\WindowsXP-WindowsMedia-KB954155-x86-ENU.exe" /quiet /norestart /overwriteoem
"autopatcher:\modules\Critical\__WMP_critical\WindowsXP-WindowsMedia-KB975558-x86-ENU.apm_files\WindowsXP-WindowsMedia-KB975558-x86-ENU.exe" /quiet /norestart /overwriteoem
so, it fixes 3 issues, but not 2: kb978695 and kb975562. with those, the problem goes deeper: there's at least an partial superseed with this one (at least, there's an reason for the removal set for those 2 long ago). the problem: with wmp11, those aren't fully replaced. kb975562 is about Quartz.dll. the version that is in place after wmp11 is 6.5.2600.5908, but kb975562 deploy 6.5.2600.5933. as WU looks for that version, wu will offer this one to be installed if the user have wmp11. with kb978695, it's the same. kb978695 deploys Wmvcore.dll. with wmp11, the system has 11.0.5721.5262, but kb978695 deploys 11.0.5721.5275 and wu looks for that. as those aren't in the script anymore and will happen the same thing than KB973540, there's only one fix: bring this ones back and set wmp11 module to deploy those as well
Posted 24 June 2011 - 09:20 PM
if any of those files are already in place, then this one will show as already installed. as for KB975562, this one will look for this:
also, those 2 will be deployed with wmp11, to avoid issues like wmp11 deploying old files and those still looking as already in place
still, there's a few updates to check
Edited by Cristiano, 24 June 2011 - 09:21 PM.
Posted 24 June 2011 - 09:54 PM
Edited by ViroMan, 24 June 2011 - 09:54 PM.
Posted 24 June 2011 - 10:51 PM
Posted 25 June 2011 - 01:25 PM
kb2524375 and kb2492386-> this ones was missing. i don't remember right now with one is an critical update, but both require windows validation in order to be downloaded. so, both was added as non critical
KB2378111 is about Wmp.dll. the problem: this one updates that file to wmp9, 10 and 11. as wmp9 is the one that comes with windows, if the user select this one to be installed in a first round and then select wmp11 to be installed, wmp11 will deploy an file without that fix. i don't know if i did the best possible thing, but i've changed the detection for this one to be this:
with that, the script will detect the fixed versions. the problem: to have multiple file detections, one registry detection must be set and that key doesn't change when wmp11 is deployed and could make the user think that is safe, but isn't. worst at all: waste of bandwith downloading that update from wu with the update already downloaded. so, to fix the issue, this one will be silently deployed with wmp11
also, KB975562 isn't really required after wmp11 (but wu asks for that due some reason. so, this one stays in the script). so, the wmp11 will deploy those:
with that, the xp enu script shall now fully match wu
Edited by Cristiano, 25 June 2011 - 01:28 PM.
Posted 26 June 2011 - 12:22 PM
the test is pretty simple: after replace the original files, run autopatcher and look if those updates show as installed (those work even with wmp9, 10 and 11, so doesn't matter if you have wmp11 or not). if not, try to deploy those to see if it solves the issue if you are unsure if those updates are already in place
sorry, but i can't test it today by myself
Edited by Cristiano, 26 June 2011 - 12:24 PM.
Posted 08 July 2011 - 01:27 PM
Posted 11 July 2011 - 10:02 PM
about the wmp updates, i didn't found an solution for the following problem:
- the updates aim 3 or 4 versions of wmp, basically from 9 to 11;
- to every single wmp, the file detection changes and the registry detection remains static;
- if the user deploys the wmp updates and later wmp11, the modules will show as already in place, but wmp11 replaced the fixed files. due that, the vulnerabilities are back in place;
- it's impossible set multiple detections for the same file. due that, only a few options remain: detect the wmp11 updates only, make wmp11 deploy those updates again if selected to install (will not help those that already have wmp11 deployed) or made one module for every single wmp
Posted 12 July 2011 - 06:13 PM
KB2555917 -> KB2506223
KB2507938 -> KB2476687,KB2121546
and, of course, mrt
just 2 updates, so it's an very easy thing to fix. but please, give your opinions about the issue described in the last post
Posted 14 July 2011 - 11:41 AM
# 07-13: ~mrt 3.21; +KB2555917; -KB2506223; +KB2507938; -KB2476687; -KB2121546; -KB955759 (replaced by KB2492386); preactions older than 2011 removed
i've forgot to mention in this log that yours may notice 15 modules under modules\Critical\__WMP_critical. as no one give the slight hint about how to solve the detection issue described above, instead have 5 modules, i've extracted the content of each update with that issue and did one module for each wmp version. that shall detect the proper version for each wmp and those modules will show only if the wmp that they target is present. sorry, but it's really impossible do an single module to look for the same file with only an version/md5 change for 3 wmp versions. those detections was made with the content of those updates, meaning that if yours have an non-public update in your systems, the detection set may not work. if is the case, please state that
Posted 14 July 2011 - 05:49 PM
BTW, does the dotNET addon replace the dotNET files in \modules\Components\__dotnet or is it only for V4?
Edited by click-click, 14 July 2011 - 06:14 PM.
Posted 14 July 2011 - 09:44 PM
probably an upload issue. i will check that
Posted 14 July 2011 - 10:41 PM
Nevermind, I was confused. I downloaded the NET Add-on and everything is clean. Good job.
Edited by click-click, 14 July 2011 - 11:02 PM.
Posted 14 July 2011 - 11:56 PM
2 user(s) are reading this topic
0 members, 2 guests, 0 anonymous users