Google erkent gevaarlijke bug in cryptomodule Android

Het beveiligingsteam bij Google erkent dat Android kwetsbaarheden bevat in de pseudo random number generator van de Java Cryptography Architecture. Met behulp van een exploit zouden er al Bitcoins zijn geroofd. Honderdduizenden apps zouden de bug kunnen bevatten.

Android-developer Alex Klyubin beschrijft op het Android Developers Blog de kwetsbaarheden in de Java Cryptography Architecture. De randomiserfuncties in de SecureRandom-class zouden onvoldoende sterke willekeurige waarden genereren, terwijl deze noodzakelijk zijn voor taken als het genereren van sleutels en het ondertekenen van bestanden. Ook de zogeheten OpenSSL PRNG-module in Android zou kwetsbaar zijn. De problemen doen zich voor in Android 4.2 en alle lagere versies van Googles mobiele besturingssysteem.

De bugs in de cryptografieonderdelen zijn gevonden nadat criminelen cryptografische sleutels scanden die door Bitcoin-apps op Android waren gegenereerd. Het scanwerk werd uitgevoerd in de zogeheten block chain, waarin alle Bitcoin-transacties continu worden verwerkt. Hierdoor zouden criminelen Bitcoins uit de wallets van enkele gebruikers hebben kunnen roven.

Klyubin stelt dat er inmiddels patches zijn gemaakt waardoor apps op een veilige wijze willekeurige getallen kunnen genereren. De patches zijn geleverd aan Android-fabrikanten. Verder geeft Klyubin aan Android-developers een aantal aanwijzingen hoe zij hun apps moeten aanpassen. Symantec waarschuwt dat misschien honderdduizenden apps kwetsbaar zijn door de bugs in SecureRandom.

Reacties (70)

[Musho]

"De bugs in de cryptografieonderdelen zijn gevonden nadat criminelen cryptografische sleutels scanden die door Bitcoin-apps op Android waren genegereerd."

Ik neem aan dat "genegereerd" "gegenereerd" moet zijn, maar ook dan is deze statement onjuist. Het probleem zat niet zozeer in het genereren van private keys met bijhorende public keys in Android wallets, het probleem zat hem in het signen van transacties.

Het probleem was dat de pseuso random number generator die gebruikt werd in Android soms leidde tot het gebruik van twee keer dezelfde waarde voor de random number parameter k die de elliptic curve signature algorithm nodig heeft om veilig te zijn. Als een transactie twee keer met een private key wordt gesigned met dezelfde waarde k, is het kinderspel om de bijhorende private key te berekenen.

Wat deze criminelen deden, was het scannen van de blockchain naar 2 verschillende transacties die gesigned waren door dezelfde private key, en die door deze bug twee keer dezelfde waarde voor k hadden gebruikt. Vervolgens berekenden ze de bijhorende private key en hierdoor konden zij het geld op dit adres zelf uitgeven en naar een eigen adres sturen.

Bron (uitleg door de ontdekker van de kwetsbaarheid): https://bitcointalk.org/i...831.msg2916589#msg2916589

[Reactie gewijzigd door Musho op 25 juli 2024 10:33]

[Origin64]

Dat er in 2013 ook nog steeds pseudorandom gebruikt wordt voor heel veel encryptie is natuurlijk belachelijk. Hoeveel kost het nou om een RNG mee te bakken in de SoC? Of zit dat er al in en wordt het door devs niet gebruikt?

[Junketsu]

Ja, er is een C++ instructie die RdRand wordt genoemd. Bron: [url=" [url=https://en.wikipedia.org/wiki/RdRand]RdRand[/url]"]Wikipedia[/url] en Intel®.

De implementatie in de processor is er sinds Sandy Bridge bij Intel (2011 dus). Ze noemen dit de Intel® Digital Random Number Generator of de Intel® Secury Key. De handleiding voor de software implementatie kan je hier terugvinden.

Voor AMD heb ik dit niet kunnen vinden.

[Simyager]

Alleen gaat dit over Android en de meeste Androids werken (bijna) allemaal op ARM-cpu. Dus dan zou ARM eentje in moeten implementeren/ontwerpen.

[hardwareaddict]

Alsof er geen gat in de intel hardware generator zou zitten, al dan niet voorspelbare sequencing waarmee een key is gegenereerd.

