First on a different system you should remove all existing partitions and create new ones (optional), then set the partition as active, give it a boot loader, then give it the installation files.

First execute diskpart.exe from inside of a console. You'll need to determine which drive is the hard drive you intend to do this to. Type in list disk. From now on, the drive number will be referred to as n.

select disk n
clean
create partition primary
select partition 1
active
format fs=NTFS quick
assign
exit

clean will remove all existing partitions, then the partition is made and selected, active will mark is at an active partition which signals a bootloader to use this partition, the partition is then formatted, and mounted. Determine the drive letter assigned to the partition, this will be referred to as m.

Using the bootsect.exe executable found in the \boot\ directory of your Vista or Windows 7 DVD, install Windows Boot Manager (BOOTMGR) onto the drive using bootsect.exe /nt60 m: . I can confirm that using a 32 bit executable to make a 64 bit installer does work, and vice versa.

That's it! You're all done! Boot from the drive and the installer will run.

Don't feel like doing this yourself? No need!

When running PowerCalcPowertoySetup.exe, it complained that I'm not on Windows XP. Fair enough, but is that really important?

The exe installer dumped the MSI file at C:\Windows\Downloaded Installations\Calculator Powertoy for Windows XP.msi which I ran MsiDiff on to dump the MSI script. This gave me Calculator Powertoy for Windows XP.msi.MmDumpTxt which I searched for the above error in.

<$Row
	Condition="VersionNT = 501"
	Description="The powertoys require Windows XP or a service pack. They will not function on a version of Windows earlier or later than Windows XP."
>

Perfect. 501 is the Windows XP kernel version. Lets change that to the Vista kernal version in the MSI...

Sweet! It worked!

Running PowerCalc.exe causes it to exit before ever giving us a GUI. Lets do a trace in OllyDbg and see what we can figure out.

01018405	Main	JE SHORT PowerCal.0101840C
0101840C	Main	TEST BYTE PTR SS:[EBP-30],1
01018410	Main	JE SHORT PowerCal.01018423
01018412	Main	MOVZX ECX,WORD PTR SS:[EBP-2C]	ECX=0000000A
01018416	Main	JMP SHORT PowerCal.01018426
01018426	Main	PUSH ECX	Arg4 = 0000000A
01018427	Main	PUSH EAX	Arg3 = 001E1F33
01018428	Main	PUSH EBX	Arg2 = 00000000
01018429	Main	PUSH PowerCal.01000000	Arg1 = 01000000
0101842E	Main	CALL PowerCal.01001FD3	EAX=00000000, ECX=D73F2C3E, EDX=7F68081A
01018433	Main	MOV ESI,EAX
01018435	Main	MOV DWORD PTR SS:[EBP-7C],ESI
01018438	Main	CMP DWORD PTR SS:[EBP-60],EBX
0101843B	Main	JNZ SHORT PowerCal.01018444
0101843D	Main	PUSH ESI	status = 0
0101843E	Main	CALL DWORD PTR DS:[<&msvcrt.exit>]	ECX=0006FE28, EDX=00000000, EBP=0006FE84, ESI=00000001, EDI=00831BF0
    Process terminated, exit code 0

The bottom of the trace-over isn't telling us much. Lets check out some of these offsets in IDA Pro and see what we can come up with.

All the stuff around 0101843B seems to exit the program, and none of these other offsets get us anywhere... lets run a trace-into and see what we get.

