Run Windows 7 from an external USB HardDrive

Windows 7 - XP mode

2009-07-04T10:11:00.000-07:00

Windows Virtual PC Beta:
http://www.microsoft.com/downloads/details.aspx?familyid=65E1C5EB-DF9B-415F-B2D6-27F6EF5DCEB9&displaylang=en

Windows XP Mode Beta:
http://www.microsoft.com/downloads/details.aspx?familyid=0E8FA9B3-C236-4B77-BE26-173F032F5159&displaylang=en

Check Windows expiration date

2009-06-28T23:46:00.000-07:00

Start -> Run -> winver and hit enter :-)

Upgrade pre-RC (70xx) to RC (71xx)

2009-06-07T05:18:00.001-07:00

use the following trick to to upgrade successfully from pre-RC (build
70xx series) to RC (possibly 71xx series).

1.Download the Windows 7 ISO.
2.Burn the Windows 7 ISO image to a DVD, and then copy and whole image
to a storage location that you wish to run the upgrade from (can be
either any directory/folder on any partition/drive on the machine
running the pre-release build, or a bootable USB/FireWire flash
drive).
Alternatively, it’s possible to directly extract the content of the
ISO to a desired folder using file extraction tool such as WinRAR.

3.Browse to the sources directory.
4.Open the file cversion.ini in a text editor such as Notepad.
5.Modify the MinClient build number to a value lower than the
down-level build. For example, change 7100 to 7000.

6.Save the file in original place and original name.
7.Start the setup process of Windows 7 as per normal from the modified
copy of the installation files, and the version check will be
bypassed

Free Windows 7 RC Activation Product Keys

2009-06-02T13:31:00.000-07:00

Free Windows 7 RC Activation Product Keys
MM7DF-G8XWM-J2VRG-4M3C4-GR27X
KGMPT-GQ6XF-DM3VM-HW6PR-DX9G8
MVBCQ-B3VPW-CT369-VM9TB-YFGBP
KBHBX-GP9P3-KH4H4-HKJP4-9VYKQ
BCGX7-P3XWP-PPPCV-Q2H7C-FCGFR
RGQ3V-MCMTC-6HP8R-98CDK-VP3FM
Q3VMJ-TMJ3M-99RF9-CVPJ3-Q7VF3
6JQ32-Y9CGY-3Y986-HDQKT-BPFPG
P72QK-2Y3B8-YDHDV-29DQB-QKWWM
6F4BB-YCB3T-WK763-3P6YJ-BVH24
9JBBV-7Q7P7-CTDB7-KYBKG-X8HHC
C43GM-DWWV8-V6MGY-G834Y-Y8QH3
GPRG6-H3WBB-WJK6G-XX2C7-QGWQ9
MT39G-9HYXX-J3V3Q-RPXJB-RQ6D7
MVYTY-QP8R7-6G6WG-87MGT-CRH2P

The product keys can be used to activate both 32bit and 64bit Windows 7 RC

Fix and Restore Windows 7 Boot Screen That Changes to Vista Style

2009-02-19T04:39:00.000-08:00

Sometimes, the beautiful, elegant, high resolution animated and dynamic Windows 7 boot screen UI may be changed to or replaced with Windows Vista boot screen, normally when user adds a Windows 7 entry in boot menu or accidentally when user attempts to repair the startup menu items with Windows Vista DVD, specifically Startup Repair. Windows Vista boot screen is a boring black background with low resolution green running progress bar.The invalid and wrong boot screen for Windows 7 is due to missing locale entry in boot record, which failed to be set when editing or rebuilding the BCD. When locale is not found, Windows boot loader does not know which boot locale folder to look for the animated bootscreen. Thus, in order to fix the boot screen so that the boot screen can be reverted, restored or reseted back to original animated Windows 7 boot screen, just run one of the following commands in elevated command prompt with administrator rights:
bcdedit /set {current} locale en-US
or
bcdboot %WinDir% /l en-US
Change the en-US to the language version of the installed Windows 7, such as ja-JP, de-DE, es-ES, pt-BR, zh-CN, zh-TW, fr-FR, fi-FI and etc.
Restart the computer after running the command to see the new boot UI (user interface) be used again. To check if the locale setting has been entered properly, just run the bceedit command in command prompt that runs as administrator.
window.google_render_ad();

Remove Windows 7 watermark

2009-01-30T20:57:00.001-08:00

http://depositfiles.com/files/pcpnj38aq

Remove "Send Feedback" in Windows 7 beta

2009-01-26T00:16:00.001-08:00

Run Registry Editor (RegEdit), and navigate to the following registry key:

HKEY_CURRENT_USER\Control Panel\Desktop

Change FeedbackToolEnabled to 0 (zero)

logg off and log in.

Windows 7 Quick Launch

2009-01-11T17:08:00.000-08:00

is hidden!!!

Right click in the taskbar -> Toolbars -> New Toolbar...
Now search in
C:\Users\%username%\AppData\Roaming\Microsoft\Internet Explorer\
for the folder "Quick Launch"

Then un-pin everything from the superbar

Windows 7 free activation keys

2009-01-10T16:01:00.000-08:00