Over paar jaar 'vindt' zogenaamd iemand dat en dan moet je weer nodig een nieuwe intel chip kopen met een nieuw gat

[Anoniem: 224244]

Het lastige zit 'em in het eerlijk uitschudden als de balans niet op orde is.
vb: 11111111111111101111111111101111111111111111111111110 weer eerlijk verdelen zonder al teveel snij-verlies.

Lees:
http://spectrum.ieee.org/...-randomnumber-generator/0

[Anoniem: 84969]

Een hardware RNG is niet per definitie ook écht random, en ook niet per definitie meer veilig dan een software oplossing.

En als er een bug / veiligheidsprobleem in je chip zit... succes met het patchen.

[Mad-Monkey]

Ik ben de eerste om te zeggen dat ik me verder nog niet hierop heb ingelezen, dus misschien kan iemand met meer kennis mij vertellen of hier nog verdere gevaren aan zitten naast evt. geroofde bitcoins, het verhaal focust hier nogal op, maar dit klinkt breder dan enkel dat.

[OddesE]

Tja als de SecureRandom generator 'willekeurige' getallen genereert die in de praktijk voorspelbaar blijken dan kan er van alles door gecompromitteerd worden. Zo krijg je na inloggen op een website een sessie ID. Dat moet random zijn, want als je die kunt voorspellen dan kun je even zelf inloggen en dan aan de hand van je eigen sessie ID gaan voorspellen wat de volgende sessie ID's gaan worden... En dan staat de deur open voor session hijacking, het kapen van de sessie van een andere gebruiker.

Verder... Tja, meestal als we een random nummer genereren dan moet het ook wel echt willekeurig zijn, dus als dat niet het geval is... Dobbelspelletjes waarbij je kunt voorspellen wat de volgende worp wordt, kaartspellen waarbij je vantevoren de kaart die je gaat krijgen kunt voorspellen e.d.

Dus ja, Bitcoins is inderdaad maar één scenario. Dit is een platform functie waar alle apps last van (kunnen) hebben. Het lijkt me dan ook niet dat afzonderlijke apps bijgewerkt moeten worden, maar dat er echt een update op Android zelf moet komen.

Het beveiligingsteam bij Google erkent dat Android kwetsbaarheden bevat in de pseudo random number generator van de Java Cryptography Architecture.

Wat ik me dan afvraag: Zit deze fout alleen in de Dalvik VM of geldt dit ook voor alle Java applicaties? Waarschijnlijk niet want dan zou Google wel met het vingertje naar Oracle gewezen hebben... Zou dus betekenen dat Google al die Java API's volledig opnieuw geïmplementeerd heeft.... Ik dacht eigenlijk dat ze gewoon OpenJDK opnieuw gecompileerd hadden met de Dalvik compiler...

[Pb Pomper]

Verder... Tja, meestal als we een random nummer genereren dan moet het ook wel echt willekeurig zijn, dus als dat niet het geval is... Dobbelspelletjes waarbij je kunt voorspellen wat de volgende worp wordt, kaartspellen waarbij je vantevoren de kaart die je gaat krijgen kunt voorspellen e.d.

Dat hoeft niet altijd. Vaak wil je juist bepaalde seeds gebruiken om dezelfde random reeks te krijgen. Dat is juist het mooie aan pseudo random numbers, ze zijn niet echt random. Dit kan bijvoorbeeld heel handig zijn als je een simulatie experiment meerdere keren wil laten verlopen. Je wilt dan uiteindelijk toch de resultaten vergelijken tussen de experimenten.

All random number generators zijn niet random omdat ze afhankelijk zijn van het opgestelde algorithme. Random.org komt volgens mij nog het dichtst bij echte random nummers. Al kan je daar ook altijd vraagtekens bijzetten.

[BlackHawkDesign]

Eigenlijk als je wat dieper nadenkt, in hoeverre is random echt random? Als ik een dobbelsteen gooi, dan staat op het moment van gooien in principe al vast wat de uitkomst is. Alleen omdat wij niet in staat te zijn om dat berekenen (zwaartekracht, positie dobbelsteen etc) noemen wij het willekeur. Dus zolang de uitkomst niet van te voren voorspellen is, is het random

[.oisyn]

All random number generators zijn niet random omdat ze afhankelijk zijn van het opgestelde algorithme

