Divers

20 mars 2019

Short review of the KeyGrabber USB keylogger

Few days ago I've bought a USB keylogger to use on my own computers (explanation in french here). Since then, and as I'm sitting in front of a computer more than 12 hours a day, I've got plenty of time to test it.
The exact model I've tested is the KeyGrabber USB MPC 8GB. I've had to choose the MPC model because both my current keyboards are Apple's Aluminum keyboards. They act as USB hubs, hence requiring some sort of filtering so that the keylogger won't try and log everything passing through the hub (mouse, usb headset, whatever…) and will get only what you type.
My setup is close to factory settings: I've just set LogSpecialKeys to "full" instead of "medium" and added a French layout to the keylogger, so that typing "a" will record "a", and not "q".

First of all, using the device on a Mac with a French Apple keyboard is a little bit frustrating: the French layout is for a PC keyboard, so typing alt-shift-( to get a [ will log [Alt][Sh][Up]. "[Up]"? Seriously? The only Macintosh layout available is for a US keyboard, so it's unusable here.

The KeyGrabber has a nice feature, especially on it's MPC version, that allows the user to transform the device into a USB thumbdrive with a key combination. By default if you press k-b-s the USB key is activated and mounts on your system desktop. The MPC version allows you to continue using your keyboard without having to plug it on another USB port after activation of the thumbdrive mode, which is great. You can then retrieve the log file, edit the config file, etc.
Going back to regular mode requires that you unplug and plug back the KeyGrabber.
Applying the "kbs" key combo needs some patience: press all three keys for about 5 seconds, wait about 15-20 seconds more, and the thumbdrive could show up. If it does not, try again. I've not tested it on Windows, but I'm not very optimistic, see below.

I'm using a quite special physical and logical setup on my home workstation. Basically, it's an ESXi hypervisor hosting a bunch of virtual machines. Two of these VM are extensively using PCI passthrough: dedicated GPU, audio controller, USB host controller. Different USB controllers are plugged to a USB switch, so I can share my mouse, keyboard, yubikey, USB headset, etc. between different VMs. Then, the KeyGrabber being plugged between the keyboard and the USB switch, it's shared between VMs too.
Unfortunately, for an unidentified reason, the Windows 10 VM will completely loose it's USB controller few seconds after I've switched USB devices from OSX to Windows. So for now on, I have to unplug the keylogger when I want to use the Windows VM, and that's a bummer. Being able to use a single device on my many systems was one of the reasons I've opted for a physical keylogger, instead of a piece of software.
Worse: rebooting the VM will not restore access to the USB controller, I have to reboot the ESXi. A real pain.

But in the end, it's the log file that matters, right? Well, it's a bit difficult here too, I'm afraid. I've contacted the support at Keelog, because way too often what I see in the log file does not match what I type. I'm not a fast typist, say about 50 to 55 words per minute. But it looks like it's too fast for the KeyGrabber which will happily drop letters, up to 4 letters in a 6 letters word (typed "jambon", logged "jb").
Here is a made-up phrase I've typed as a test:

c'est assez marrant parce qu'il ne me faut pas de modèle pour taper

And here is the result as logged by the device:

cesae assez ma[Alt][Ent][Alt] rrant parc qu'l ne e faut pa de modèl pour taper

This can't be good. May be it's a matter of settings, some are not clearly described in the documentation, so I'm waiting for the vendor support to reply.

Overall, I'm not thrilled by this device. It's a 75€ gadget that won't work properly out of the box, and will crash my Win 10 system (and probably a part of the underlying ESXi). I'll update this post if the support helps me to achieve proper key logging.

18 mars 2019

Bref, j’ai acheté un keylogger

Avant d'en venir au dispositif qui donne son titre à cet article il me semble important de donner un peu de contexte. Je cherche depuis plusieurs mois maintenant à me procurer un bon et beau clavier mécanique. "Beau" est bien évidemment un critère totalement subjectif, et si "bon" inclue des éléments objectifs comme la solidité, la fiabilité, il intègre lui-aussi des éléments totalement subjectifs.
Ce qu'il y a de merveilleux dans le monde des claviers mécaniques haut de gamme, c'est qu'il est presque possible de faire n'importe quoi : si aucune marque ne propose un clavier tout fait qui vous corresponde, il est presque toujours possible d'en construire un qui répondent à nombre de vos critères. Presque, parce que la France n'est pas tout à fait cœur de cible : trop peu de demande pour susciter une offre variée, me suis-je laissé dire. Aussi le critère "AZERTY" ou ISO-FR est sans doute un des plus difficiles à remplir. Vous trouverez tous les claviers ou jeux de touches en ANSI-US, une portion raisonnable en ISO-UK, ISO-NO, ISO-DE, mais presque aucuns en ISO-FR. Ceux que vous trouverez seront les plus grand public, souvent des claviers de gamer dans des formats réduits comme le populaire TKL ("ten key less"), qui comme son nom l'indique fait l'impasse sur pas mal de touches.
Vortex ViBE © vortexgear.tw Après quelques mois d'étude du marché, de documentation sur les technologies, sur les capacités des claviers, sur les marques et leur réputation, de recherche d'un modèle qui réponde à mes besoins et à mes envies (surtout), j'ai fini par jeter mon dévolu sur deux modèles : le ViBE de Vortex Gear (photo ci-dessus), et le Tab 90M aussi chez Vortex Gear.
Bien sûr, je les veux en ISO-FR : je tape autant de texte que je code ou que je joue. J'ai besoin que mes accents et cédille soient accessibles sans contorsion. Et très honnêtement si je devais changer de disposition de touches j'irais sur un BEPO, pas sur l'archaïque ANSI-US.
J'ai plein d'autres critères que je ne détaille pas ici car ils n'ont aucun lien avec cette histoire de keylogger.
Comme on le remarque rapidement, le Vortex ViBE ne dispose pas de toutes les touches habituelles d'un clavier étendu : exit les flèches, page-down, page-up, etc. Toutes les touches entre le pavé numérique et le bloc de touches principal ont disparu. Par un jeu de combinaison de touches, il est possible d'utiliser le pavé numérique pour jouer le rôle des touches absentes. Dans mon quotidien, je fais un grand usage des flèches de navigation et du pavé numérique. En tout cas c'est ce qu'il me semble. J'utilise aussi les touches de fonctions (absentes sur le ViBE), et les touches "multimédia" du clavier étendu Apple qui est branché sur mes machines au travail et à la maison.
Je tenais donc à évaluer précisément l'usage que je fais de ces touches, histoire de ne pas prendre une trop grosse claque quand le fameux clavier arriverait. Et quoi de mieux pour savoir ce qu'on l'on tape toute la journée qu'un keylogger ? (réponse : rien).
La solution gratuite est assez facile à mettre en œuvre : trouver et installer sur mon poste un keylogger logiciel qui écrit dans un fichier texte tout ce qui passe par mon clavier. Mais cette solution est problématique à plusieurs égards. Notamment j'ai plusieurs machines. À la maison j'ai un OSX, un Windows et un FreeBSD, utilisés via un unique clavier physique au travers d'un switch USB. Il faudrait que je trouve une solution logicielle homogène à installer sur les trois systèmes. Au boulot et bien, juste non. Installer un keylogger logiciel qui pourrait exfiltrer à mon insu mes frappes clavier n'est réellement pas une bonne idée. Par ailleurs une solution logicielle attraperait aussi au vol ce qui sort de mes Yubikeys, et ça non plus ça ne me convient pas.
keygrapper © keelog.com La solution matérielle qui stocke mes frappes clavier en son sein, sans rien faire sortir et qui s'affranchit totalement du système sur lequel est branché le clavier me semble donc la plus sûre à tout point de vue, et la plus adaptée à mes besoins. Bien évidement je me suis assuré que le dongle n'exfiltre aucune données via mes machines. L'exfiltration de données via un réseau hertzien est assez peu probable même si le dispositif semble assez grand pour héberger une SIM et l'électronique nécessaire pour tout renvoyer par SMS. Par ailleurs comme le dongle est branché sur un unique clavier, il m'est toujours possible de saisir des données sensibles via un autre clavier :)
Ceci posé, n'installez pas de keylogger chez vous sans savoir très exactement ce que vous faites et dans quoi vous mettez le doigt.

J'utilise le keylogger matériel depuis quelques dizaines de minutes, mais je vois déjà qu'il me faudra peut être tenter de le régler un peu finement : je tape trop vite pour lui, et pas mal de mots sont tronqués dans la capture. Cela a peut être aussi à voir avec le fait que c'est un modèle spécial supposé filtrer le trafic USB d'un clavier Apple. Les claviers Apple sont des hub USB, et sur le mien j'ai branché un casque/micro USB qui peut donc générer pas mal d'interférences au niveau du dongle qui connecte le clavier au switch USB. Quoi qu'il en soit ce n'est pas un drame puisque ce que je cherche à obtenir c'est une vue statistique de mes frappes, de mon utilisation du clavier.
Petit exemple de ce que cela donne :
[Sh]Parailleur comme le donge est branc sur un uniqu cver, il n[Bck]mest [Bck][Bck][Bck][Bck]e'est
Certains mots sont sévèrement amputés, mais l'esprit est là ! J'espère pouvoir obtenir des statistiques représentatives assez rapidement.

Bref, j'ai acheté un keylogger.

13 mai 2017

Cherche administrateur système

L'université Lyon 2 recherche un admin système H/F. CDD d'un an, renouvelable.
Le profil est détaillé ci-dessous. Si vous avez des questions vous pouvez me contacter.
Envoyez CV et lettre de motivation à la RH Lyon 2

Poste à pourvoir à partir de :	ASAP
Affectation	Direction des Systèmes d’Information
Localisation géographique	Campus Porte des Alpes – Bron
Niveau de rémunération	IGE 2 C échelon 5 – 25,3 K€ brut annuels, avec 55 jours de congés
Niveau diplôme requis	Bac +3 mini en informatique

Mission : Au sein de l'équipe Système du pôle Opérations de la DSI Lyon 2, vous avez en charge l’administration et l’exploitation des infrastructures serveur physique et virtuelle.

ACTIVITES PRINCIPALES :
• Configuration et supervision des systèmes informatiques physiques et virtuels (VMware)
• Exploitation des applications en production à l’université Administration des serveurs (web,
bases de données, messagerie, etc.)
• Collaboration avec le pôle Support, le pôle Etudes, intervenants et fournisseurs
• Participation à l’élaboration de cahiers des charges dans le cadre de nouveaux projets
• Gestion des incidents
• Veille technologique, évolution, et modernisation

Compétences

SAVOIR-FAIRE :
• VMware ESXi / VSphere / VCloud Director Linux (préférentiellement RedHat), FreeBSD est un plus.
• Outils et procédures liés à l’exploitation des services (supervision, sauvegarde...)
• Réseaux TCP/IP
• Script Shell
• Bonnes capacités d'expression, rigueur, et organisation Anglais technique

SAVOIR-FAIRE APPRÉCIÉS :
• Systèmes Windows Serveur et Linux Debian,
• Outils de métrologie, d’analyse et de forensic
• ITILv3
• Postfix, filtrage antispam, Firewall iptables
• Serveurs Apache, Glassfish, Tomcat, nginx,
• SAN/NAS, LDAP, CAS, Shibboleth, Active Directory, Oracle, MySQL

COMPORTEMENTS ATTENDUS :
• Autonome
• Rigoureux
• Capacité à travailler en équipe

Moyens mis à disposition (matériels, humains, financiers)

Le candidat exercera son activité sur le campus Portes des Alpes au sein du pôle "Opérations" (8 personnes) de la D.S.I. (40 personnes).

Contexte de travail

Champs des relations :
• Internes entre les différents pôles de la DSI,
• Externes, pilotage prestataires, fournisseurs.

Spécificités :
Disponibilité éventuelle lors de la fermeture de l’Université.

9 avril 2017

My take on the MySpace dump

About a year ago, a full MySpace data breach dump surfaced on the average-Joe Internet. This huge dump (15 GiB compressed) is very interesting because many user accounts have two different password hashes. The first hash is non-salted, and represents a lower-cased, striped to 10 characters, version of the user original password. The second hash, not always present, is salted, and represents the full original user password.
Hence, the dump content can be summarized by this :

id : email : id/username : sha1(strtolower(substr($pass, 0, 9))) : sha1($id . $pass)

It contains about 116.8 million unique unsalted sha1 hashes, and about 68.5 million salted sha1 hashes.

Of course, people who crack passwords will tell you that the unsalted hashes have no value, because then don't represent real user passwords. They are right. But when you crack those hashes you have a very interesting password candidate to crack the salted hashes. And this is very interesting!

After you cracked most of unsalted hashes, the question is: how do you proceed to crack their salted counterpart? Spoiler alert: hashcat on an Nvidia GTX 1080 is more than 200 times slower than John the Ripper on a single CPU core on this very particular job.

I'm a long time John the Ripper user (on CPU), and I'm pretty fan of it's intelligent design. Working on CPU requires wits and planing. And the more versatile your software is, the more efficient you can be. Hashcat sits on the other end of the spectrum: huge raw power thanks to GPU optimization. But it lacks the most sensible attack mode: "single".

Single mode works by computing password candidates from GECOS data like login, user name, email address, etc. So it makes sense to provide a full password file to JtR, instead of just naked hashes. These passwords metadata are very efficient when you want to create contextual password candidates.
The password retrieved from unsalted hash is more than a clue to retrieve its salted counterpart, in many case it's also the real user password. And when it's not, simple variations handled by mangling rules will do the trick.
You've probably guessed by now: I've created a file where password cracked from non-salted hashes are paired with the corresponding salted hash. The known password impersonate the user login, so that with proper tuning John the Ripper will try only this particular candidate against the corresponding salted hash.
Because of a bug in JtR, I was not able to use this attack on a huge file, I had to split it into small chucks. Nevertheless, I was able to retrieve 36708130 passwords in just 87 minutes. On a single CPU core.
In order to find those passwords with hashcat, I had to rely on a wordlist attack with on a GTX 1080. It took about 14 days to complete. No matter how fast your GPU is (about 1000 MH/s in that particular case), it will brainlessly try every single candidate on every single hash. Remember hashes are salted, so each one requires its own computation. If your file is 60M hashes long, then your GPU will only try 16.6 candidates per second (1000/60). It's very slow and inefficient.

Hashcat performance on a file containing 50% of total hashes.

Sometime, brain is better than raw power. Thank you John ;)

More on this topic:
https://hashes.org/forum/viewtopic.php?t=1715
http://cynosureprime.blogspot.fr/2016/07/myspace-hashes-length-10-and-beyond.html

12 août 2016

Escaping the Apple ecosystem: a view of the setup

Here is a quick & dirty view of the physical and logical setup of my new workstation. The linux part is not finished yet (no drivers for Radeon GPU, thank you Ubuntu), it's a work in progress.

esx
Not depicted: each USB controller sports 4 USB ports (yellow) or 2 USB ports (pink and blue). It allows me to plug few devices that won't be "managed" by the USB switch.
USB devices plugged-in on the switch are made available to only one VM at a time. When I press the switch button, they disappear for the current VM and are presented to the next one.

3 août 2016

Cracking passwords: testing PCFG password guess generator

Cracking passwords is a kind of e-sport, really. There's competition among amateurs and professionals "players", tools, gear. There are secrets, home-made recipes, software helpers, etc.
One of this software is PCFG password guess generator, for "Probabilistic Context-Free Grammar". I won't explain the concept of PCFG, some scientific literature exists you can read to discover all the math inside.
PCFG password guess generator comes as two main python programs: pcfg_trainer.py and pcfg_manager.py. Basic mechanism is the following:
- you feed pcfg_trainer.py with enough known passwords to generate comprehensive rules describing the grammar of known passwords, and supposedly unknown passwords too.
- you run pcfg_manager.py, using previously created grammar, to create millions of password candidates to feed into your favorite password cracker (John the Ripper, Hashcat…).

In order to measure PCFG password guess generator's efficiency I've made few tests. Here is my setup:

Huge password dump, 117205873 accounts with 61829207 unique Raw-SHA1 hashes;
John the Ripper, Bleeding Jumbo, downloaded 20160728, compiled on FreeBSD 10.x;
PCFG password guess generator, downloaded 20160801, launched with Python 3.x;

Here's my methodology:

Of these 61829207 hashes, about 35 millions are already cracked. I've extracted a random sample of 2 millions known passwords to feed the trainer. Then I've used pcfg_manager.py to create a 10 millions lines word list. I've also trimmed the famous Rockyou list to it's 10 millions first lines, to provide a known reference.

Finally, I've launched this shell script:

#!/bin/sh
for i in none wordlist jumbo; do
  ./john --wordlist=pcfg_crckr --rules=$i --session=pcfg_cracker-$i --pot=pcfg_cracker-$i.pot HugeDump
  ./john --wordlist=ry10m --rules=$i --session=ry10m-$i --pot=ry10m-$i.pot HugeDump
done

No forking, I'm running on one CPU core here. Each word list is tested three times, with no word mangling rules, with defaults JtR rules, and finally with Jumbo mangling rules.

Some results (number of cracked passwords):

Rules	PCFG	Rockyou
none	4409362	2774971
wordlist	5705502	5005889
Jumbo	21146209	22781889

That I can translate into efficiency, where efficiency is Cracked/WordlistLength as percentage:

Rules	PCFG	Rockyou
none	44.1%	27.7%
wordlist	57.1%	50.1%
Jumbo	211.5%	227.8%

It's quite interesting to see that the PCFG generated word list has a very good efficiency, compared to Rockyou list, when no rules are involved. That's to be expected, as PCFG password guess generator has been trained with a quite large sample of known passwords from the same dump I am attacking.
Also, the PCFG password guess generator creates candidates that are not very well suited for mangling, and only the jumbo set of rules achieves good results with this source. Rockyou on the other hand starts quite low with only 27.7% but jumps to 50.1% with common rules, and finally defeats PCFG when used with jumbo rules.

On the word list side, Rockyou is known and limited: it will never grow. But PCFG password guess generator looks like it can create an infinite list of candidates. Let see what happens when I create a list of +110 M candidates and feed them to JtR.

Rules	PCFG	Efficiency
none	9703571	8.8%
wordlist	10815243	9.8%

Efficiency plummets: only 9.7 M hashes cracked with a list of 110398024 candidates, and only 1.1 M more when the set of rules "wordlist" is applied. It's even less beneficial than with a list of 10 M candidates (+1.3 M with "wordlist" rules, compared to "none").

On the result side, both word list with jumbo rules yields to +21 M cracked passwords. But are those passwords identical, or different?

Rules	Total unique cracked	Yield
none	6013896	83.7%
wordlist	8184166	76.4%
Jumbo	26841735	61.1%

Yield = UniqueCracked / (PcfgCracked + RockyouCracked)

A high yield basically says that you should run both word lists into John. A yield of 50% means that all pwd cracked thanks to PCFG are identical to those cracked with the Rockyou list.

As a conclusion, I would say that the PCFG password guess generator is a very interesting tool, as it provides a way to generate valid candidates pretty easily. You probably still need a proper known passwords corpus to train it.
It's also very efficient with no rules at all, compared to the Rockyou list. That might make it a good tool for very slow hashes when you can't afford to try thousands of mangling rules on each candidate.

Some graphs to illustrate this post:

every john session on the same graph

every session, zoomed on the first 2 minutes

Rules "wordlist" on both lists of candidates

Rules "none", both lists of candidates

19 novembre 2014

Du SSL gratuit pour tout le monde ?

Let’s Encrypt est une initiative toute récente de Mozilla, Cisco, l'EFF, Akamai, et IdenTrust. Elle vise à permettre à tout webmaster de proposer son site en HTTPS sans surcoût. Il s'agit de proposer aux administrateurs de serveurs web la possibilité d'obtenir gratuitement, automatiquement, et sans contrainte le précieux certificat SSL nécessaire au chiffrement des échanges entre le serveur et les clients. Le certificat sera bien évidemment reconnu nativement dans les navigateurs. C'est en tout cas la promesse du projet. Si cela permet de mettre fin à un racket que je dénonçais il y a quelques semaines, cela lève aussi quelques questions.

Un des principaux arguments des Verisign et autres Thawte pour vous facturer une fortune pour chaque certificat est que la création et le maintient d'une autorité de certification (CA) est extrêmement onéreux. Cela coûte en effet assez cher : les contraintes de sécurité sont immenses, les audits nombreux, etc. En effet la moindre compromission de l'autorité de certification réduit tous les efforts à néant : l'attaquant qui parviendrait à s'infiltrer dans la CA serait capable d'émettre des faux certificats passant pour tout à fait valides dans les navigateurs. Votre belle connexion sécurisée avec "barre verte" pourrait alors être détournée sans que vous n'en ayez conscience (sécurité ≠ confiance).
Mais on le sait ces grosses CA ne sont pas forcément plus fiables que les petites. Elles ne résistent pas forcément mieux aux pressions des agences gouvernementales, ni aux détournements ou piratages. Quelques exemples par ici. Finalement, ce surcoût n'a guère de valeur. Ce qui compte vraiment c'est de savoir si on peut faire confiance à la CA, ou pas.

Dans l'initiative Let’s Encrypt, la question de confiance peut se poser. Je n'ai pas de souci avec Mozilla, et la présence de l'EFF est rassurante. Par contre celle de Cisco m'interpelle. Snowden nous a montré comment la NSA s'amuse à intercepter les livraisons de matériels de cette marque pour caviarder les firmwares et ajouter des portes dérobées. Rien, bien évidement, n'incrimine Cisco directement dans ces magouilles. Néanmoins le doute raisonnable peut naître sur leur degré de connaissance de ces agissements.
Au bout du compte je n'ai pas trop envie de faire confiance à un groupement d'entités sachant que la duplicité d'une seule d'entre elles peut réduire à néant la sécurité des certificats délivrés.

Le protocole proposé (ACME) me laisse aussi dubitatif. J'avoue n'avoir pas lu l'ensemble du brouillon. Je n'ai pas de critique fondée à son encontre mais la débauche d'automatisme (le serveur web qui commande lui même le certificat par exemple) me laisse dubitatif, et je pense que j'attendrai sagement de voir ce que ça donne chez les autres avant d'essayer moi-même.

L'outils lets-encrypt est conçu pour fonctionner assez simplement. C'est sans doute une bonne idée au départ, mais cela laisse peu de maitrise sur le processus. Bien sûr, tout comme le protocole, il faudra attendre de voir ce que ça donne, quelles plateformes sont supportées, quels logiciels aussi. Mettre du SSL dans le web c'est sympa, mettre du SSL dans du mail (smtp, pop, imap) c'est primordial. A priori la première version sera livrée à l'été 2015, donc il reste un peu de temps.

Je souhaite profondément que Let’s Encrypt réussisse son pari. Fournir des certificats SSL reconnus et gratuits, avec des outils simples, basés sur une autorité de certification et sur des protocoles sûrs est un vrai défi.

23 août 2014

L4D2: comparative benchmark between Mac OS X and Windows

Back in december 2012 I've benchmarked (shortly) native and virtualized Mac OS X against virtualized Windows.
Few days ago, I've dedicated a 250G B SSD to a Windows 7 installation, inside my Mac Pro. Weird thing for me to go back and forth between Mac OS X and Windows. I'm more accustomed to +50 days long uptime. Admittedly my various attempts to put Mac OS X into deep sleep, reboot on Windows, and go back later to a fully restored Mac OS X session right out from deep sleep, are failing. That's another story.
Nevertheless, I'm using this Windows system as a playground.

Inside this Mac Pro model 2010, I've one Xeon quad core 2.8 GHz with 24 GB RAM, and a Radeon HD 5770. One SSD is dedicated to Mac OS X 10.6.8, and one SSD is dedicated to Windows 7 Pro 64 bits (with latest stable Catalyst drivers). Both systems are using the latest Steam client with a fully updated and clean Left 4 Dead 2 install.

I've recorded a demo, and played back this file on both systems with identical video settings, recording fps numbers during the playback. The demo is 17827 frames long, and video settings are "MSAA x4", "Anisotropic 8x", "vertical sync triple", "resolution 1920x1200", "shader detail very high', "effect detail high", "model/texture detail high".

The playback is a bit laggy on Mac OS X, especially when the player is looking at fire. It would be playable, but not a very smooth experience. The playback is better on Windows.
Here is the plot of numbers of frames calculated at a given fps rate. For example, on Mac OS X (black line) a total of 4 frames were calculated at a frame rate of 10 fps. On Windows, 90 frames where calculated at a frame rate of 47 fps.

click plot to display full size

Windows 7 has better drivers, and may be the game itself is coded better. The fact is some situations in the game are not handled very well by the GPU on Mac OS X. The huge spike around 30 fps means that ~2500 frames were computed at about 30 fps. Not good. But more importantly the global shape of the plot shows a spread of fps values from as low as 10 fps to 60 fps. Note that the log scale on Y does mask isolated frames (Y=1).
Windows does a better job here, with only a handful of frames below 40 fps.

Fortunately L4D2 is an old game, and my hardware is enough to handle it nicely even on Mac OS X (I usually play at 1600x1000), but being able to push it a little further with full quality on Windows is a nice thing. I hope L4D3 will run ok too, some day, in a not too distant future.

Edit

To complete the comparison, I've made a Cinebench R15 benchmark. The OpenGL score on Windows 7 is ~64 fps, and the same test on Mac OS X 10.6.8 is ~53 fps. On CPU side both OSes score around 440.

Cognitive Overhead

Category Archives: Divers