SP2 865/875 Microcode Industry Failure?

  • Thread starter Thread starter Ron Reaugh
  • Start date Start date
Paul said:
I don't understand all the details, but the microcode itself is
encrypted for this very reason. To make it harder to craft a 2KB
"bomb" to load into the processor. Judging by the fact that the
tools I use can list version info, the headers must be in plain
text. I don't recall where the microcode method is documented,
but there were some discussions about microcode a while back where
some of this was discussed.
Click to expand...

Do you remember where exactly?
 
Jan said:
I run a P4 3.4 GHz Northwood on a P4C800-E DLX MB (Bios version 1016) and
the reported CPU Revision = 17 (I used the Win version of the application).
Is that normal? (looks quite high compared to 7 or 8)
Click to expand...

This whole thread is only about Prescott so Northwoods 17 is in a different
arena.
Ron Reaugh said:
I had BIOS 1016 on a P4C800-E Dlx and the Intel Frequency ID app showed
CPU Revision = 7. 7 was reported with both the boot floppy version and the
XP version underp XP SP1(one).

I have now flashed BIOS 1017. The build date as shown inside BIOS setup on
the Information Screen 7/24/04.

The Intel Frequency ID app continues to show CPU Revision = 7 using the boot
floppy version of the Intel app AND using the XP version under XP SP1(one).
Yet as cited in the MS XP NG article below, what is supposed to be
Click to expand...
there
is
"at least 8".

Now if it's supposed to be 8 and apparently it is 8 on Intel mfg mobos then
why isn't 8 here in this recent release Asus BIOS?

The industry failure and/or competence level may be a version issue and not
a there/not there issue. Anyone?

of
XP
Click to expand...
using
a
Click to expand...
http://www.google.com/groups?q=+"[email protected]&rnum=1
An MVP there Cari had detected the issue and was pursuing it with
Click to expand...
MS
and
Intel.

Current Intel CPUs have the ability to have their internal microcode
updated
on the fly(addenda fixed). Apparently that microcode update is done
both by
the mobo's BIOS during POST and during OS init by
%windir%\system32\drivers\update.sys.

What was determined is that MOST all the major mobo mfgs around
Click to expand...
are
NOT
keeping their microcode current, at least for 865/875 chipset mobos,
even
with recent BIOS updates! That old CPU microcode(non-existent BIOS
microcode update apparently in many cases[=0]) was causing SP2 to hang
after
install.

One can view/report that microcode revision level by running Intel's
Frequency ID utility. The entry to look for is "CPU Revision = n" where
n
= 0 which is the microcode revision level.

Cari's conclusion as apparently gleaned from MS & Intel was that NO
major
mobo mfg has been keeping their microcode(addenda) current EXCEPT Intel.
Cari claimed to have tried a broad range of 865 and 875 chipset mobos
with
SP2 and most all failed! She then said that she'd never use anything
except
an Intel mfged mobo again as if after her eureka moment.

Does anyone know more precise details of the overall technology involved
here and the overall industry competence with respect to CPU microcode
updates. What is the BIOS supposed to be doing here; is there any
standard? What does %windir%\system32\drivers\update.sys do exactly?

The implication is that most all of us 865/875 chipset mobo owners (and
I
assume that the issue is MUCH WIDER) have been running with all
Click to expand...
the
CPU
bugs/addenda UNFIXED!

I don't know why this issue is blown all out of proportion.

It is an issue that is not well known which is why I'm trying to find more
details and also see what folks know in general.

It is like the second coming or something.

If an OS is so dependent on microcode being correct, a fairly simple
algorithm and small file of microcode segments would fix it.

Well then what does this do in XP?
%windir%\system32\drivers\update.sys

Microsoft
should consider moving the microcode loader up in their boot sequence,
like before some other kernel files are loaded.

I got the impression that there was some condition precedent required
Click to expand...
in
the
BIOS and that's why %windir%\system32\drivers\update.sys didn't work
Click to expand...
and
the
fix was to rename update.sys ??? Please clarify.