Windows 7 Beta 64-bit Product Key
7XRCQ-RPY28-YY9P8-R6HD8-84GH3
JYDV8-H8VXG-74RPT-6BJPB-X42V4
482XP-6J9WR-4JXT3-VBPP6-FQF4M
JYDV8-H8VXG-74RPT-6BJPB-X42V4
D9RHV-JG8XC-C77H2-3YF6D-RYRJ9

Windows 7 Beta 32-bit Product Key
6JKV2-QPB8H-RQ893-FW7TM-PBJ73
TQ32R-WFBDM-GFHD2-QGVMH-3P9GC
GG4MQ-MGK72-HVXFW-KHCRF-KW6KY
4HJRK-X6Q28-HWRFY-WDYHJ-K8HDH
QXV7B-K78W2-QGPR6-9FWH9-KGMM7

Inside Windows Product Activation

2008-12-27T13:15:00.001-08:00

Inside Windows Product Activation
A Fully Licensed Paper
July 2001
Fully Licensed GmbH, Rudower Chaussee 29, 12489 Berlin, Germany
http://www.licenturion.com
>> INTRODUCTION
The current public discussion of Windows Product Activation (WPA) is
characterized by uncertainty and speculation. In this paper we supply
the technical details of WPA - as implemented in Windows XP - that
Microsoft should have published long ago.
While we strongly believe that every software vendor has the right to
enforce the licensing terms governing the use of a piece of licensed
software by technical means, we also do believe that each individual
has the right to detailed knowledge about the full implications of the
employed means and possible limitations imposed by it on software
usage.
In this paper we answer what we think are currently the two most
important open questions related to Windows Product Activation.
* Exactly what information is transmitted during activation?
* How do hardware modifications affect an already activated
installation of Windows XP?
Our answers to these questions are based on Windows XP Release
Candidate 1 (build 2505). Later builds as well as the final version of
Windows XP might differ from build 2505, e.g. in the employed
cryptographic keys or the layout of some of the data
structures.
However, beyond such minor modifications we expect Microsoft to cling
to the general architecture of their activation mechanism. Thus, we
are convinced that the answers provided by this paper will still be
useful when the final version of Windows XP ships.
This paper supplies in-depth technical information about the inner
workings of WPA. Still, the discussion is a little vague at some
points in order not to facilitate the task of an attacker attempting
to circumvent the license enforcement supplied by the activation
mechanism.
XPDec, a command line utility suitable for verifying the presented
information, can be obtained from http://www.licenturion.com/xp/. It
implements the algorithms presented in this paper. Reading its source
code, which is available from the same location, is highly
recommended.
We have removed an important cryptographic key from the XPDec source
code. Recompiling the source code will thus fail to produce a working
executable. The XPDec executable on our website, however, contains
this key and is fully functional.
So, download the source code to learn about the inner workings of WPA,
but obtain the executable to experiment with your installation of
Windows XP.
We expect the reader to be familiar with the general procedure of
Windows Product Activation.
>> INSIDE THE INSTALLATION ID
We focused our research on product activation via telephone. We did
so, because we expected this variant of activation to be the most
straight-forward to analyze.
The first step in activating Windows XP via telephone is supplying the
call-center agent with the Installation ID displayed by msoobe.exe,
the application that guides a user through the activation process. The
Installation ID is a number consisting of 50 decimal digits that are
divided into groups of six digits each, as in
002666-077894-484890-114573-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XX
In this authentic Installation ID we have substituted digits that we
prefer not to disclose by 'X' characters.
If msoobe.exe is invoked more than once, it provides a different
Installation ID each time.
In return, the call-center agent provides a Confirmation ID matching
the given Installation ID. Entering the Confirmation ID completes the
activation process.
Since the Installation ID is the only piece of information revealed
during activation, the above question concerning the information
transmitted during the activation process is equivalent to the
question
'How is the Installation ID generated?'
To find an answer to this question, we trace back each digit of the
Installation ID to its origins.
>>> Check digits
The rightmost digit in each of the groups is a check digit to guard
against simple errors such as the call center agent's mistyping of one
of the digits read to him or her. The value of the check digit is
calculated by adding the other five digits in the group, adding the
digits at even positions a second time, and dividing the sum by
seven. The remainder of the division is the value of the check
digit. In the above example the check digit for the first group (6) is
calculated as follows.
1 2 3 4 5 <- position
---+---+---+---+---
0 0 2 6 6 <- digits
0 + 0 + 2 + 6 + 6 = 14 (step 1: add all digits)
0 + 6 + 14 = 20 (step 2: add even digits again)
step 3: division
20 / 7 = 2, remainder is 20 - (2 * 7) = 6
=> check digit is 6
Adding the even digits twice is probably intended to guard against the
relatively frequent error of accidentally swapping two digits while
typing, as in 00626 vs. 00266, which yield different check digits.
>>> Decoding
Removing the check digits results in a 41-digit decimal number. A
decimal number of this length roughly corresponds to a 136-bit binary
number. In fact, the 41-digit number is just the decimal encoding of
such a 136-bit multi-precision integer, which is stored in little
endian byte order as a byte array. Hence, the above Installation ID
can also be represented as a sequence of 17 bytes as in
0xXX 0xXX 0xXX 0xXX 0xXX 0xXX 0xXX 0xXX
0x94 0xAA 0x46 0xD6 0x0F 0xBD 0x2C 0xC8
0x00
In this representation of the above Installation ID 'X' characters
again substitute the digits that we prefer not to disclose. The '0x'
prefix denotes hex notation throughout this paper.
>>> Decryption
When decoding arbitrary Installation IDs it can be noticed that the
most significant byte always seems to be 0x00 or 0x01, whereas the
other bytes look random. The reason for this is that the lower 16
bytes of the Installation ID are encrypted, whereas the most
significant byte is kept in plaintext.
The cryptographic algorithm employed to encrypt the Installation ID is
a proprietary four-round Feistel cipher. Since the block of input
bytes passed to a Feistel cipher is divided into two blocks of equal
size, this class of ciphers is typically applied to input blocks
consisting of an even number of bytes - in this case the lower 16 of
the 17 input bytes. The round function of the cipher is the SHA-1
message digest algorithm keyed with a four-byte sequence.
Let + denote the concatenation of two byte sequences, ^ the XOR
operation, L and R the left and right eight-byte input half for one
round, L' and R' the output halves of said round, and First-8() a
function that returns the first eight bytes of an SHA-1 message
digest. Then one round of decryption looks as follows.
L' = R ^ First-8(SHA-1(L + Key))
R' = L
The result of the decryption is 16 bytes of plaintext, which are -
together with the 17th unencrypted byte - from now on interpreted as
four double words in little endian byte order followed by a single
byte as in
name size offset
-----+-------------+-------
H1 double word 0
H2 double word 4
P1 double word 8
P2 double word 12
P3 byte 16
H1 and H2 specify the hardware configuration that the Installation ID
is linked to. P1 and P2 as well as the remaining byte P3 contain the
Product ID associated with the Installation ID.
>>> Product ID
The Product ID consists of five groups of decimal digits, as in
AAAAA-BBB-CCCCCCC-DDEEE
If you search your registry for a value named 'ProductID', you will
discover the ID that applies to your installation. The 'About' window
of Internet Explorer should also yield your Product ID.
>>>> Decoding
The mapping between the Product ID in decimal representation and its
binary encoding in the double words P1 and P2 and the byte P3 is
summarized in the following table.
digits length encoding
--------+---------+---------------------------------------
AAAAA 17 bits bit 0 to bit 16 of P1
BBB 10 bits bit 17 to bit 26 of P1
CCCCCCC 28 bits bit 27 to bit 31 of P1 (lower 5 bits)
bit 0 to bit 22 of P2 (upper 23 bits)
DDEEE 17 bits bit 23 to bit 31 of P2 (lower 9 bits)
bit 0 to bit 7 of P3 (upper 8 bits)
The meaning of each of the five groups of digits is documented in the
next table.
digits meaning
--------+-------------------------------------------------
AAAAA apparently always 55034 (in Windows XP RC1)
BBB most significant three digits of Raw Product Key
(see below)
CCCCCCC least significant six digits of Raw Product Key
plus check digit (see below)
DD index of the public key used to verify the
Product Key (see below)
EEE random value
As can be seen, the (Raw) Product Key plays an important role in
generating the Product ID.
>>>> Product Key
The Raw Product Key is buried inside the Product Key that is printed
on the sticker distributed with each Windows XP CD. It consists of
five alphanumeric strings separated by '-' characters, where each
string is composed of five characters, as in
FFFFF-GGGGG-HHHHH-JJJJJ-KKKKK
Each character is one of the following 24 letters and digits:
B C D F G H J K M P Q R T V W X Y 2 3 4 6 7 8 9
Very similar to the decimal encoding of the Installation ID the 25
characters of the Product Key form a base-24 encoding of the binary
representation of the Product Key. Decoding the Product Key yields a
multi-precision integer of roughly 115 bits, which is stored - again
in little endian byte order - in an array of 15 bytes. Decoding the
above Product Key results in the following byte sequence.
0x6F 0xFA 0x95 0x45 0xFC 0x75 0xB5 0x52
0xBB 0xEF 0xB1 0x17 0xDA 0xCD 0x00
Of these 15 bytes the least significant four bytes contain the Raw
Product Key in little endian byte order. The least significant bit is
removed by shifting this 32-bit value (0x4595FA6F - remember the
little endian byte order) to the left by one bit position, resulting
in a Raw Product Key of 0x22CAFD37, or
583728439
in decimal notation.
The eleven remaining bytes form a digital signature, allowing
verification of the authenticity of the Product Key by means of a
hard-coded public key.
>>>> Product Key -> Product ID
The three most significant digits, i.e. 583, of the Raw Product Key's
nine-digit decimal representation directly map to the BBB component of
the Product ID described above.
To obtain the CCCCCCC component, a check digit is appended to the
remaining six digits 728439. The check digit is chosen such that the
sum of all digits - including the check digit - is divisible by
seven. In the given case, the sum of the six digits is
7 + 2 + 8 + 4 + 3 + 9 = 33
which results in a check digit of 2, since
7 + 2 + 8 + 4 + 3 + 9 + 2 = 33 + 2 = 35
which is divisible by seven. The CCCCCCC component of the Product ID
is therefore 7284392.
For verifying a Product Key, more than one public key is available. If
verification with the first public key fails, the second is tried,
etc. The DD component of the Product ID specifies which of the public
keys in this sequence was successfully used to verify the Product Key.
This mechanism might be intended to support several different parties
generating valid Product Keys with different individual private keys.
However, the different private keys might also represent different
versions of a product. A Product Key for the 'professional' release
could then be signed with a different key than a Product Key for the
'server' release. The DD component would then represent the product
version.
Finally, a valid Product ID derived from our example Product Key might
be
55034-583-7284392-00123
which indicates that the first public key (DD = index = 0) matched and
123 was chosen as the random number EEE.
The randomly selected EEE component is the reason for msoobe.exe
presenting a different Installation ID at each invocation. Because of
the applied encryption this small change results in a completely
different Installation ID.
So, the Product ID transmitted during activation will most probably
differ in the last three digits from your Product ID as displayed by
Internet Explorer or as stored in the registry.
>>> Hardware Information
As discussed above, the hardware configuration linked to the
Installation ID is represented by the two double words H1 and H2.
>>>> Bit-fields
For this purpose, the double words are divided into twelve
bit-fields. The relationship between the computer hardware and the
bit-fields is given in the following table.
double word offset length bit-field value based on
------------+--------+--------+----------------------------
H1 0 10 volume serial number string
of system volume
H1 10 10 network adapter MAC address
string
H1 20 7 CD-ROM drive hardware
identification string
H1 27 5 graphics adapter hardware
identification string
H2 0 3 unused, set to 001
H2 3 6 CPU serial number string
H2 9 7 harddrive hardware
identification string
H2 16 5 SCSI host adapter hardware
identification string
H2 21 4 IDE controller hardware
identification string
H2 25 3 processor model string
H2 28 3 RAM size
H2 31 1 1 = dockable
0 = not dockable
Bit 31 of H2 specifies, whether the bit-fields represent a notebook
computer that supports a docking station. If docking is possible, the
activation mechanism will be more tolerant with respect to future
hardware modifications. Here, the idea is that plugging a notebook
into its docking station possibly results in changes to its hardware
configuration, e.g. a SCSI host adapter built into the docking station
may become available.
Bits 2 through 0 of H2 are unused and always set to 001.
If the hardware component corresponding to one of the remaining ten
bit-fields is present, the respective bit-field contains a non-zero
value describing the component. A value of zero marks the hardware
component as not present.
All hardware components are identified by a hardware identification
string obtained from the registry. Hashing this string provides the
value for the corresponding bit-field.
>>>> Hashing
The hash result is obtained by feeding the hardware identification
string into the MD5 message digest algorithm and picking the number of
bits required for a bit-field from predetermined locations in the
resulting message digest. Different predetermined locations are used
for different bit-fields. In addition, a hash result of zero is
avoided by calculating
Hash = (Hash % BitFieldMax) + 1
where BitFieldMax is the maximal value that may be stored in the
bit-field in question, e.g. 1023 for a 10-bit bit-field, and 'x % y'
denotes the remainder of the division of x by y. This results in
values between 1 and BitFieldMax. The obtained value is then stored in
the respective bit-field.
>>>> RAM bit-field
The bit-field related to the amount of RAM available to the operating
system is calculated differently. The seven valid values specify the
approximate amount of available RAM as documented in the following
table.
value amount of RAM available
------+---------------------------
0 (bit-field unused)
1 below 32 MB
2 between 32 MB and 63 MB
3 between 64 MB and 127 MB
4 between 128 MB and 255 MB
5 between 256 MB and 511 MB
6 between 512 MB and 1023 MB
7 above 1023 MB
It is important to note that the amount of RAM is retrieved by calling
the GlobalMemoryStatus() function, which reports a few hundred
kilobytes less than the amount of RAM physically installed. So, 128 MB
of RAM would typically be classified as "between 64 MB and 127 MB".
>>>> Real-world example
Let us have a look at a real-world example. On one of our test systems
the hardware information consists of the following eight bytes.
0xC5 0x95 0x12 0xAC 0x01 0x6E 0x2C 0x32
Converting the bytes into H1 and H2, we obtain
H1 = 0xAC1295C5 and H2 = 0x322C6E01
Splitting H1 and H2 yields the next table in which we give the value
of each of the bit-fields and the information from which each value is
derived.
dw &
offset value derived from
-------+-------+-----------------------------------------------
H1 0 0x1C5 '1234-ABCD'
H1 10 0x0A5 '00C0DF089E44'
H1 20 0x37 'SCSI\CDROMPLEXTOR_CD-ROM_PX-32TS__1.01'
H1 27 0x15 'PCI\VEN_102B&DEV_0519&SUBSYS_00000000&REV_01'
H2 0 0x1 (unused, always 0x1)
H2 3 0x00 (CPU serial number not present)
H2 9 0x37 'SCSI\DISKIBM_____DCAS-34330______S65A'
H2 16 0x0C 'PCI\VEN_9004&DEV_7178&SUBSYS_00000000&REV_03'
H2 21 0x1 'PCI\VEN_8086&DEV_7111&SUBSYS_00000000&REV_01'
H2 25 0x1 'GenuineIntel Family 6 Model 3'
H2 28 0x3 (system has 128 MB of RAM)
H2 31 0x0 (system is not dockable)
>>> Using XPDec
XPDec is a utility to be run from the command prompt. It may be
invoked with one of four command line options to carry out one of four
tasks.
>>>> XPDec -i
This option enables you to access the information hidden in an
Installation ID. It decodes the Installation ID, decrypts it, and
displays the values of the hardware bit-fields as well as the Product
ID of your product. Keep in mind that the last three digits of the
Product ID contained in the Installation ID are randomly selected and
differ from the Product ID displayed by Internet Explorer.
The only argument needed for the '-i' option is the Installation ID,
as in
XPDec -i 002666-077894-484890-114573-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XX
>>>> XPDec -p
To help you trace the origin of your Product ID, this option decodes a
Product Key and displays the Raw Product Key as it would be used in a
Product ID.
The only argument needed for the '-p' option is the Product Key, as in
XPDec -p FFFFF-GGGGG-HHHHH-JJJJJ-KKKKK
Note that this option does not verify the digital signature of the
Product Key.
>>>> XPDec -v
This option calculates the hash of a given volume serial number. It
was implemented to illustrate our description of string hashing. First
use '-i' to display the hardware bit-fields. Then use this option to
verify our claims concerning the volume serial number hash.
The only argument needed for the '-v' option is the volume serial
number of your system volume, as in
XPDec -v 1234-ABCD
(The volume serial number is part of the 'dir' command's output.)
>>>> XPDec -m
This option calculates the network adapter bit-field value
corresponding to the given MAC address. Similar to '-v' this option
was implemented as a proof of concept.
The only argument needed for the '-m' option is the MAC address of
your network adapter, as in
XPDec -m 00-C0-DF-08-9E-44
(Use the 'route print' command to obtain the MAC address of your
network adapter.)
>> HARDWARE MODIFICATIONS
When looking at the effects of hardware modifications on an already
activated installation of Windows XP, the file 'wpa.dbl' in the
'system32' directory plays a central role. It is a simple
RC4-encrypted database that stores, among other things like expiration
information and the Confirmation ID of an activated installation,
a) the bit-field values representing the current hardware
configuration,
and
b) the bit-field values representing the hardware configuration
at the time of product activation.
While a) is automatically updated each time the hardware configuration
is modified in order to reflect the changes, b) remains fixed. Hence,
b) can be thought of as a snapshot of the hardware configuration at
the time of product activation.
This snapshot does not exist in the database before product activation
and if we compare the size of 'wpa.dbl' before and after activation,
we will notice an increased file size. This is because the snapshot is
added to the database.
When judging whether re-activation is necessary, the bit-field values
of a) are compared to the bit-field values of b), i.e. the current
hardware configuration is compared to the hardware configuration at
the time of activation.
>>> Non-dockable computer
Typically all bit-fields with the exception of the unused field and
the 'dockable' field are compared. If more than three of these ten
bit-fields have changed in a) since product activation, re-activation
is required.
This means, for example, that in our above real-world example, we
could replace the harddrive and the CD-ROM drive and substantially
upgrade our RAM without having to re-activate our Windows XP
installation.
However, if we completely re-installed Windows XP, the information in
b) would be lost and we would have to re-activate our installation,
even if we had not changed our hardware.
>>> Dockable computer
If bit 31 of H2 indicates that our computer supports a docking
station, however, only seven of the ten bit-fields mentioned above are
compared. The bit-fields corresponding to the SCSI host adapter, the
IDE controller, and the graphics board are omitted. But again, of
these remaining seven bit-fields, only up to three may change without
requiring re-activation.
>> CONCLUSIONS
In this paper we have given a technical overview of Windows Product
Activation as implemented in Windows XP. We have shown what
information the data transmitted during product activation is derived
from and how hardware upgrades affect an already activated
installation.
Looking at the technical details of WPA, we do not think that it is as
problematic as many people have expected. We think so, because WPA is
tolerant with respect to hardware modifications. In addition, it is
likely that more than one hardware component map to a certain value
for a given bit-field. From the above real-world example we know that
the PX-32TS maps to the value 0x37 = 55. But there are probably many
other CD-ROM drives that map to the same value. Hence, it is
impossible to tell from the bit-field value whether it is a PX-32TS
that we are using or one of the other drives that map to the same
value.
In contrast to many critics of Windows Product Activation, we think
that WPA does not prevent typical hardware modifications and,
moreover, respects the user's right to privacy.
>> ABOUT THE AUTHORS
Fully Licensed GmbH is a start-up company focusing on novel approaches
to online software licensing and distribution. Have a look at their
website at
http://www.licenturion.com
for more information.
Their research branch every now and then analyzes licensing solutions
implemented by other companies.
>> COPYRIGHT
Copyright (C) 2001 Fully Licensed GmbH (www.licenturion.com)
All rights reserved.
You are free to do whatever you want with this paper. However, you
have to supply the URL of its online version
http://www.licenturion.com/xp/
with any work derived from this paper to give credit to its authors.