Aside from a 75mb text file, we get: (search from the bottom up for our programs address space! There's a lot of external code in there!).

010180E3	Main	RETN
01001FD1	Main	LEAVE	EBP=0006FEE4
01001FD2	Main	RETN
01001FDF	Main	TEST EAX,EAX
01001FE1	Main	JE PowerCal.010020A0
010020A0	Main	XOR EAX,EAX
010020A2	Main	POP ESI
010020A3	Main	LEAVE	EBP=0006FF88
010020A4	Main	RETN 10
01018433	Main	MOV ESI,EAX
01018435	Main	MOV DWORD PTR SS:[EBP-7C],ESI
01018438	Main	CMP DWORD PTR SS:[EBP-60],EBX
0101843B	Main	JNZ SHORT PowerCal.01018444
0101843D	Main	PUSH ESI	status = 0
0101843E	Main	CALL DWORD PTR DS:[<&msvcrt.exit>]
exit	Main	MOV EDI,EDI

Now we're talking! It looks like a function returns and then the program exits. Lets check out the call to that function.

One path goes to the exit, the other... doesn't! Lets check out sub_1001F60 to see what it does...


It's our evil Windows Version Checking function!

In OllyDbg lets goto the jz loc_10020A0 after the function call, right click, and goto "nop" and press run. This causes the program to always follow the non-exiting code path.

Success!

Lets hex edit that into the executable so it's like this all the time.

We can now use our calculator!

Oh, that makes sense. So lets uninstall the old version.

Can't install the new, can't uninstall the old. Time for some hackery!

First lets find out the name of the culprit installer with Process Explorer's find tool, then in Process Monitor lets setup a filter to this executable.

Re-running the installer lets us see what it's accessing. Using that we can find out what makes it think it's installed so we can trick it into thinking it's doing a fresh install. Once the error screen comes up, unattach the event monitor in Process Monitor (control+e).

This looks interesting. It's the registry key used by Window's Add/Remove Programs.

Lets rename it to prevent the installer from seeing it then re-run the installer. Hmm... Semi-success. The installer now gives us the same error, but in a different place, so lets re-Process Monitor the installer.

Well! This looks very interesting! Lets rename this one as well...

Hey! It's installing!

Finally, time to get back to work.

Crap!

A DLL did not get replaced during the installation and a version mis-match is causing problems (why put the version number in the filename and not update it?). After a harddrive-wide search, I found sigc-2.0.dll in C:\Program Files\VMware\VMware Workstation. Good news is the installer has all of the installation files out in the open, so no need to dump cabs or hack the msi. I replaced copy in the Program Files directory with the one from the installer's directory and...

Success!

The local machine is a Windows Vista workstation and the remote is a webserver running LAMP.

The security of the locally backup database file is only as secure as the machine it-self. If you're not sure what this means, do not backup sensitive data using this method.

mysqldump is a program which can dump the contents of a MySQL database. It should be used with a MySQL user which has read access to all of the databases on your server that you wish to backup.

mysqldump will be executed by PHP on the remote server and the output will be passed back over standard http.

Update the variables in the above script and save as index.php. Upload this file to it's own directory on your server, for example /www/sqlbackup/.

/www/sqlbackup/ should be configured as a password protected directory to prevent access by anyone to it.

Download wget into your %windir. This is a command line utility that can be used to download remote files and pages from http and ftp servers.

Optionally, install WinRAR to add compression.

wget --http-user=... --http-password=... --output-document=C:\Users\Joe\Documents\Scripts\sqlbackup\backup.txt http://www.yourserver.com/sqlbackup/
"C:\program files\winrar\rar.exe" u -dw -y -p... backup.rar backup.txt

The first line uses wget to download the output from our remote script to backup.txt. The user, password, remote, and local locations all need to be changed to suite your configuration. This should be saved into script.bat in it's own directory on your local workstation, example C:\Users\Joe\Documents\Scripts\sqlbackup\.

The second line compresses the downloaded file into backup.rar and sets the password of the rar to whatever follows the -p argument. Note that the rar password ads very minimal security due to the script, which contains the password, being in the same directory. This line is optional and can be omitted.

Run backup.bat to make sure that everything is working fine.

In a command window, enter at 13:00 /EVERY:M,T,W,Th,F,S,Su C:\Users\Joe\Documents\Scripts\sqlbackup\backup.bat

This will cause the above local script to execute everyday at 1:00PM everyday of the week.

There's nothing else to it! Keep in mind, once again, that this will make any of the dumped MySQL contents as insecure as your computer is!