Een discreet computer algoritme kan nooit random zijn omdat dat perfect deterministisch is. Maar de stelling dat àlle RNG's niet random zijn is gewoon pertinent omwaar. Quantummechanische processen zijn bewezen willekeurig en onvoorspelbaar. Denk aan het radioactief verval van een atoom, de polarisatie van een foton, etc. Door dat soort bronnen te gebruiken zijn TRNG's (true random number generator) te bouwen. Random.org maakt gebruik van electromagnetische ruis. Waar je wel mee op moet passen is dat er geen systematische afwijking optreedt, waardoor de resultaten niet meer uniform verdeeld zijn. Dat betekent overigens niet dat het niet random meer is. Een dobbelsteen waarbij de 1 iets verzwaard is zal vaker 6 gooien, maar niet altijd. Het is dus nog steeds random - je kunt het resultaat van de volgende worpen niet met 100% zekerheid voorspellen - maar de kansen zijn niet meer gelijk verdeeld.

[Anoniem: 415197]

De vraag is waarom het security-team van google dit niet eerder heeft opgemerkt. Ze zullen toch wel een unit-test hebben die kijkt of de getallen uit die generator voldoende random zijn, zou je zeggen... (?)

[elpino.rv]

Er is een officiële test die aantoont of je algoritme random genoeg is.
Zie FIPS 140-2:
http://csrc.nist.gov/publ...ps/fips140-2/fips1402.pdf

Je moet natuurlijk zelf de test maken, en het komt er in het kort op neer dat je een x aantal seeds (random waardes dus) neemt en opslaat. De FIPS 1402 spec zegt waaraan deze moeten voldoen.

[Barryke]

Goed punt. Stel dat ze die hadden en de unittest code heeft geen bug, kan die unittest misschien gewoon correct gedrag vertoond hebben .. of uit deze bug zich zo niet?

Bijvoorbeeld afhankelijk van hardware, klok en seed waarden, of misschien zelfs de VM waarin dat draait.

[Reactie gewijzigd door Barryke op 25 juli 2024 10:33]

[Blokker_1999]

lol, en hoe ga je willekeur testen? Het punt van willekeur is net dat het niet te voorspellen valt, maar dat wil niet zeggen dat je soms geen keten van willekeurige getallen kunt genereren die een logisch lijstje vormen. De kans dat het gebeurd is uitermate klein maar met echte willekeur kan het wel.

[Anoniem: 109989]

TRN's worden gecreëerd doormiddel van onvoorspelbare Muisbewegingen (Touch pad events), Keyboard events, Laad tijden modules etc, Alle onvoorspelbare timings. normaal word dit gewoon gedaan in java, c etc. De code is zelfs redelijk simpel Daarom vind ik het ook wel verdacht, Google zal niet het eerste Amerikaanse bedrijf zijn zijn die onder dwang van de NSA zijn TRNG heeft moeten aanpassen (Ugh Microsoft) Microsoft moest zelfs een heel stuk code injecteren, Waarvan de Microsoft ontwikkelaars geen enkele zicht hadden wat het deed. Ook raar dat ze er niet eerder achter kwamen aangezien er veel manieren zijn om vast te stellen hoe random bepaalde informatie is.

[Reactie gewijzigd door Anoniem: 109989 op 25 juli 2024 10:33]

[daan.timmer]

Het is jammer dat er geen RNG's gemaakt gebruikt worden d.m.v. een hardware matige implementatie.

zo zijn er verschillende (simpele) hardwarematige implementaties mogelijk. Twee voorbeelden:

Clock drift: http://en.wikipedia.org/w...ber_generator#Clock_drift

Random ADC waardes d.m.v. noise generators:
http://en.wikipedia.org/w...quantum-random_properties

[Reactie gewijzigd door daan.timmer op 25 juli 2024 10:33]

[.oisyn]

Het is jammer dat er geen RNG's gemaakt gebruikt worden d.m.v. een hardware matige implementatie.

Intel Core processoren vanaf Ivy Bridge hebben gewoon een built-in rnd instructie genaamd RDRAND, die cryptografisch secuur is. Da's een digitale RNG die gebruik maakt van entropie uit een echte random bron.

Achtergrond

[Reactie gewijzigd door .oisyn op 25 juli 2024 10:33]

[.oisyn]

Wat mogen ze niet? Een RNG inbouwen in hardware? Ze maken geen van allen hardware (geen chips iig). En waarom zouden ze het niet mogen?