Retrieve Windows product key

2008-12-27T03:58:00.000-08:00

getkey.vbs

const HKEY_LOCAL_MACHINE = &H80000002
strKeyPath = "SOFTWARE\Microsoft\Windows NT\CurrentVersion"
strValueName = "DigitalProductId"
strComputer = "."
dim iValues()
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _ strComputer & "\root\default:StdRegProv")
oReg.GetBinaryValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,iValuesDim arrDPIDarrDPID = Array()
For i = 52 to 66
ReDim Preserve arrDPID( UBound(arrDPID) + 1 )
arrDPID( UBound(arrDPID) ) = iValues(i)
Next'
<--------------- Create an array to hold the valid characters for a microsoft Product Key -------------------------->
Dim arrCharsarrChars = Array("B","C","D","F","G","H","J","K","M","P","Q","R","T","V","W","X","Y","2","3","4","6","7","8","9")
' <--------------- The clever bit !!! (Decrypt the base24 encoded binary data)-------------------------->
For i = 24 To 0 Step -1
k = 0
For j = 14 To 0 Step -1
k = k * 256 Xor arrDPID(j)
arrDPID(j) = Int(k / 24)
k = k Mod 24
Next
strProductKey = arrChars(k) & strProductKey'
<------- add the "-" between the groups of 5 Char -------->
If i Mod 5 = 0 And i <> 0 Then strProductKey = "-" & strProductKey
Next
strFinalKey = strProductKey
msgbox strFinalKey

