Jump to content

VBScript not working on WinPE 3.0 x64


Tripredacus

Recommended Posts

This is in referral to this project:

http://www.msfn.org/board/imagex-hta-win-p...64-t138048.html

I have determined that VBScript processing is not happening at all in Win PE 3.0 x64. The HTA itself is working fine except you can't do anything with it. None of the functions that require VBScript will work properly. Is there perhaps a file missing that I need? For example, running this function (its launched by clicking an image link) does nothing at all:

Sub Unmount
Dim Answer
Answer = window.confirm("Click OK to install Vista apps")
If Answer Then
objshell.run("vista_pe_selector.exe"),0
Else

End If
End Sub

And it should create a msgBox to show an OK box. When you click OK, it runs the EXE shown there or else Cancel and it does nothing. I have recompiled the programs for x64, so its not that it can't launch the programs. Now, the following code does something different. For some reason (if I am reading the code properly), the var for myInput = 7 because the "Aborted" box shows up right away.

Sub doTask(doMe)
Dim myInput
Dim myError
If doMe = "1" Then
MsgBox "You must select image to apply first."
Else
If Instr(1, doMe, "1", 1) > 0 Then
myInput = 1
If myInput = 7 Then
MsgBox "Aborted"
Else
Call DiskPart()
If objFso.FileExists(Sysfolder & "\1.txt") Then
objShell.Run doMe,1,True
Call confirmation2()
On Error Resume Next
Objfso.DeleteFile(Sysfolder & "1.txt")
On Error Goto 0
Else
End If
End if
Else
myError = objShell.Run(doMe, 1, True)
End if
End if
End Sub

However, the link object with the following code to open the Command Prompt DOES work properly, and it still uses the doTask sub.

onclick=doTask('%comspec%')

So what could be the reason that VBScript is not functioning in this PE?

Edit: I forgot to add that I have tried the following as well. Each of them succeed but offer no change.

x:\windows\system32\regsvr32 vbscript.dll

x:\windows\syswow64\regsvr32 vbscript.dll

Link to comment
Share on other sites


Use DISM to add the winpe-scripting package to your PE image.

e.g.

Dism /image:<path to your mounted image> /Add-Package /PackagePath:<path to your petools packages folder \winpe-scripting.cab>

Then add the language package for it as well.

e.g.

Dism /image:<path to your mounted image> /Add-Package /PackagePath:<path to your petools packages\en-us folder \winpe-scripting_en-us.cab>

Link to comment
Share on other sites

try installing the language pack thats in the winpe_fps\en-us folder for the scripting package to see if that lets it work...

i use winpe amd64 as a recovery source and letting you know it works fine. so defo something being missed.... also the exe application has to be 100% 64-bit as they WOW function doesnt work in winpe.

just remember to copy mshta.exe from the system32 folder to the syswow folder as they still haven't corrected this bug. (but you seem to already have your hta running so you prolly dont have to do this)

hope this helps

Link to comment
Share on other sites

If objFso.FileExists(Sysfolder & "\1.txt") Then

i think you'll find that it will always return a negative result until you remove the "\"

corrected code: If objFso.FileExists(Sysfolder & "1.txt") Then

also as i said before: sysfolder = syswow64 in 64-bit so your text file must reside there

has this solved it? or am i being an id***?

Edited by Atheros
Link to comment
Share on other sites

Sorry Atheros. Currently I am not going at it on my own (or with help from people here) yet as I have an SR open with Microsoft about it.

But ok, so the sysfolder, is defined here:

Set SysFolder = Objfso.GetSpecialFolder(1)

But yes, looking at this code, you may be on the right track! Because obviously the code after this, which sets the dimensions of the HTA, does in fact work... So is this "GetSpecialFolder" a global variable? It isn't defined anywhere in the HTA. So I am understanding that when it looks at SysFolder in x64, the PE returns Syswow64, instead of System32. How can it be (easily) changed to return System32?

Update:

Nope this is a dead end, going after SysFolder. I got this code written up real quick, to find out what variable is being returned:

Dim fso, tempfile, tfolder, tname, tfile
Set fso = CreateObject("Scripting.FileSystemObject")
Set tfolder = fso.GetSpecialFolder(1)
MsgBox(tfolder)

Saved as test.vbs, and executed as cscript test.vbs. The messagebox that comes up says:

X:\Windows\System32

So this object isn't referring to syswow64. There must still be something missing. I was hoping it would have been that simple!

Link to comment
Share on other sites

odd because when i was testing the code it was pointing to my syswow64 folder (vistax64). i ran your script and yest it does seem to return system32 folder.

also the \1.txt = root\1.txt thats why i said to remove the "\". so it calls systemfolder\1.txt.

check it out, this is the code i used and although the variable is calling system32 folder, it fails even though the file is in system32, but if you put the file in syswow64 it returns with the working value.

Sub Window_Onload


Dim fso, tempfile, tfolder, tname, tfile
Set fso = CreateObject("Scripting.FileSystemObject")
Set tfolder = fso.GetSpecialFolder(1)
MsgBox(tfolder)

Set objfso = CreateObject("Scripting.FileSystemObject")
If objFso.FileExists(Sysfolder & "1.txt") Then
msgbox "moo"
else
msgbox "baa"
end if


End Sub

Edited by Atheros
Link to comment
Share on other sites

OK I am starting to think we can make this easier. I don't think we have to worry about sysfolder. There is another sub that controls applying the images. See this snippet:

If Radio.Checked = True Then
myInput2 = window.confirm("Would you like to apply the selected image?")
If myInput2 = false Then
MsgBox "Aborted"
Exit Sub