Verder zitten in al die OS'en een vergelijkbare oplossing die gebruik maakt van entropie van gebruikersinvoer en hardwaretimings. Minder efficient dan Intel's oplossing maar daarom niet minder effectief.

Heb je eigenlijk überhaupt enig idee waar je over praat?

[Reactie gewijzigd door .oisyn op 25 juli 2024 10:33]

[daan.timmer]

Intel Core != SOC in een smartphone? En het gaat hier over een smartphone.

[.oisyn]

Dat snap ik ook wel, ik geef slechts aanvullende informatie dat dat soort dingen dus tegenwoordig ook op moderne desktop cpi's zitten. Het zal niet lang meer duren of je gaat dergelijke ontwikkelingen ook in mobiele SoC's zien lijkt me.

[Anoniem: 109989]

Word ook wel gebruikt maar het nadeel is dat je dan wel de chip fabrikanten moet kunnen vertrouwen. Dat is de reden dat goede TRNG gebruik maken van een pool doormiddel van entropy te verzamelen van zoveel mogelijk verschillende sources. Zodat als er 1 gemanipuleerd is er nog steeds voldoende entropy is.

[Reactie gewijzigd door Anoniem: 109989 op 25 juli 2024 10:33]

[Rafe]

Wat ik me dan afvraag: Zit deze fout alleen in de Dalvik VM of geldt dit ook voor alle Java applicaties?

Geen van beiden: Android gebruikt delen van Apache Harmony voor de class library ipv die van OpenJDK.

Wat meer detail dan in het nieuwsartikel, correct me if I'm wrong: de Android-implementatie van de PRNG bevat kwetsbaarheden. Die PRNG is beschikbaar volgens volgens de principes van de JCA, die ten doel stelt cryptofuncties beschikbaar te stellen op een uniforme wijze voor verschillende Java-implementaties.

[SidewalkSuper]

Alle apps met cryptografische onderdelen die volgens een PRNG gedaan worden zijn hierdoor kwetsbaar. Cryptografische sleutels die momenteel worden aangemaakt zijn niet veilig en kunnen gekraakt worden. Er zijn talloze apps die daar een update voor moeten doen.

In feite heeft Google hiermee eenzelfde probleem als Sony had met de PS3 beveiliging. Eén van de hackers, van de PS3 destijds, postte een aantal dagen geleden dan ook dit op zijn Twitter.

Héctor Martín ‏@marcan42 11 Aug
When SecureRandom is neither secure nor random, you're gonna have a bad day.
9:47 PM - 11 Aug 13 · Details

https://twitter.com/marcan42/status/366647075477258240

Mensen die via een Android app Bitcoins hebben overgemaakt doen er ook goed aan om met een update van die app of op een normale computer die Bitcoins nogmaals een keer heen en weer te sturen tussen eigen accounts om zo correcte cryptografische sleutels te krijgen. Dan is dat geld weer veilig.

Deze cartoon is ook gelijk weer van toepassing.
http://xkcd.com/221/

[Reactie gewijzigd door SidewalkSuper op 25 juli 2024 10:33]

[Jazco2nd]

Apps worden continu geupdate, vaak ivm de adserving/adtracking code die erin zit. Dus ff hier een fix voor inbakken en updaten lijkt me geen big deal voor app developers.

[johnkeates]

Eeh, nee. Volgens mij snap je niet helemaal hoe programmeren werkt.

De developers gebruiken een SDK om software te ontwikkelen. Die SDK linkt hun software met bibliotheken die gebruikt worden in het OS.

Om deze fix te kunnen gebruiken moet je de bibliotheken fixen, en dat kan alleen in het OS en/of de SDK.

In theorie zou je je eigen libs kunnen gebruiken en die met je app meeleveren, maar volgens mij kan een aantal van de libs en/of modules alleen in kernel-space draaien, en dat kan op android niet zomaar zonder android aan te passen.

[Rutix]

Er is een workaround om het te fixen zonder de bibliotheken te fixen. Als je namelijk de PRNG expliciet initialized met entropy van /dev/urandom of /dev/random ben je niet vatbaar voor de exploit. Er is ook wel een patch gereleased voor de bibliotheken maar als je zeker wilt zijn dat je app niet vatbaar is dan implementeer je toch even die workaround want dat kan nooit kwaad.