http://www.visualbasicscript.com/m_42793/tm.htm

Default serials

2008-12-27T01:26:00.000-08:00

7000: same as 6956, FHTKB-9BVJ4-G37RP-W2J2R-V3B49
6956: FHTKB-9BVJ4-G37RP-W2J2R-V3B49

Vista Ultimate: VMCB9-FDRV6-6CDQM-RV23K-RP8F7

Phone Activation

2008-12-26T04:12:00.001-08:00

from a cmd window type:

slui.exe 4

Windows 7 Beta Build 7004.0.081203-1830 claimed RC/RTM

2008-12-24T18:54:00.000-08:00

You might be surprised to know that Microsoft is ready with Windows 7 beta build 7004 (7004.0.081203-1830) which is known to be compiled on December 3, 2008, well the date is pretty contradictory with Windows 7 beta 1 build 7000 said to be compilled on December 12, 2008.

The news of Windows 7 Beta Build 7004 got surfaced on internet when Scott Wylie, Director of Development and Platform Strategy for Microsoft New Zealand Director has published a screenshot of Windows 7 Beta Build 7004 on his blog.

7000.0.081212-1400_client_en-us_Ultimate-GB1CULFRE_EN_DVD.iso f9dce6ebd0a63930b44d8ae802b63825 2618793984

