MAIN.HTM
========

Now what happens?

We have gone to "http://home.earthlink.net/~f60a/main.htm".

This page (and "pay.htm" which we will get to) loads the big brothers to
loadscr.js and loadlib.js.

The new modules are mainscr.js and mainlib.js.

All pages start with 200 blank lines and a line starting with 200 tabs.

These modules include code from the original page as well (checking for the
URL used and the browser being used with the option to misdirect away) but
to get here you are using a working browser and the code is not used.

mainscr.js has the encrypted strings that are used in mainlib.js.

The page runs some code while it is loading. This sets the window.onerror
function to one that does nothing. It updates some variables with your
browser information, blocks right clicks, creates and updates an array from
the data section in the URL used (there is none) and from the browser
variables, updates this array internally(*) (for added items to your shopping
cart - there are none).

(*) When the function sees a data section with an AddItem data section in
    the URL (as it will when it is used on "pay.htm") it creates a section
    of indices in the array for this. It has a separate section for items in
    the "shopping cart". The update takes the data it puts into the AddItem
    section and moves it to a new item in the shopping cart and recalculates
    the total cost, tax, etc. (by the way, the shopping cart code has the
    ability to handle shipping and tax: how many charge tax on shipping as
    this does?).

This page also has an onLoad() function - which tests and updates the form
on the page from the array (which has been updated from the data in the
URL).

(so: First get the data from the URL and some other variables, such as the
     browser and add them to the array and then update the array. This can
     be done as the page loads. We can't access the form on the page until
     the page has loaded. So use an onLoad() function which runs after the
     page has loaded and then update the form on the page from the array.)

Of course, most of this does nothing since this is the "main.htm" page and
there is no data section in the URL. However, this same module and code is
used on the "pay.htm" page and when we go to THAT page there WILL be a data
section in the URL used which WILL be added to the array, the array will
update it and will then add it to the form on that page.

However ... how about getting back to this page ("main.htm") ...

It shows a sale going on and the last time you can get the product on sale
is TONIGHT (OH WONDER OF WONDERS! WE GOT THERE JUST IN TIME!!) (it uses
JavaScript to get today's date for that little trick).

It has a form with a few items on it (including a field for REJECTION info,
which gets updated as you try to do things like use a fake id, use bad
language, etc.) and fields for the ADDED item. This is the item you are
choosing to purchase (download version only or CD+download, for example).

The form's action is "" (none). The method is GET (that is important, since
a GET URL will include the data as part of the URL in a search/data section
following a question mark at the end of the site location).

There are a few links. They are JavaScript URLs. When you click one
it changes a few items on the form (it changes the add item information
to that of the product you chose - the download or download + CD version).

The JavaScript URL changes the form's action to "pay.htm".

The JavaScript URL then submits the form (that is, loads the page:
"http://home.earthlink.net/~f60a/pay.htm" but with a data section
added to the end of the URL).

Thus, when you choose a product (download or download + CD) the click will
submit the form data using a GET operation as:

  "http://home.earthlink.net/~f60a/pay.htm
         ?AddItemDesc=(description_of_which_you_chose)
         &AddItemUnitPrice=(price_of_which_you_chose)
         &..."

PAY.HTM
=======

There is no script there (this is on earthlink that does not give out the
ability to use scripts on the public sites). HOWEVER, you do get the page
"pay.htm" which loads the same mainscr.js and mainlib.js files and has the
same code. NOW all that code for creating an array, updating it from the
data in the URL and then (when the page has loaded) updating the form from
that data - well that works now. That code has your browser take and parse
the data from the URL (the description, etc.), then update the array it has
created (it adds the item you chose to the shopping cart list in the array).

THEN it runs that same code to update the fields in the form on this page
from the array and other variables.

ON THIS PAGE there is a form with a product description, cost, tax, sections
for you to enter your credit card info, address, email_address (to get the
unlock code for the downloadable file), etc.

The form on this page has action "" (none) and the method is POST.

Well, with a method of POST this form will not be handled on the client
side.