[Reactie gewijzigd door Rutix op 25 juli 2024 10:33]

[djwice]

Wikipedia geeft aan dat je beter /dev/random kunt gebruiken dan /dev/urandom :

While it is still intended as a pseudorandom number generator suitable for most cryptographic purposes, it is not recommended for the generation of long-term cryptographic keys.

de reden hiervoor is

the output may contain less entropy than the corresponding read from /dev/random

Je schreef:

die workaround want dat kan nooit kwaad.

Daar ben ik het niet mee eens, aangezien je ook naar /dev/random kunt schrijven, kan je programma kwetsbaar worden als door een bug het mogelijk is de ioctl uit te voeren. Je kunt dan als kwaadwillende de /dev/random ruimte vullen en de entropie estimate aanpassen.

Je moet dus altijd blijven monitoren welke fouten er gevonden worden en patches voor situaties als hierboven klaar hebben liggen, zodat je die direct kunt pushen naar je gebruikers.

[Reactie gewijzigd door djwice op 25 juli 2024 10:33]

[Tozz]

Helaas is /dev/random niet echt een optie, omdat /dev/random blocked als de entropy op is. In andere woorden, je App(licatie) zal dan blocken totdat er weer entropy beschikbaar is. Afhankelijk van hoeveel random nummers je nodig hebt en hoeveel zaken er draaien die entropy genereren kan dat best wel lang duren. Ik vermoed dat Android het ophalen van random nummers uit /dev/random ook toestaat in de UI thread, waardoor het lijkt alsof de applicatie vast loopt.

In de praktijk is daarom eigenlijk alleen /dev/urandom geschikt.

[Jeanpaul145]

Ik ben dan nieuwsgierig: wat belet je om de /dev/random read in een aparte, non-UI thread te doen?

[Mentalist]

Misschien het feit dat je dan nog steeds geen random data hebt en hoewel de UI responsive blijft je om onduidelijke redenen niet verder kan met het programma?

Ik heb het even getest op mijn desktop:

cat /dev/random > random.blaat & sleep 10 && killall cat

Geeft me een bestandje met 41 bytes random rommel. "Dat is dan dus zo ongeveer deze tekst." (inclusief de aanhalingstekens, die tekst is 41 bytes groot en de kans dat je precies die tekst krijgt als output van /dev/random is kleiner dan 1 op tien miljoen miljard)

Vervolgens:

cat /dev/urandom > urandom.blaat & sleep 10 && killall cat

geeft me een bestand met 60030976 bytes (57,2MiB) aan random rommel ofwel 1464170 keer zoveel. Daar kan je dus heel snel sleuteltjes mee maken. Gebruik je /dev/random, dan kan het zomaar minuten duren voor de sleutelgeneratie gedaan is.

Als het goed moet gebeuren zou je haast denken dat je het beter serverside kan doen, die kan het wel snel..

[[Yellow]]

Dan nog ben ik het met JeanPaul145 eens: waarom (en hoe vaak) zou je crypto kwaliteit random nodig hebben in je UI thread?

/dev/urandom is goed genoeg voor de meeste random zaken en is prima te gebruiken in de UI thread.

Je crypto random zou je alleen nodig moeten hebben als je zaken als een nieuwe key moet genereren (sessie of anderszins) en moet je zoveel mogelijk op de achtergrond doen.

[Anoniem: 80466]

Ik vind dit anders misschien nog wel zorgwekkender als security issue:

http://www.theguardian.co...2013/aug/13/chrome-google

[Anoniem: 390875]

