Dark SEO Programming
SEO Tools. I code ‘em.

My last post was a major screw up. I admit it. Maybe I was high, but whatever I posted some shit, someone called me out on it. Ah well, big deal. I post some good stuff I reckon. Totally for free. If you can’t read through some of my bullshit to get to it then I will clean you up the proper info for a small fee of $600. But I guess you’re all just going to have to read my shit along with the good stuff. Am I retarded? Hell yeah. But I don’t give a fuck.

Anyway instead of rebooting your pc everytime you want to compile a program for windows it’s actually possible to compile straight from Linux with wine. This includes ImageMagick programs. Now I’m not sure but I think some other folks have tutorials on similar stuff but it’s a pain to get imagemagick included as well. Here’s how you do it.

Go download dev-cpp we’ll use this as our IDE

Now go get the latest MingW. You’ll know you’ve got the right one because in dev-cpp/bin/ you’ll find a load of same named files as in MinGW/bin/.

Copy the files from MinGW/bin/ over the dev-cpp/bin/ directory. This is basically an update of MinGW. Oh yeah copy over the libraries (lib/) too, I’m pretty sure you need those. Something about gettimeofday() not being present in older versions of mingw.

Download the ImageMagick for MinGW install. It’s listed under the unix binaries but runs on windows. No idea why. Anyway this will install a directory with some libraries in it. Libraries are files that have an .a extension like libMagick.a

Ok right if you’ve done all that you can go ahead and run Dev-Cpp. Like this (Make sure you’ve installed it using wine:

user[~]$ cd .wine/drive_c/Dev-Cpp/

user[Dev-Cpp]$ wine devcpp.exe

and make a commandline C++ project and set the include directory to C:\ImageMagick…\include\ and add these three libraries in this order:

C:/ImageMagick-6.3.7/lib/libMagick++.a
C:/ImageMagick-6.3.7/lib/libWand.a
C:/ImageMagick-6.3.7/lib/libMagick.a

That will now compile perfectly but when it comes to linking it will complain that there is a billion functions missing. That’s because they didn’t include all the other libraries you need. Which is what this tutorial is really about. Basically I went in search of them all and now I’ve got them I’ll zip them up for everyone. The other files you need are (you can probably just paste this into your project properties):

C:/Dev-Cpp/otherlib/libfreetype.a
C:/Dev-Cpp/otherlib/libjbig.a
C:/Dev-Cpp/otherlib/libjpeg.a
C:/Dev-Cpp/otherlib/liblcms.dll.a
C:/Dev-Cpp/otherlib/libpng.a
C:/Dev-Cpp/otherlib/libtiff.a
C:/Dev-Cpp/otherlib/libtiffxx.a
C:/Dev-Cpp/otherlib/libz.a
C:/Dev-Cpp/lib/libgdi32.a

Incidentally Dev-Cpp does come with libgdi32.a, which is handy.

Here’s the libraries. Enjoy.

Other Libraries You Need

All my programs so far in c++ will compile to a windows .exe from linux using this method. I find it handy. Especially as windows refuses to install because linux is on my first hard disk.

I feel like writing right now. Weird. But anyway. Cookie stuffing works. Cookie stuffing is on the limits of even my ethics . Cookie stuffing should be solved. Why don’t the big companies seem to care? Maybe they make too much to even notice, they just factor it in as an inevitable loss with affiliate marketing. On to solving. Cookie stuffing can generally be done two or three ways.

hidden IFRAME

cross-domain browser bug

an image pointing to site with affiliate URL

If there is a cross-domain javascript browser bug then you are fecked. Nothing you can really do to solve that.

Ok so the easy one. An image is the easiest way to cookie stuff, you can do it on any forum, blog, etc. It’s easy. Instant traffic with no work. But. It’s a CSRF (cross-site forgery request)! It simply needs a two-step process from the affiliate merchant’s website. He loads the affiliate url but then on that page is another HTTP request to a token based on the user’s session cookie. Remember we can’t read a cookie and we can’t place a cookie because it’s not on our domain. All we can do is basic HTTP requests. So if the tokenized URL is never loaded then that must mean that page has never been parsed by a browser so we don’t give the user a cookie. Simple.

Ok now before I started writing this I thought the IFRAME method could never be algorithmically detected. You’ve got the obvious checks such as checking referrer URL that sends a bot to make sure the page isn’t breaking rules, but that’s a laborious process. However if I remember correctly according to browser security rules it is ok for an IFRAME to read information about the parent frame from javascript but not the other way around. So if javascript is enabled then it should be easy to check that the page has not been IFRAMED. If it has been IFRAMED that’s a big red flag but I think javascript can also test the IFRAME to make sure it conforms to the rules right there and then.

Cookie stuffing solved. Anybody going to do anything about it?