How does it update the form (besides taking the item you selected and
changing the form field's to reflect that)?

It also updates it from some other encrypted variables in mainscr.js.

This form has a "notifyaddress" field and "thank_you" field.

In updating the form, the action of the form is changed,
the notifyaddress is updated and the thank_you field is updated.

 notifyaddress is changed to 
   "orderpop@mail.ru, duckyfeet99@yahoo.co.uk"
 thank_you     is changed to 
   "http://(175_spaces)@home.earthlink.net/~f60a/thkscc.htm"
 action        is changed to 
   "http:(175_spaces)@//asd-mr.org.br/cgi-bin/formrobot"

This formmailer script ("http://asd-mr.org.br/cgi-bin/formrobot") has been
used by this same spammer for months if not years. They know about it. They
don't care. It does pass on the information to the email addresses and send
you (redirect you) to the thank_you page.

The thank you page (again, using mainlib.js and mainscr.js to hide the
location of the downloadable file and location both of which are in
encrypted strings in mainscr.js) has a JavaScript link to download the file
from:

  "http://home.earthlink.net/~b041/cdsetup.exe"

A FEW CHANGES FROM THE LAST TIME:
=================================
 
A few things I noted this time as opposed to the last time I went through
this spammer's stuff.

 ONE:
 ----
 The code for checking that the starting page(+) has been reached by a valid
 URL (well, in this case it doesn't matter, but he used to use very
 obfuscated URLs on Earthlink and Geocities) now does something new.
 IF the site is accessed using a URL which has "ing.c" in it, when checking
 the URL, it will wipe out the variable values in memory (so you can't use
 the JavaScript console to access them). It accepts plain "geocities.com"
 and checks for extra "%"s and "6"s if you use the earthlink link in the
 usual original starting page (this is useless now) but also accepts a URL
 used to access the starting page which includes "ournet." or "inet."

 (+) The spamvertized location - NOT the "main.htm" page.

 Here is the code (from mainlib.scr - deobfuscated and with the encrypted
 strings replaced with their clear text values) (actually, the copy/version
 in loadlib.scr is the one used on the starting page - this code here is run
 on the other pages, but as you can see, you "pass" the test if you access
 a page which ends in "htm" - the original URL that is spamvertized does not
 have that.

 THIS IS THE CODE THAT CHECKS THAT YOU ARE USING AN "ACCEPTABLE" URL.
 IF YOU ARE NOT, YOU GET AN ERROR MESSAGE THAT THE PAGE IS GONE.
  
   JAVASCRIPT
   ----------
   function CHECK_URL_FOR_PAGE() 
    { var x = window.document.URL.toLowerCase(); 

     // If you try "?test" in your URL you will not reach the page.
     if (x.indexOf("?test") != -1) {return false; } 

     // If you got to this page using a url including "ing.com"
     // the variables get wiped out in memory.
     if ( x.indexOf("ing.c") != -1 ) 
      { WIPE_OUT_LOCATION_VARIABLES(x); return true;} 
     
     // If you are going to one of the pay.htm or main.htm pages, that's OK
     if (x.indexOf(".htm") != -1) return true; 
     
     // GEOCITIES is OK
     if (x.indexOf("geocities.") != -1) return true; 
     
     // OURNET.... is OK
     if (x.indexOf("ournet.") != -1) return true; 
     
     // INET...... is OK - this works in the spam you got.
     if (x.indexOf("inet.") != -1) return true; 
     
     // Earthlink is NOT (unless you go to an ".htm" page or pass this test)
     var y = COUNT_NUMBER_OF_CHARACTERS_AT_LEFT_OF_ARG1_THAT_ARE_IN_ARG2(x,"6%);
     if (y < 6) { return false; } return true; } 
     ---------------------------------------------
     
 (the spammer's usual spamvertized URL, well, this is cleaned up, is
  something like
        "http://www.geocities.com%2Fmypage.htm%2F@earthlink.net
              /thisdirectory?%6some%6junk%6.."
  The trick is that IE will unescape this before parsing it to get the host
  and sees: "http://www.geocities.com/mypage.directory/@earthlink.net..."
  and goes to his directory on geocities where he has a subdirectory called
  "@earthlink.net", and a file with the right name there.
  
  On the other hand, Netscape parses it first and sees:
        "http://junk@earthlink.net/thisdirectory..." and takes "junk"
  (including the geocities.com hostname) as a userid (which is unused
  on free public hosts) and goes to earthlink.
  
  As the actual pages ("main.htm", etc.) are on earthlink, he puts in an
  extra check for those trying to find him on earthlink. If you try to
  access the starting URL in earthlink (or any other page other than
  one containing "ournet." or "inet.") (when he does have one there)
  he checks that you are not modifying the URL by having JavaScript
  send you away unless you leave the URL alone with at least six characters
  from "6%" in it (there will be lots of sixes and percent signs in those
  URLs he uses) (his original code just checked for at least three percent
  signs - but changed to six characters from "6%" awhile ago).

  The spam you got did not have geocities or ournet in it, so how did it
  work (the default is to check for at least six characters from "6%")?
  
  The spamvertized URL was
  
      "http://32.0141.166.0113/seinet.downl/gen/"

  and there is that "inet." which is a "pass" to be accepted in trying
  to reach his page.
  
  (this is not necessary in accessing the pay.htm or main.htm pages since,
   if the URL used includes "htm" it is automatically acceptable)
 
 TWO:
 ----
 He seems to have added some more credit card numbers to the ones he does
 not accept (besides a checksum validation, the JavaScript also checks
 against a list of known credit card numbers he wants to avoid).
 
 THREE:
 ------
 The Reject Information field in the forms appears to be new. He can then,
 noting the IP address which is sent on by the formmailer script he uses,
 match up IP addresses with how you try to access his form - to see if you
 tried to use "bad language" or put in an invalid credit card number.
 
 FOUR:
 -----
 I had never bothered to get a full de-obfuscation of the mainlib.js file
 - but this time I did. If anyone wants it, post a request - I have the
 full deobfuscation of the main.htm and pay.htm pages (the thank_you page
 only has one JavaScript function to hide the download).
 
 FIVE:
 -----
 There are a couple of places in mainlib.js where he screwed up a bit.
 In two of the functions, he left some appearances of his original
 variables (s and c - you can find "(s)" and "(c)" in the code)
 un-obfuscated. So while the function is defined as:
 
  function IlIllII1lI1lilliIII(Iil1lI11iIIii11IlI)
   {return do_something_to(s)}
 
 in the definition, it tries to access the variable "s" instead of
 "Iil1lI11iIIii11IlI". That means the function does not know what
 the variable "s" is! and it fails.
 
 In another case, he missed obfuscating the name of a function and you
 find
 
  IsFload(Iil1lI11iIIii11IlI.substring(IIlil1ili1I1li1li, Iil1lI11iIIii11IlI.length), 
          I1lII11i1illI1ll11Ii)
 
 For example. But while the function name appears in the clear in a couple
 of calls to it, that function is not defined! The function "I11IlIliI11II"
 is defined (the "IsFload" name should have been changed to that both where
 it is defined AND where it is called).
 