So if I choose to apply an image, it needs to get a var back from window.confirm. Since we have already established that window.confirm isn't working, this value would be "false" thus generating the "aborted" message. So if there is a way to simply replace window.confirm, this may solve this problem.

Update: Another user confirmed that window.confirm does not work in the x86 version either. I have safely replaced that code, here is a new example:

Dim Answer, objShell, objFso
Set objShell = CreateObject("WScript.Shell")
Set objFso = CreateObject("Scripting.FileSystemObject")

Answer = MsgBox("Do you want to install XP Apps?",1,"XPapps")
If Answer Then
objshell.run("xp_pe_selector.exe"),0
Else

End If

So the new PE must have something that was changed from last version. Perhaps the Cscript program was changed? We may never know.

Link to comment
Share on other sites

yes i noticed it too. i could no long do answers unless i specified the true value

forgive me as this is prolly gonna be messy.

sub startbutton_OnClick

blnanswer "do you want to install XP apps"
if blnanswer = "true" then diskpart
if blnanswer = "false" then exit sub

'next function if true

msgbox "About to deploy image, a window will popup to confirm when the process is complete. this can take upto 30 mins"
set objapp = createobject(wscript.shell")
objapp.run "imagex /apply" & " %path%\%imagename%" & " %index%" & " %pathtodeploy%",0,true

blnanswer "image apply complete, would you like to reboot now?"
if blnanswer = "true" then shutdown
if blnanswer = "false" then exit sub

end sub

sub diskpart

set objapp = createobject("wscript.shell")
objapp.run "diskpart /s script.txt",0,true 'hides that **** command prompt window

end sub

sub shutdown

set objapp = createobject("wscript.shell")
objapp.run "wpeutil -reboot",0,true

end sub

problem is from there it will process that sub and continue down the original sub so i had to stop it by using the exit sub command if the value was false.

Link to comment
Share on other sites

Yes, I see you added the true/false in there. My example does not have it, so in some cases (such as using it to shutdown the pc) it executes the following code no matter what. I'd hope that other people would have seen that! :whistle:

I have not made the code change to fix that issue yet. Maybe tomorrow!

Anyways, since I did take this issue to Microsoft, and yet fixed it myself. Although Atheros led me on the track that the same code brought different results, and tabone confirmed that some code doesn't work anymore. I ended up changing my SR to a bug report, at least for window.confirm.

Thanks everyone for your help!

Ohh Atheros, my use of installing apps, XP or Vista, is an option that is called after applying an image. A lot less logic required for that. I haven't posted that code yet but maybe one of these days I will!

Link to comment
Share on other sites

ok so i couldn't find your issue using my winpe, but now i have made one from scratch, and window.confirm most definetly isn't working.

im gonna look into it as MS don't respond easily, as i need this function also.

you could use the winpe built on the windows disk as this works fine (install.wim 1 \windows\system32\recovery\winre.wim..... until we see whats really going wrong or find a fix.

[EDIT] OK GOT IT WORKING [/EDIT]

OPEN DEPLOYMENT TOOLS COMMAND PROMPT

COPYPE AMD64 C:\WINPE

IMAGEX /MOUNTRW WINPE.WIM 1 MOUNT

DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\WINPE-HTA.CAB"

DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\WINPE-MDAC.CAB.CAB"

DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\WINPE-SCRIPTING.CAB"

DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\WINPE-WDS-TOOLS.CAB"

DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\WINPE-WMI.CAB"

DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\EN-US\LP_EN-US.CAB"

DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\EN-US\WINPE-HTA_EN-US.CAB"

DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\EN-US\WINPE-MDAC_EN-US.CAB"

DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\EN-US\WINPE-SCRIPTING_EN-US.CAB"

DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\EN-US\WINPE-WDS-TOOLS_EN-US.CAB"

DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\EN-US\WINPE-WMI_EN-US.CAB"

XCOPY MOUNT\WINDOWS\SYSTEM32\MSHTA.EXE MOUNT\WINDOWS\SYSWOW64


IMAGEX /UNMOUNT MOUNT /COMMIT

Now that is everything exactly what i have done to the letter no deviations, nothing. and its working....

give it a go

Edited by Atheros
Link to comment
Share on other sites

Its no big secret Atheros. I already posted it above. This only fixes the window.confirm by replacing it with MsgBox. After my research, it seems that window.confirm is a Javascript leftover and isn't documented for VBScript at all. Here is a now fixed, and working example:

Sub Append
Dim Answer
Answer = MsgBox("Do you want to install XP Apps?",1,"XPapps")
If Answer = 1 Then
objshell.run("xp_pe_selector.exe"),0
Else
Exit Sub
End If
End Sub

So to be creative, replacing other parts, such as the peice that is called when you select a radio button for an image:

A snippet from the beginning of showRadioInfo()

myInput2 = MsgBox("Would you like to apply the selected image?",1,"showRadioInfo")
If myInput2 = false Then
MsgBox "Aborted"
Exit Sub
Else
Call DiskPart()

And later on

If RebootAfterImageApply = 0 Then
Answer2 = MsgBox("Image applied successfully!"& Chr(13) + Chr(13) & "Click OK to Shutdown?",1,"SUCCESS")
If Answer2 = 1 Then
objshell.run("wpeutil Shutdown"),0
Else
Exit Sub
End If

On my HTA, i did not replace all instances of window.confirm. For example, we do not make use of mounting any wims and capturing/appending images are not the task of the regular software deployment people. There was a time, back when we used Ghost, we let anyone save images. What ended up happening is having tons of images with ambiguous names. If I handle all image management myself, I can confirm that everything follows a naming convention and is easy to find and sorted properly. Instead of relying on people who might have been too lazy to name the images properly.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...