Shared Secrets

Door Sgreehder op dinsdag 16 april 2013 15:59 - Reacties (1)
Categorie: Perpetuum, Views: 2.579

Zoals beschreven in een vorige blog, worden via mijn Perpetuum-client wat gegevens verzameld die worden doorgezet naar mijn website, zodat spelers niet hoeven te zijn ingelogd om te zien wat er zoal in het spel omgaat. Inmiddels heb ik deze informatie uitgebreid. Het gaat nu om:

• Conversaties in-game channels en IRC
• Notificaties in-game channels en IRC (dit bestaat met name uit inloggen/uitloggen)
• Intrusion events (dit zijn de tijden dat player-owned outposts kwetsbaar zijn geweest en wie aanspraak heeft gemaakt op een toekomstige overname)
• Wallet-transacties

Het mag duidelijk zijn dat ik nu kan volgen wie aan mij (in-game) geld stuurt. Ik wil dit doorzetten naar een systeem waarmee in-game geld kan worden overgezet naar de website, om 'premium'-diensten af te nemen (wat dit precies gaat inhouden moet ik nog vorm geven), maar ook om leukigheidjes (zoals een lotterij) makkelijker te kunnen realiseren.

Met dat soort faciliteiten begint het dus ook interessanter te worden om misbruik te maken van de website. Het systeem wat ik gebruik om de gegevens door te zetten is momenteel gebaseerd op een POST request via cURL. Een IP-check lijkt mij in elk geval niet betrouwbaar genoeg om na te gaan of nieuwe data daadwerkelijk van mijn computer afkomt. Een mogelijkheid is HTTP basic access authentication, maar ik gebruik momenteel shared-hosting waarbij SSL niet mogelijk is, dus waterdicht is het dan zeker niet. Er is gelukkig een goed alternatief: keyed-hash message authentication code, of HMAC.

HMAC functioneert op basis van een hash-algoritme (zoals SHA512), waarmee de te sturen data in combinatie met een 'shared secret' (een sleutel) kan worden gehashed naar een MAC (message authentication code). De server ontvangt daarop de data met aantekening (signature), en vergelijkt de MAC op basis van de gedeelde sleutel. Als deze hetzelfde is, wordt de data goedgekeurd voor verwerking.

Het versturen van de data:


code:
1
2
3
4
5
$data = serialize($transfers);
$hmac = hash_hmac('sha512', $data, $sharedSecret);

curl_setopt($ch, CURLOPT_URL, $transfersUpdateURL . '&sign=' . urlencode($hmac));
curl_setopt($ch, CURLOPT_POSTFIELDS, ('transfers=' . urlencode($data)));



En het controleren van de afkomst aan de andere kant:


code:
1
2
3
4
5
$signature = isset($_GET['sign']) ? $_GET['sign'] : '';
$hmac = hash_hmac('sha512', $_POST['transfers'], $config['shared-secret']);
if ($hmac !== $signature) { 
    exit;
}



De voornaamste kwetsbaarheid tegen HMAC is een brute-force aanval (met de lengte van de keys al een aardige opgave op zichzelf), maar dit kan eventueel eenvoudig worden opgelost met een SSL-verbinding.

Livestream 'coding jam'

Door Sgreehder op zondag 14 april 2013 14:38 - Reageren is niet meer mogelijk
Categorie: Perpetuum, Views: 1.828

Vandaag (de zon laat zich nog niet zien) ga ik mij bezig houden met het ontwikkelen van extra functionaliteit voor mijn 'third-party' website die is gebouwd rond het spel Perpetuum. Ik vind het zelf altijd interessant om livestreams te zien van coding jams e.d., dus waarom het niet zelf doen?

Het is de bedoeling naar het volgende toe te werken:
• agents verifieren via een in-game channel, zodat de site zeker weet dat een bepaald account op de site ook correspondeert met een in-game account gelukt!
• commentaar op het killboard
• de mogelijkheid in-game geld te sturen naar de site, hoofdzakelijk om onzinnig commentaar op het killboard te elimineren (alleen directe betrokkenen kunnen 'gratis' commentaar leveren)

De stream:

http://www.twitch.tv/sequer_doek