Inside an Asus BIOS, there is a file called cpucode.exe and it will
consist of perhaps 8 or so 2KB microcode segments. Apparently, at least
in some of the older BIOS, there were also a couple of 2KB
"cache segments" in the flash chip as well, and if a new processor
is detected, the microcode segment that loads successfully, is stored
in one of the two cache segments. The BIOS effectively has to
"flash itself", and contains the code to do that. There is actually
a procedure for Award BIOS, where a user can "write" the cache
segment with their own Prescott 2KB code segment, if they want to.
(I have done this on a P2B-S, to get microcode support for a Tualatin.)
The program is called CTMC from CT Heise magazine. In other words,
for the initiated, they can actually prep their BIOS to be "SP2
ready" if they want to, without waiting for Asus (AFAIK works
for Award BIOS, no idea if it works for AMI, as the hook and
methodology of the AMI BIOS could be different).

Asus updates BIOS files on a fairly regular basis. One user here
owns a T2-P Asus small form factor system, and while the Asus
cpusupport page doesn't currently list his system, he claims it
supports Prescott or the advert copy says it supports Prescott.
When I extracted the file of microcode segments for the most
recent version of that BIOS, there were no Prescott family code
segments in the file. So, indeed, in that case, support was
lacking. Other users here who have had "SP2 trouble", aren't
running the latest BIOS, so the solution there is clear.

To keep all these BIOS updated to cover the latest Intel
inprovements, means there will always be a gulf between the
latest released microcode segments and what is available for
download from Asus.

Prescotts were shipping in March.

I'm sure when a new processor is
released at Intel, it even takes Intel a day or two to update
their BIOS files, so Cari shouldn't be too smug sitting on
an Intel motherboard.

And finally, there is probably a small number of users who
have stuffed Prescott processors in non-Prescott boards,
and whatever happens, is of their own making. If your old
motherboard lists Northwood 0.13u processor support, that is
what you should be buying for it.

Seeing as microcode loading existed in my 440BX based P2B-S
motherboard, I would say the "industry competence" is there.

Well, the question is whether the appropriate microcode is getting
Click to expand...
Click to expand...
out
in level to
Click to expand...
Click to expand...
 