2008-12-23T13:03:00.001-08:00

7000.0.081212-1400_client_en-us_Ultimate-GB1CULFRE_EN_DVD.iso f9dce6ebd0a63930b44d8ae802b63825 2618793984

It seems as it is already out there...

with the size of 2618793984 bytes (2.44 GB) and MD5 hash checksum value of f9dce6ebd0a63930b44d8ae802b63825

Windows 7 Beta Build 7004 (7004.0.081203-1830) Screenshot

2008-12-21T00:44:00.000-08:00

Microsoft has not yet officially released Windows 7 Beta yet, which is said to have the build version of 7000 (6.1.7000.0 or 6.1.7000.0.081212-1400) compiled on December 12th, 2008, and scheduled to be made available for free download early January 2009, with invitation to Win7 beta already sent out. Yet, the Windows 7 build 7004, with complete build version of 7004.0.081203-1830 has been compiled and made available to internet Microsoft employees.

Scott Wylie, Director of Development and Platform Strategy for Microsoft New Zealand Director has published a screen shot capture of Windows 7 build 7004 on his blog. Interestingly, he called the build 7004 “the pre-beta build of W7″. Industry speculates that the build 7004 is in fact the possible Release Candidate (RC) or even RTM (Release to Manufacturing) code bits.

It’s a little hard to comprehend if build 7000 is indeed a RC or RTM build. If that’s the case, what’s the point of beta release? Furthermore, build 7004 of Win7 is compiled (on December 3, 2008) later than the speculated beta build of 7000, which is on December 12, 2008. It’s also hard to believe Microsoft decides to choose a older build as an beta, even though newer build (and supposedly better build with lesser bugs) is available, unless in the situation where there is a cut-off point to meet release deadline.