De website:

http://sequer.nl/

Het spel:

http://perpetuum-online.com/

Logs theft met PHP/MySQL

Door Sgreehder op vrijdag 5 april 2013 16:45 - Reacties (2)
Categorie: Perpetuum, Views: 2.402

Voor Perpetuum, een sandbox-MMOG, heb ik een stapel scripts ontwikkeld om berichten van in-game chatkanalen te pushen (dmv. long polling) naar bezoekers op een website. Op deze website heb ik, naast deze tool, een selectie van hulpmiddelen voor dit spel geplaatst.

Allereerst even wat over Perpetuum. Op de oppervlakte is deze 'Hungarian-made' MMOG behoorlijk vergelijkbaar met EVE Online, met het duidelijk verschil dat het om 'robots op eilanden' gaat. Ook in Perpetuum is het een kwestie van een paar korte tutorials afwerken, en daarna mag je het zelf allemaal bekijken. Robots zijn modulair opgebouwd, en ook de overview op de UI is vertegenwoordigd. Zoals in EVE is de markt grotendeels gevuld met producten van andere spelers, maar de lage populatie (ik vermoed zelf rond de 500-600 actieve spelers) en producenten die alleen actief zijn binnen corporaties/coalities zorgen voor een wat karig aanbod.

De verschillen zijn ook opvallend; het approach/orbit-patroon is vervangen door een WSAD-patroon, skills (hier: extensions) kunnen selectief worden opgewaardeerd (achteraf vergelijkbaar met Dust, grappig genoeg), en PVP is snel en heeft opvallende kenmerken (zo kan dicht op elkaar vechten tot gevolg hebben dat sensoren flink worden verstoord en een ontploffing kan een kettingreactie veroorzaken die een hele groep kan vernietigen).

Goed, de Perpetuum-client kan dus een log bijhouden van open chatkanalen. Daarnaast zijn de Perpetuum-servers zo goed als 24/7 online (geen downtime, behalve voor patches), en de client duldt langere periodes van inactiviteit van de spelers. De berichten worden direct bijgeschreven in een bestand (per kanaal), dus het was voor mij zaak te beginnen met een tail -f implementatie voor Windows, die nieuwe berichten kan doorsturen (met behulp van een POST request bijvoorbeeld) naar de website. Hoewel het mogelijk kan met een wat losse applicaties en een pipe in PowerShell, leek het me toch handiger dit met een PHP CLI-applicatie te doen. Deze kan dan in een loop werken en om de paar seconden de bestanden pollen voor veranderingen, en gelijk wat PCRE en Purificatie toepassen.

De code van een tail implementatie in PHP (van dit voorbeeld):


code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
function tail($filename, $lines = 10, $buffer = 4096) {
        
    $f = fopen($filename, "rb");
    fseek($f, -1, SEEK_END);
    if(fread($f, 1) != "\n") $lines -= 1;
    
    $output = '';
    $chunk = '';
        
    while(ftell($f) > 0 && $lines >= 0) {
        $seek = min(ftell($f), $buffer);
        fseek($f, -$seek, SEEK_CUR);
        $output = ($chunk = fread($f, $seek)).$output;
        fseek($f, -mb_strlen($chunk, '8bit'), SEEK_CUR);
        $lines -= substr_count($chunk, "\n");
    }
    
    while($lines++ < 0) {
        $output = substr($output, strpos($output, "\n") + 1);
    }
        
    fclose($f);
    return $output;
}



Het CLI-script stuurt in het geval van nieuwe berichten een POST-request naar de webserver, die deze in een database opslaat en de laatste 15 berichten per kanaal wegschrijft naar een filesystem.

Op de website zelf wordt javascript geserveerd met herhalende asynchronous requests (met een lange time-out) naar een long polling script, vergezeld met een 'since' parameter. Mochten er dus nieuwe berichten zijn, dan kunnen deze direct worden doorgezet, anders blijft het script om de paar seconden het filesystem op wijzigingen pollen. Dit script draait voor maximaal 30 seconden (vandaar 'long polling'), waarna de browser simpelweg een nieuwe request verstuurt.

Het resultaat:

http://sequer.nl/?a=chat-default