... et al. said:
Not on this technical level.
But one of my favourite complaints in this newsgroup (the *.asus
one) is that their BIOS updates (for my A7V333 board) come
*without any* documentation *at all* !! And from what i gather
that behaviour is nothing exceptional, but rather bussiness as
usual from motherboard manufacturers. :-(
Click to expand...

Yes, but now an actual situation has arisen making that clearly
unacceptable.
 
I don't understand all the details, but the microcode itself is
encrypted for this very reason. To make it harder to craft a 2KB
"bomb" to load into the processor. Judging by the fact that the
Click to expand...

Paul,

Ah, crypto, something I DO know about. Semi-dumb question. Can you
extract the microcode from a CPU? If so, is it written in any kind of
language anyone would understand? This is out of curiosity and not
key to what I am going to write below.

If you can extract the actual microcode, then you have "cleartext" in
crypto-land-speak. The encrypted microcode is "ciphertext." There
are lots of tools to determine the encryption key given both
cleartext and ciphertext.

The security company RSA Security has posted "challenges" on the net,
which consist of an encrypted message. Several online groups have
organized "set-at-home-like" groups to crack the enciphered messages
successfully.

It would help to have multiple text pairs from a given CPU. Then you
run brute force attacks on the pair until you get the encryption key.
Unless Intel (and AMD?) is really dumb, each CPU model, and perhaps
each stepping, uses a different encryption key.

If I had to guess at the crypto algorithm, I would say either AES at
256 or greater length, or perhaps Triple-DES for older processors.

I'm pretty confident that "shared secret" or symmetric crypto is used,
where the same key both encodes and decodes. Thus, if you can
determine the crypto key for a given sample of a CPU, you probably
have a key good for every sample of that CPU.

I'm also pretty confident that Intel isn't using Public Key crypto,
where every CPU would have a different private key, because that would
make the ability to distribute microcode updates unmanageable. (You
would need a separately encrypted version of the code for each and
every CPU you want to upgrade.)

If the Intel engineers were not smart (which I seriously doubt, they
would write their own crypto algorithm. Inevitably homegrown crypto
has weaknesses. Standards like DES, Triple-DES and now AES have
undergone lots of public scrutiny.
 
Good discussion, folks, so it's
SP2 + Prescott = hang, unless on an intel mobo.
Click to expand...

No, it is considered on a case by case basis, and the Intel
Frequency ID utility shows the version of microcode being used.
Based on the version being a particular one, with the Prescott,
that is how you decide to install of not. If some kind person
will examine your mobo maker's BIOS microcode files for you,
they can even tell you which minimum BIOS is required to be
flash upgraded to the motherboard, to make it "SP2 Prescott"
ready. For example, some Asus 875/865 BIOS are more than
ready, and others are not - microcode updates are not issued
separately, but new microcode is bundled with bug fixes to the
BIOS, and that is why they are late in coming on some boards.

So, Intel doesn't have the market cornered :-) In fact, I bet
even Microsoft could fix this, if SP2 wasn't so "bug free". It
is my belief that an improved update.sys file could fix this,
and this is a NIMBY (not in my back yard) problem. I'll believe
that, until someone tells me exactly what SP2 update.sys is using
for its own microcode patches.

Paul
 
I have a ABIT IC7MAX3 motherboard with 1 gig of Coasiar PC3200 and a P4 3.0
prescot CPU
2 40 gig maxtor drives and 1 120 gig maxtor drive with a sony DRU510a DVDRW
and a Philips sound card using a geforce ti4600 vid card.
This Board has Bios rev13 on it .
What I need to know is if I flash the Bios to Rev 16 will this alow me to
run the SP2 update.
I have read many post that I need and updated version of mircocode for SP2
to run.
Curently it shows my CPU as 0 but should be a 8.
When I install the SP2 update it lads fine but when it shuts down to reboot
it hangs on startup.

Any help welcome.....
 
On Sun, 12 Sep 2004 13:31:13 GMT, Brian Brunner

:> Good discussion, folks, so it's
:> SP2 + Prescott = hang, unless on an intel mobo.

Not here, working just fine together.
 
"Eric Burghdoff" said:
I have a ABIT IC7MAX3 motherboard with 1 gig of Coasiar PC3200 and a P4 3.0
prescot CPU
2 40 gig maxtor drives and 1 120 gig maxtor drive with a sony DRU510a DVDRW
and a Philips sound card using a geforce ti4600 vid card.
This Board has Bios rev13 on it .
What I need to know is if I flash the Bios to Rev 16 will this alow me to
run the SP2 update.
I have read many post that I need and updated version of mircocode for SP2
to run.
Curently it shows my CPU as 0 but should be a 8.
When I install the SP2 update it lads fine but when it shuts down to reboot
it hangs on startup.

Any help welcome.....
Click to expand...

ftp://ftp.abit.com.tw/pub/download/bios/ic7-max3/ic7p16.exe

Microcode utility ctmc V1.0, c't/Andreas Stiller 02/2001
Filename Version UpdateID Date CPUID Checksum LoadVers Platform
CPUCODE.BIN 00000001 0000002E 02.05.2003 00000F12 B2548D0A 00000001 00000004
CPUCODE.BIN 00000001 00000001 29.05.2001 00000F21 78CDDD37 00000001 00000004
CPUCODE.BIN 00000001 00000008 30.07.2001 00000F23 7483278F 00000001 00000004
CPUCODE.BIN 00000001 0000001E 05.06.2003 00000F24 9BA58D71 00000001 00000004
CPUCODE.BIN 00000001 00000005 08.05.2003 00000F13 386C53DA 00000001 00000004
CPUCODE.BIN 00000001 0000001B 03.02.2004 00000F25 DCBE99DE 00000001 00000004
CPUCODE.BIN 00000001 00000037 04.06.2003 00000F27 972CD5FA 00000001 00000004
CPUCODE.BIN 00000001 00000017 18.07.2003 00000F29 C42D13A3 00000001 00000004

Prescott has a CPU ID of 00000F33. You can go to processorfinder.intel.com
and use the SLxxx number (a.k.a SSPEC) from the box the processor came in,
to look up the info page for your processor. You can use that to verify
that you have a 0F33 processor.

Notice there is no 0F33 microcode in the latest Abit BIOS. As if Abit
didn't want you to put a Prescott in there ? Even though their release
notes proudly proclaim Prescott ?

OK, get a copy of CTMC:
ftp://ftp.heise.de/pub/ct/ctsi/ctmc10.zip

It has three tools in it. CTMC.exe, splitawd.exe, and lha.
(It's been a while - I think the lha is a self extracting archive,
and the real lha.exe is inside it.)

The first step is to find another Award BIOS that has Prescott
microcode in it. In a DOS (command line) window, cd to your
working directory, and with only splitawd.exe and the donor BIOS,
do "splitawd donor.bios" where donor.bios is the filename of
the BIOS. This will yield some screen output, identifying the names
of the modules, and the modules themselves are numbered. An Award
BIOS is a bunch of LHA compressed modules, so once splitawd finds
the modules, the next step is to take note of which numbered module
is named "cpucode.bin" or the like. (Note: For me at least, splitawd
will hang, if you make lha.exe available to it in the same folder.
That is why splitawd should be by itself with the donor BIOS file,
so that it cannot call lha.exe, to try to decompress the file. I
got stuck when it got its hands on lha.exe. I do the decompression
step separately to avoid this problem.)

Now, find a copy of lha.exe, get the file from $MCTEMP that
the text output of splitawd said contains cpucode.bin .
Use the command "lha x 00000002.bin", where in this example
00000002.bin is the file that contains cpucode.bin. lha will
decompress the file for you. Now, you will have cpucode.bin.

Next, bring a copy of ctmc.exe into the place where the cpucode.bin
file is. Do "ctmc cpucode.bin /store >>log.txt". After a short
pause, there will be a bunch of 2KB files. These are the individual
microcode files for various Intel processor types. Here is
a version 0x0B (11 decimal) of a Prescott 0F33 microcode, for
example. I have uuencoded the data, because the final 2KB file
is binary encoded. (You may be able to use this for your board.
That is why I included it.) When decoded, this file is exactly
2048 bytes.

BEGIN-------cut here-------CUT HERE-------PART 01

END-------cut here-------CUT HERE-------PART 01

Once you have the microcode file, the next step is to install
it. Do "ctmc 0F330D0B.BIN /write" and ctmc will use the Award
BIOS hook INT15 Function D042, to flash the 2KB microcode
segment into a temp area in the BIOS chip. Assuming this
works and the program doesn't complain, you can test that it
really worked, by powering down the computer and starting up
again, to make sure there is no microcode present inside the
processor, and that it really came from somewhere else in the
computer.

Once back into Windows, use the Intel ID Utility to check the
version - now the Prescott should be at version 11 decimal.

Note - I've used this procedure on an Asus 440BX board with
Award BIOS, to put a microcode for a 06B4 Tualatin, but have
not tested this on my P4C800-E, because it has an AMI BIOS
and CTMC is not compatible with it.

Note2 - Since a temp area is used inside the BIOS flash chip,
if you pull the Prescott processor and install, say, a
Northwood, the temp area gets flushed and repopulated with
Northwood microcode. So, if you flip processors in and out of
the board on a regular basis, repeat the "/write" step above
after reinstalling the Prescott processor. Similarly, if you
happen to download a new BIOS from Abit and flash it, that will
wipe out the temp area as well (a good thing, if the Abit BIOS
actually contains its own Prescott microcode).

HTH,
Paul
 
Floyd Drennon said:
On Sun, 12 Sep 2004 13:31:13 GMT, Brian Brunner

:> Good discussion, folks, so it's
:> SP2 + Prescott = hang, unless on an intel mobo.

Not here, working just fine together.
Click to expand...

What mobo and what was the release date of the BIOS you were using during
the SP2 install? What does the Intel Frequency ID utility report for "CPU
revision ="?
 
Paul said:
No, it is considered on a case by case basis, and the Intel
Frequency ID utility shows the version of microcode being used.
Based on the version being a particular one, with the Prescott,
that is how you decide to install of not. If some kind person
will examine your mobo maker's BIOS microcode files for you,
they can even tell you which minimum BIOS is required to be
flash upgraded to the motherboard, to make it "SP2 Prescott"
ready. For example, some Asus 875/865 BIOS are more than
ready, and others are not - microcode updates are not issued
separately, but new microcode is bundled with bug fixes to the
BIOS, and that is why they are late in coming on some boards.

So, Intel doesn't have the market cornered :-) In fact, I bet
even Microsoft could fix this, if SP2 wasn't so "bug free". It
is my belief that an improved update.sys file could fix this,
and this is a NIMBY (not in my back yard) problem. I'll believe
that, until someone tells me exactly what SP2 update.sys is using
for its own microcode patches.
Click to expand...

There is an ongoing question as to whether update.sys is in fact a microcode
loader. No one has been able to show that a system before and after
update.sys ever shows a different "CPU revision =" from Intel's Freq ID.
Some have been looking including on Northwoods.

What exactly happened here with this whole deal remains a deepening mystery.
 
Eric Burghdoff said:
I have a ABIT IC7MAX3 motherboard with 1 gig of Coasiar PC3200 and a P4 3.0
prescot CPU
2 40 gig maxtor drives and 1 120 gig maxtor drive with a sony DRU510a DVDRW
and a Philips sound card using a geforce ti4600 vid card.
This Board has Bios rev13 on it .
What I need to know is if I flash the Bios to Rev 16 will this alow me to
run the SP2 update.
I have read many post that I need and updated version of mircocode for SP2
to run.
Curently it shows my CPU as 0 but should be a 8.
When I install the SP2 update it lads fine but when it shuts down to reboot
it hangs on startup.

Any help welcome.....

hang

see:
http://support.microsoft.com/default.aspx?kbid=885626

http://cquirke.mvps.org/sp2intel.htm
Click to expand...
 
ftp://ftp.abit.com.tw/pub/download/bios/ic7-max3/ic7p16.exe

Microcode utility ctmc V1.0, c't/Andreas Stiller 02/2001
Filename Version UpdateID Date CPUID Checksum LoadVers Platform
CPUCODE.BIN 00000001 0000002E 02.05.2003 00000F12 B2548D0A 00000001 00000004
CPUCODE.BIN 00000001 00000001 29.05.2001 00000F21 78CDDD37 00000001 00000004
CPUCODE.BIN 00000001 00000008 30.07.2001 00000F23 7483278F 00000001 00000004
CPUCODE.BIN 00000001 0000001E 05.06.2003 00000F24 9BA58D71 00000001 00000004
CPUCODE.BIN 00000001 00000005 08.05.2003 00000F13 386C53DA 00000001 00000004
CPUCODE.BIN 00000001 0000001B 03.02.2004 00000F25 DCBE99DE 00000001 00000004
CPUCODE.BIN 00000001 00000037 04.06.2003 00000F27 972CD5FA 00000001 00000004
CPUCODE.BIN 00000001 00000017 18.07.2003 00000F29 C42D13A3 00000001 00000004

Prescott has a CPU ID of 00000F33. You can go to processorfinder.intel.com
and use the SLxxx number (a.k.a SSPEC) from the box the processor came in,
to look up the info page for your processor. You can use that to verify
that you have a 0F33 processor.

Notice there is no 0F33 microcode in the latest Abit BIOS. As if Abit
didn't want you to put a Prescott in there ? Even though their release
notes proudly proclaim Prescott ?

OK, get a copy of CTMC:
ftp://ftp.heise.de/pub/ct/ctsi/ctmc10.zip

It has three tools in it. CTMC.exe, splitawd.exe, and lha.
(It's been a while - I think the lha is a self extracting archive,
and the real lha.exe is inside it.)

The first step is to find another Award BIOS that has Prescott
microcode in it. In a DOS (command line) window, cd to your
working directory, and with only splitawd.exe and the donor BIOS,
do "splitawd donor.bios" where donor.bios is the filename of
the BIOS. This will yield some screen output, identifying the names
of the modules, and the modules themselves are numbered. An Award
BIOS is a bunch of LHA compressed modules, so once splitawd finds
the modules, the next step is to take note of which numbered module
is named "cpucode.bin" or the like. (Note: For me at least, splitawd
will hang, if you make lha.exe available to it in the same folder.
That is why splitawd should be by itself with the donor BIOS file,
so that it cannot call lha.exe, to try to decompress the file. I
got stuck when it got its hands on lha.exe. I do the decompression
step separately to avoid this problem.)

Now, find a copy of lha.exe, get the file from $MCTEMP that
the text output of splitawd said contains cpucode.bin .
Use the command "lha x 00000002.bin", where in this example
00000002.bin is the file that contains cpucode.bin. lha will
decompress the file for you. Now, you will have cpucode.bin.

Next, bring a copy of ctmc.exe into the place where the cpucode.bin
file is. Do "ctmc cpucode.bin /store >>log.txt". After a short
pause, there will be a bunch of 2KB files. These are the individual
microcode files for various Intel processor types. Here is
a version 0x0B (11 decimal) of a Prescott 0F33 microcode, for
example. I have uuencoded the data, because the final 2KB file
is binary encoded. (You may be able to use this for your board.
That is why I included it.) When decoded, this file is exactly
2048 bytes.
Click to expand...

Great. My attachment and the rest of the post got cut off :-(
I guess something enforced the no binary rule :-(

Anyway, when you get a 2KB microcode file, like 0F330D0B.bin,
do "ctmc 0F330D0B.bin /write" and CTMC will attempt to use the
INT15 Function D042 BIOS hook to write the microcode into the
BIOS chip. If the function is not in the BIOS, CTMC will
complain and you will have failed the update attempt.

If it claims to work, do a shut down to a power off state,
then boot up. Use the Intel utility to check the microcode
version. If the version has changed to reflect the new BIOS
(0x0B in my example above), then you can try SP2.

The microcode storage space used for this operation is volatile.
The microcode update can be lost if you swap another processor
type into the motherboard, as the BIOS uses the D042 function
itself, when a new processor is detected. Similarly, if you
flash a different BIOS, the flash operation will clear the
microcode slot used as well.

(Now, since I cannot attach anything, you'll have to use splitawd
and CTMC, to test extract other Abit Award type BIOS, until
you find a 0F330D0B of your own.)

I'm going to throw the lines of uuencoded stuff on the end of this
post anyway, just to see if it gets through.

HTH,
Paul

This is what goes after the line with the 644 in it. Remove
the tilde ~ character from the beginning of each line. The
decoded file should be exactly 2048 characters - if it is not,
then I screwed up somewhere.

~M`0````L````$(!(%,P\``.J*9N4!````#0``````````````````````````
~M````'*?]1;,\R,6CI]QZB,X&Z<)W1K_M>FLL+%O+$BBC7LR&B5!!+]WJ^O>4
~M,UJ^/O(\18K5Z3H84L)`)I!1T$+O5=[#>Z18<U\WB[,3_W'P=&YJP#HU'>E=
~M3/#ANBNC#($O2[U96CXC^VN*!*LL0L8$LJ'DSRS\)X4R.[HL@?<\N(S.`0.#
~MZ3]!K8=3<PAU<WTZ!:E,@B+T6Y_#_<P&SU57:;H;,MLQ,Q`O]1X0!;1.6%A#
~M,%WD85<"=&T<``U(JW(?S?Y#K5I!\5X196>B\%;?HEU88UC(S3$*+F/17/+%
~MOI$UK/,7%#RRH!5WH)H%Z;8TGOJ#NBS!"))V"+*&L;M:;:O$I!%V[M4@&R1^
~M"J4005`62:$XT@T68E62%<21_!PA"$5D&Y&_TUEHH<K9'R;6SGNDT$IUE&,R
~M'<&/!L[?(?FV0$:?(\7BPC7^!\HDL;4H'/;7YKY/]?VX\]#3N-Y$",(.70S#
~M@ULYX9Z<1KC9>"\!W,+O`;5B!5(^R+62,@DZYB#?T['3[R>5B&H'&45`WZ70
~M(-NP)MD[:NEP=%(H1O'[K\8?./T=P;O#K62Z'2`W[^N-?^R$ON.!Z3,,;X`6
~M/AUDZ\3?8*DD?/SNF5KO>!FO,K*T&#L[/$8B>?K?-PLTL84[\H(5NAA,<,`"
~MV:&4K'=ZL>_$[\DH=I><E7@YB)G*I<$!PT*[I-^V+C>7O7`H"FIGNO`9RIP@
~M0K8M["4@?>H>[&;PW8DHAY"1CTS6^5DW2IS5.=S]?VLY1LM@N9LM"I-3;T]?
~M_D!6?Y#8%(RVZ!:S,M%=^-\C3YES6XP)2<<W++Y$QTOCZPW63)@G2;,[*VX&
~MZ%%ML<U@-KO6MF"&&3S"F:53M]<F/E\!)Z/O!C'?E-I!X\]0$8$7$KDCYA0]
~MI`5>9C(;:S]2L%LZMXJ>F-J6*Y%SK90V13ZU*T@R=Z37=M.Y_I-8@0\FG.I!
~M.Q4C``Q`%@Y`%+;Z]P0<,AQLCHVPOP`L!GLV6$2P#I%OOJ4GS"XJ/&5ME\)?
~M::G)1AHT69`B2O_`IJ7K?DDKXAE0,QZGM:ETN+0XW87X"T.FC!4967U7!6U?
~M-$F7+MF0$QPJ#:U;`-NHJAOX\.]516[/@&Y2K+*8>+XBC]Z.V@S;AJHG!A,Q
~M)&R@E>5LCJ<B><8^BUEF4\5C<:5ZP?PR`NMV=D">N&/9.80_#N,)-*+]3D$+
~M15JS1<CG8@(E/!M:EVTH+@H)9#B&9%SXE/QY>1*YT0$&FT:DG",GNO(&B1DK
~MQO"3XD&.R]B?WW3),S+#7S<D/T'A#@:M:^#Q?Q)%RBX/'@.=>NQ^3"`VDE*(
~MT>V&9!]52T7K/.5)$/;^4Y):2),S9'<X6A(1"1#*3Z"XB%52B%*G*<V-Z"\^
~MX7`\-0M.`+4%5CF+N^\T@O>E#YTPZJXNI#W2/SHK5+!RAJ*.&,,?:J%&!VD"
~M;ZXTR.RIVJ%E4U!2"XSN"T&I8]5IKJ(<UC4\'C!./C&]JT80H<I,8-G&W187
~M![CT[^4]\1L23OXPD_\WIT(`VA:MSHFPG/NO4^,RP/2#0F*"3>5G:80`/E!*
~M>@`^\,5/D04@YY-%AZ9UMU:]PRG^9`\.\LQ&-8J6E4,^::ZL,(NM2M@2*IKQ
~M@6L=%)@.#9?,H:X\B`A-IGZG^3G@8ZREE]$O%T6Q>M3_B=,AI5NSQD9&`#T3
~M-1R[*6IG#+>C;N+5*X0CV?/B('K0"R(GN>&32&1\#K[A/*+EM>LU7Z@%HKM"
~M,RXMXD=F9.X']Z7#O'B&G!$BY&@O]\W)T,9)$`WZ7AS^[4`G$-$%NB\CCY=1
~MHM2DL]U?TOFNY3V7<+TVDI)`U.,];[email protected]$'%PNK3ZOJ?@M8#Q)P7>4RX4L
~MW'5.7"#CP5-?ZG]0XR0,MC5-L[]QJI`_K[CJH4RD>IPOW2>W'_N%L2OJ!?,B
~M]5`\&M(->BB)MH_V86L23,E?(Q,08VGHY@L]W,I6AY<(.`]AN>H@#"06**59
~M[Y\8:ADK57/H*@HU@!$>V]\TT)[$C/M>-K3,""0JGPVLJ.LC3*O!>J9`(^C_
~M@CH%H+S[O+DX4%X9"#/9X:./'[N*&W>I.:QGZELD49@GUIECI/Y22!T.`QJA
~M,>E./Z;V$H\>R)[email protected]?Q4&*NW<<7(NE8Q!\D4RM[W)?.E@K)5E)(*B
~MPTZ$POH$39Z9O-R(>AQ(=L2#)%2--Z,7E,1KT,'8)A$7**"%JPF_5!4("9WY
~MX]C?9Y<>N8)+4@5VGZZ?5CBCF6KV1QUJH$'(F!#`S`M!]-#&MEK[0<@:[YX-
~MK`;`IL,DZD9.X<3".L-R$'"-J-E[]!L^7E/E5PK@N1#539NHGC549B*;#$<%
~M;R#FV>S>)&BK0/>-,93+_6N\9W9MLM@[-Q,3IU7D22?MF'P=?.0G!=`(C$=`
~M8CC"@Y.347CTK\OP>')X68BDY*#VKR$?QX$YWF,6C'0J1M79(W(T7BH6DLY=
~MY=EE_-+`JW/^.I?B4S1YK0+&R%HUFMFIQ#;11MNH.4>_)U.[?26L=VX<_F91
~M?P\=XW3EV1M9=B+H^2+S*#//D\$]P).N9_T4&P-P=^:I<D]GLCEB+";Q#*1[
~MM)F'V#8(W&J3+SNBDP&2@HL=ZMT<SS\8\TEBT:@%EVML'28T4>#V9KC.O37F
~7QJ^D1M1ZXOL+Q$/X]IX_/O#1PE5)P!X@
~`
~this_word_should_just_be_the_three_letters_"end"
 
Back
Top