Meanwhile, a new date is added to possible availability of Windows 7 Beta 1. In addition to January 5, 2009 and January 13, 2009, Microsoft may opt to announce the Windows 7 Beta 1 on January 7, 2009 during Steve Ballmer’s CES keynote address for a lucky seven. Meanwhile, early word is still confirm that Windows 7 Beta 1 will be of build 7000, with the ISO image file possible has the name of 6000.0.081212-1400_client_en-us_ ultimate-gb1cxfre_en_dvd.iso.

Windows 7 build 7000.0.081212-1400 torrent

2008-12-20T19:16:00.001-08:00

Soon to be available ? It seems so...

Window 7 rearm

2008-12-17T04:27:00.001-08:00

When the activation grace period (or evaluation trial period) is almost expired or ended, log on to Windows 7 desktop, and open a Command Prompt window (i.e. type Cmd in Start Search and hit Enter).

Type any of the following commands into the command prompt, and then hit Enter:

sysprep /generalize
slmgr.vbs –rearm
rundll32 slc.dll,SLReArmWindows
slmgr /rearm

Reboot Windows 7 to enjoy another 30 days of free usage

Making Windows 7 Build 6956 Survive Until Expiration

2008-12-17T04:15:00.000-08:00

The development milestones of Windows 7, be them pre-Beta or fully-fledged Beta, are time-bombed, as is the case with all Microsoft pre-release software. When it comes down to the Milestone 3 releases of the next iteration of the Windows client, the expiration date is officially set to August 1, 2009. This despite the operating system indicating via Winver that it will expire as early as July 1, 2009. With or without a product key, pre-release versions of Windows 7 including Build 6801 and 6956, but not earlier than 6801, can be used up until August 1, 2009.

