Posts by GrandAdmiralThrawn

  • der link des tages

    [SecurityWeek] sagt hierzu (unter anderem natürlich) folgendes:


    "It’s worth noting that CacheOut/L1DES attacks require local access to the targeted system and attacks from a web browser are not possible."


    Ich will das jetzt natürlich nicht komplett kleinreden, aber das allein schrumpft die Angriffsfläche schon deutlich zusammen. Bei Spectre war das wirklich beängstigend, da konnte ich tatsächlich per JavaScript innerhalb von weniger als einer Minute im Kontext von Google Chrome dessen gespeicherte Passwörter raussieben.


    Offenbar läßt sich diese Lücke - soweit ich das sehen kann - durch Ausschalten des TSX Befehlssatzes schließen. Das geht, indem man einen neuen Wert des Typs REG_DWORD unter dem Registryschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel anlegt, und diesen auf 1 setzt. Ich schätze danach braucht es noch einen Neustart.


    Das Löschen des Wertes oder das Setzen des Wertes auf 0 macht TSX wieder nutzbar.


    Prozessoren mit Mikroarchitekturen die vor Haswell herausgekommen sind, sollen wohl nicht betroffen sein.

  • x265 Benchmark (kein Schnelldurchgang! 64-Bit manycore und ≥12GB RAM)

    Die geil schrillen Farben immer bei DFI! :topmodel:


    Hatte damals mit Thomsen-XE drüber gesprochen, weil der meinte man brauche den richtigen Chipsatz und die richtige Speicherorganisation. Soweit ich das verstehe, sollte das wohl mit DDR2 gehen, solange der wie folgt organisiert ist: 256MiB × 8 Bits × 2 Ranks. Also 256MiB große Chips mit 8-bit breiter Anbindung, 16 Chips in Summe, 4GiB pro Modul.


    Aber ich hab's selbst nie getestet.

  • x264 Benchmark (kein Schnelldurchgang! 32-Bit multicore und ≥1GB RAM)

    Der Selbstbau hat nur relativ wenig Einfluß. Das hatte ich damals noch getestet, als ich das Ding initial gebaut hatte. Grund dafür ist, daß diese Software Optimierungen nicht nur für deine Host-CPU baut, sondern mittels zur Laufzeit aktivierbarer Codepfade für viele verschiedene CPUs. Selbst eine auf einem Pentium 4 gebaute Version kann also die ganzen Gimmicks eines Haswell Kerns wie etwa AVX nutzen, (fast) ganz so als hättest du direkt am Haswell kompiliert. Die C/C++ Optimierungen sind kaum relevant, weil der meiste leistungshungrige Code in Assembly vorliegt, zumindest auf den modernen x86 CPUs.


    Den meisten Einfluß hat die Verwendung einer neueren Version des Encoders. Bis vor wenigen Jahren hat da noch richtig viel Leistungsoptimierung stattgefunden, kontinuierlich. Erst jetzt sind wir in einer Phase angelangt, wo dahingehend nicht mehr viel weitergeht.


    Die Auswirkungen davon kann man mittels --asm Parameter zur Laufzeit testen. Gebaut werden nämlich immer der C/C++ und der ganze Assemblycode. Man kann einzelne Codepfade selektiv deaktivieren. Man könnte also z.B. AVX oder SSE4.2 ausschalten. Dann läuft für diese Teile statt dessen der Code, den dein C/C++ Compiler ausgespuckt hat, oder es läuft ein anderer Assemblypfad (z.B. SSE2 statt SSE4.1) für gewisse Dinge. Mit --no-asm lassen sich alle Assemblypfade abdrehen, dann rennt das reine C/C++ Kompilat. Von den Entwicklern werden Versionen, die von Haus aus nur auf Basis von C/C++ gebaut werden dann "crippled Build" genannt.

  • Hey all I seek Fraps for Win2k Pro ... all I find are useless x64 versons or broken exe's.

    Very likely, yes. As long as the Themida wrapper's stripped off, the modification could be attempted at least. Themida is not trivial to break however. As far as I understand it (from reading some documentation and a scientific paper about breaking an earlier version of it), this is probably one of the best pieces of software protection on the market.


    I'm not saying it's impossible for a capable reverse engineer, but it's not going to be easy.


    Just for giggles, I tried a cracked version, but it's strange. It seems the crack doesn't require stripping of the Themida protection of Fraps.exe, so it's still active. Plus I cannot possibly redistribute cracked full versions, so that's not gonna lead anywhere anyway, at least not if the registration information is somehow embedded in Fraps.exe.

  • Hey all I seek Fraps for Win2k Pro ... all I find are useless x64 versons or broken exe's.

    It appears my article is wrong. I guess what I had hacked were only fraps32.dll and frapslcd.dll. This however only allows for a working backport to XP. For Windows 2000, the fraps.exe would need to be modified, and hacking the .exe triggers a protection system. They actually packed Fraps 3.5.99 with [Themida]:


    Themida is shielding Fraps.exe against PE32 header manipulation (Crap)



    This is confusing, as I should've stumbled over this before. I either patched the .dll files only, or modern Themida protection was added to Fraps 3.5.99 at a later point in time. Seems unlikely though... Anyway, currently known de-obfuscation code (to break Themida) does not seem to be able to handle this. Must be too new.


    So, no Windows 2000 version of Fraps 3.5.99. Too bad. But I guess 2.8.x is good enough?

  • Hey all I seek Fraps for Win2k Pro ... all I find are useless x64 versons or broken exe's.

    The "not a valid Win32 application" error may indicate a bitness mismatch (e.g. when trying to run a 64-bit tool on 32-bit Windows), but it may also indicate that the application was built with a platform target that is higher than your kernel version. E.g. if I write a program and my Win32 compiler sets this to "NT 6.0", my program will only run on Vista or newer. When you try to run my program on an older OS (Windows 2000 = NT 5.0), you'll get this error as well. The flag can be binary-edited using the tool [CFF Explorer] by NTCore. Here's an example of how to do it: [Link]. In your case, the values you'd need to set in the PE32 optional header are as follows: MajorSubsystemVersion -> 5000 and MinorSubsystemVersion -> 0000.


    This should make the program superficially compatible with Windows 2000. It may still fail in case it calls modern OS functionalities that Windows 2000 does not have of course.


    You may need to do the edit on .exe as well as .dll files of the program, see that link above.


    I only tried this with XP x64, but not with Windows 2000, so I'm not sure if this easy fix works for that OS as well.. The later versions of Fraps should still all be 32-bit (meaning the .exe), but include 64-bit DLLs to hook into 64-bit programs on 64-bit operating systems.

  • Thermaltake Xaser II schwarz

    CPU kann es da nur eine geben (sofern sie auf dem DFI rennt, soll wohl bitchy sein).. Den Pentium 4 Extreme Edition mit 3.2GHz oder noch besser 3.4GHz und 2MiB L3 Cache. Ist einfach die ultimative CPU für diesen Chipsatz. Ich hatte damals, als er neu war den mit 3.2GHz laufen.


    Ist natürlich immer noch Netburst Müll, aber der Gallatin Kern war irgendwie so der Mercedes unter den Northwoods. Nur die Kernspannung solltest besser in Ruhe lassen bei dem Chip...


    Die Raptor hatte ich damals auch drin, aber eine größere, ich glaub' die 150GB war's. Bin nicht mehr ganz sicher, aber die sollte gut passen. Grafikkarte könnte man ruhig eine Generation höher ansetzen, falls man einen Bildschirm mit entsprechender Auflösung dransteckte.


    Natürlich alles nur meine Meinung. ;)

  • x265 Benchmark (kein Schnelldurchgang! 64-Bit manycore und ≥12GB RAM)

    Ich will ja nicht, daß du dich bei der Ausführung des Tests verletzt! :topmodel:


    QX9560 klingt gut, der schwimmt schon ziemlich oben auf!


    Einen Q6600 auf Standardtakt hätte ich irgendwie gerne als Referenzmaschine definiert (Faktor 1.0x), weil diese CPU damals so weit verbreitet war. Aktuell hat der FX-9590 diese Rolle inne, aber der ist dafür nicht so prädestiniert, weil den hatte ja kaum jemand.