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).