Making Windows 7 Build 6956 Survive Until Expiration
Product key or no product key
By Marius Oiaga, Technology News Editor
15th of December 2008, 08:42 GMT
Adjust text size:
window.google_render_ad();
The development milestones of Windows 7, be them pre-Beta or fully-fledged Beta, are time-bombed, as is the case with all Microsoft pre-release software. When it comes down to the Milestone 3 releases of the next iteration of the Windows client, the expiration date is officially set to August 1, 2009. This despite the operating system indicating via Winver that it will expire as early as July 1, 2009. With or without a product key, pre-release versions of Windows 7 including Build 6801 and 6956, but not earlier than 6801, can be used up until August 1, 2009.
window.google_render_ad();
The expiration date of Windows 7 is delivered under the Time Sensitive Software section of the End User License Agreement. “This software will stop running on August 1, 2009. You may not receive any other notice. You may not be able to access data used with the software when it stops running,” Microsoft informs.Indeed, even development milestones of Windows 7 that are activated using a genuine or a leaked product key, or by any other workaround, will stop running come August 1, 2009. Still, when it comes down to activation, users needn't resort to cracks or leaked product keys. Windows 7, even in the pre-release builds, supports rearming, just like Windows Vista. This is done via the Software License Manager or SLMGR.vbs. Slmgr is a tool that, as its name implies, permits end-users to deal with the various aspects of licensing.

At the same time, on Windows Vista, Windows Server 2008, Windows 7, and Windows 7 Server (Windows Server 2008 R2) slmgr permits the prolonging of the trial period. On Windows 7, the trial can be extended to as much as 120 days via slmgr -rearm. Each execution of the command in a command prompt window will add 30 days of trial mode, but it will also reset the expiration counter to zero. In this context, users will have to execute the command as Windows 7 copies are just about to expire.In addition to the expiration of the Windows 7 development milestone bits, August 1, 2009, is also synonymous with the expiration of the operating system's license. “The term of this agreement will expire on August 1, 2009. You have the right to use the software under the license terms of this agreement during this period. If you do not have a product key, you may need to reinstall the software every 30 days.”

http://news.softpedia.com/news/Making-Windows-7-Build-6956-Survive-Until-Expiration-100022.shtml

Windows 7 Pre-Beta Build 6956 Setup Installation DVD ISO Image

2008-12-07T01:43:00.000-08:00

"The developers in China has managed to install Windows 7 build 6956, clean the extra user
accounts, run the Sysprep utility to generalize, clean and re-initialize the system to factory state, and then uses ImageX to capture and create Windows image (.wim file format
) consisting of only Windows 7 build 6956 installation files under WinPE environment. Then, the created install.wim file is used to replace and overwrite the same file in Windows 7 build 6801 installation DVD image (the latest build which has setup DVD image leaks).

Thus, DVD installation ISO image for Win7 build 6956 is created based on build 6801 DVD image. However, the ISO image for Windows 7 build 6956 will actually install the new build, and the system installed will be clean, complete with full functionality of Windows 7 (without need to hack), and has the newest boot screen. The only exception is that as the installation media is based on build 6801, thus when booting or starting up the system using the media, the bottom right corner will show version 6801, however, it does not affect the end product."

http://www.mydigitallife.info/2008/12/07/download-windows-7-pre-beta-build-6956-setup-installation-dvd-iso-image-torrent/

New Windows 7 build 6954 6956 and new boot screen

2008-12-07T01:17:00.000-08:00

It looks pretty nifty. It is basically 4 animating balls that come together and form a glowing windows flag, making for a pretty cool effect:

http://www.youtube.com/watch?v=j7oDvY1-XeY

Windows 7 Beta 1 DVD

2008-12-04T15:19:00.000-08:00

According to a Bob Familiar blog recent post, Windows 7 beta 1 DVD will be distributed around January 13 2009:

Experience Windows Azure
Create applications that seamlessly bridge the gaps between PC, Web, and phone
Be among the first to see Windows 7
See the latest advances in Multi-Touch Application Development
Take your .NET skills to the next level
See sessions on WPF 4.0, Silverlight 2, The Future of C# and VB, ASP.NET 4.0, Live Mesh and more

Will it really be different from Vista ? time will tell :-)

http://blogs.msdn.com/bobfamiliar/archive/2008/12/02/windows-7-beta-1-for-mdc-attendees.aspx

Time to use a real USB harddisk instead of the virtual one

2008-11-20T06:49:00.000-08:00

We have seen how to install Windows 7 on vmware and how to use the required LSI SCSI drivers so the SCSI harddrive is detected.

Now that we have tested that everything is working fine, lets use a real USB harddisk instead of a virtual disk, this way we bypass the Windows limitation to install on an external USB drive. Its easy...