Een systeem waarbij je zelf de browser instrueert om wachtwoorden op te slaan waarbij deze wachtwoorden vervolgens te bekijken zijn als je fysiek toegang hebt tot de computer in een onbewaakt moment (of er allereerst in slaagt malware te installeren dat muis/kb commando's verstuurt) en wat je eenvoudig kan voorkomen door wachtwoorden niet meer op te slaan of op FireFox (met master pw) of Safari over te stappen, of de computer te vergrendelen in onbewaakte momenten, en waarvoor met enig geluk na de media aandacht een update beschikbaar gesteld wordt wat vervolgens standaard overal geïnstalleerd zal worden.

vs

Een systeem waar je nul komma nul de contrôle over hebt, waarbij je - zeker als leek - niet eens door hebt dat het gebruikt wordt, waarbij iemand niet eens toegang tot jouw device nodig heeft in het geval bepaalde resultaten van encryptie publiek toegankelijk zijn, en waar je ook zelf niets tegen kan doen behalve naar iPhone, Windows Phone, of ander hardware platform danwel een compleet ander OS op je Android phone te zetten*, en waarvoor waarschijnlijk wel snel een security update beschikbaar zal zijn maar je eerst maar af moet wachten wanneer, of zelfs maar OF*, de fabrikant van jouw mobieltje die update beschikbaar gaat stellen, waardoor een groot deel gewoon deze bug blijft behouden.
( * sommige mobieltjes kunnen die immers niet draaien, ook Android 4.3 zelf niet, en ook niet via zegge een CyanogenMod - althans niet met verlies van bepaalde features met dank aan niet beschikbaar zijn van open drivers/tech specs voor de hardware. )

Nee, je hebt gelijk, die eerste is echt veel zorgwekkender. Maar alleen omdat Google stelling tegen een master password heeft genomen. Ironisch, aangezien ze maar al te graag zien dat je je Google account als 'master password' voor vele sites gebruikt - maar daar zit voor hen dan ook geld in, in een master password voor je site wachtwoorden niet.

[Anoniem: 133456]

Een non-issue lijkt me. Precies zoals de eerste comments op dat artikel al zeggen. Zoiets als. Hoeveel spullen kunnen dieven uit je huis halen als je de voordeur open laat en even boodschappen gaat doen.

[azerty]

Als de smartphone fabrikanten dit even snel uitrollen als met gewone android releases kan het nog een tijdje duren tegen dat het meeste gevaar geweken zal zijn...

[Mr_gadget]

Vraag me af of dat überhaupt gaat gebeuren. Heb het idee dat bij een hoop telefoons de support gewoon helemaal gestaakt wordt na 2 jaar. Terwijl dit echt wel een gevaarlijk probleem is, Google zou ze eigenlijk moeten verplichten updates te maken.

En de klanten bereiken is ook wel lastig, ik vind de communicatie over de updates zowieso nooit zo briljant.

[TheGhostInc]

Google zou ze eigenlijk moeten verplichten updates te maken.

Google is alleen verantwoordelijk voor de Nexus telefoons & Google Apps, alle andere dingen zijn simpel weg niet van Google. Kijk ook maar eens op de site hoe ze erin staan.

Overigens vermoed ik dat veel leveranciers een patch zullen uitbrengen die deze kwetsbaarheid oplost. Daarvoor hoef je niet naar 4.3 over te stappen.

[Prulleman]

De problemen doen zich voor in Android 4.2 en alle lagere versies van Googles mobiele besturingssysteem.

letterlijk kan je hier uit afleiden dat 4.3 hier dus geen last van heeft, maar toch twijfel ik hier ergens aan... zo groot zijn de verschillen niet tussen 4.2 en 4.3
wellicht hebben ze 4.3 gewoon helemaal niet in dit onderzoek meegenomen.. ook vreemd dat ze niet letterlijk vermelden dat het in 4.3 is gefixed,

[SidewalkSuper]

Volgens een beveiligingsonderzoeker die met Ars Technica heeft gesproken doet het probleem zich inderdaad in alle versies van Android voor.

Contrary to many earlier reports, the flaw affects all versions of Android not just 4.2 and earlier, Android Security Engineer Adrian Ludwig told Ars.

http://arstechnica.com/se...ed-in-5700-bitcoin-heist/

[Prulleman]

ah, thanks, die had ik nog niet gezien. Mooi gecommuniceerd dan.. en dat van google zelf..

[Anoniem: 120539]

En nu maar afwachten totdat deze kwetsbaarheid door alle vendors is verwerkt...
M.a.w.: een open platform is mooi, maar door de differentiatie die daardoor optreedt is het uitroeien van een mogelijk kritiek probleem lastig.

[skatebiker]

Als je geroot bent kun je dan niet simpel de library vervangen met de gepatchte versie ?

[daft_dutch]

ik moet meteen aan dilbert denken
http://dilbert.com/strips/comic/2001-10-25/

[Reactie gewijzigd door daft_dutch op 25 juli 2024 10:33]

[3dfx]

En daardoor moet ik weer denken aan de duitse variant van die number generator:

http://www.youtube.com/watch?v=1MLry6Cn_D4