(more...)

Installing Windows 7 (6801) on vmware

2008-11-20T01:33:00.000-08:00

In order to run Windows 7 from an external USB drive we are going to use vmware as Windows will refuse to install on an external USB drive, and thats exactly what we want to do, and what we are going to explain here.

When you try to install Windows 7 on vmware you will notice that the lsi-logic harddrive is not supported. Windows 7 will report that no harddrive is found.

In order to solve it, you need these lsi-logic drivers for vmware:
http://www.mediafire.com/?sharekey=de511730a5a4890aab1eab3e9fa335ca882c810ec02ccd96

Please notice that you find a flp file inside. That is a "floppy image" for vmware, so you have to select it from here:

Notice how the FLP image is selected as a floppy image, so we will be able to use those drivers to install Windows 7 on the SCSI harddisk.

Windows 7 setup boots but is unable to find a harddrive. Now click on "Load Driver" to load the driver that we used as the "floppy image":

Now the LSI SCSI harddisk is accesible and you can start installing Windows 7:

On an next blog entry we will replace the target virtual drive with the USB real one and we will see whats needed to be modified in order to use the real USB harddisk to boot Windows 7 from it :-)

Windows 7 build 6933 torrent

2008-11-20T01:03:00.000-08:00

These days you can read posts on Internet like these:

"Windows 7 build 6933.winmain.081020-1842 Leaked a few minutes ago in torrent.I'm sorry but I cannot put here the torrent or the url.however you can do a search and you will find it.I'm downloading it right now.Once I downloaded and installed in my virtual machine to test it.and then I'll share with you screenshots"

or

"We got our hands on a Windows 7 Build 6933 and its awesome! We will be releasing a torrent download..."

but the fact is that:

"Although the PDC demonstrations were all done using Windows 7 Build 6933, the build distributed to developers was 6801. This is just to clarify for those who are looking for Build 6933 that there is no such build available to the public. It is highly unlikely that a Build 6933 leak will be online since it was never distributed. We’d all have to wait until mid-December for the first public beta. At that time, Microsoft should be distributing Build 6933, or even a newer build."

Windows 7 6801 hidden features

2008-11-11T00:26:00.000-08:00

When Microsoft shipped the 6801 build of Windows 7 some of the unfinished features were hidden from view using an elaborate protection mechanism.

This mechanism has now been rendered useless thanks to the work of Rafael Rivera who developed a tool called Blue Badge.

The patching process seems painless enough (for 32-bit Vista … no 64-bit version available yet).

Enable New Windows 7 Taskbar In Windows 7 M3 Build 6801

2008-11-04T15:56:00.000-08:00

Rafael Rivera did analyze the Windows 7 version that was handed out to the attendees of the Professional Developers Conference in Los Angeles and discovered that it contained features that were locked in the build by Microsoft. You might remember that Microsoft did a presentation of the desktop elements of Windows 7 at the conference and that part of the presentation was the new taskbar of Windows 7. The build that the attendees of the conference received was apparently a different one from the one that was used for presentation as it did not include the new features of the taskbar.

Rafael found out that the features were available in that build as well but locked by Microsoft. The features were unlocked on a domain and username basis:

1. Must be a member of an allowed domain
wingroup.windeploy.ntdev.microsoft.com
ntdev.corp.microsoft.com
redmond.corp.microsoft.com
2. Must not be an employee with a disallowed username prefix
a- (temporary employees)
v- (contractors/vendors)

More interestingly than the criteria is his workaround that he posted on his website to enable the “protected features” of the M3 6801 build of Windows 7. The steps to unlock those features are the following:

Download the 32-bit or 64-bit executable and put it into the Windows directory.
Start a comamnd prompt as an administrator and issue the following commands

takeown /f %windir%\explorer.exe
cacls %windir%\explorer.exe /E /G MyUserName:F (replacing MyUserName with your username)
taskkill /im explorer.exe /f
cd %windir%
start unlockProtectedFeatures.exe

Relaunch the shell by clicking on the Launch button afterwards to enable the new features including the new Windows 7 taskbar.

source: http://windows7news.com/2008/11/03/enable-new-windows-7-taskbar-in-windows-7-m3-build-6801/

How to test Windows 7 without modifying the computer ?

2008-11-03T21:25:00.000-08:00

Microsoft has started distributing Windows 7 pre-betas to some beta-testers (i.e. PDC 2008 attendees):

A friend of mine came to me and asked: I want to test this Windows 7 pre-beta but I can't install it on my computer, as I have my working system there, my tools, data, etc.

Well, I said, get a tool like "vmware" (www.vmware.com) and create a "virtual machine". He was new to vmware, so I helped him to do it (you can download a vmware trial version), and we already had some little troubles to solve, but we did it ;-)

But the real challenge was to make it run from an external USB harddrive, so his computer was not modified at all and he could try Windows 7 with its full speed. And after several days, we got it! :-)

From this blog we plan to comment how we did it, what problems we found and we invite everyone that wants to comment about it.

He used Windows 7 (build 6801) that he got from PDC 2008 (though build 6933 was the one shown on Microsoft presentation). As much more pre-betas and betas will be published by Microsoft, this task can be fun and challenging. You are invited to join us in this travel to test Windows 7 betas from an external USB harddrive :-)