|
|
|
|
|
|
|
|
willste cheats fürs CS:GO Linux basteln?
|
|
|
|
|
|
|
|
|
|
|
http://github.com/enkore/with_smaa
LD_PRELOAD gesetzt <=> kein VAC*
Und z.B. Minecraft ignoriert LD_PRELOAD völlig (liegt nicht an Java/LWJGL, woanders funzt es).
* oder es gibt grundsätzlich kein VAC, wenn man TF2 von der Kommandozeile startet. Das weiß ich nicht. Steam hat arge Probleme mit meinem Preload-Shim, ein Hintergrundprozess scheint Steam dann immer wegzusterben, worauf Steam quasi permanent in einen 2-3 Sekunden Timeout hängt.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 11.11.2014 19:35]
|
|
|
|
|
|
|
|
|
|
du willst vielleicht das steam overlay zeugs abschalten.
|
|
|
|
|
|
|
|
|
|
|
Jain, mein Problem ist eine Ebene tiefer.
TF2/Source lädt die libGL.so explizit. Daher sieht TF2 das glXSwapBuffers aus meinem LD_PRELOAD-Shim nicht.
Daher mache ich als Gegenmaßnahme folgendes:
| |
| Code: |
void *__libc_dlsym (void *, const char *);
void *dlsym(void *handle, const char *name)
{
if(!real_dlsym) {
fprintf(stderr, "with_smaa: Getting real dlsym...\n");
void *libdl = dlopen(lib_path("libdl.so"), RTLD_NOW);
real_dlsym = __libc_dlsym(libdl, "dlsym");
fprintf(stderr, "with_smaa: real_dlsym=%p\n", real_dlsym);
}
if (!strcmp(name, "dlsym")) {
return (void*) dlsym;
} else if(!strcmp(name, "glXGetProcAddressARB")) {
fprintf(stderr, "with_smaa: dlsym: redirecting glXGetProcAddressARB\n");
return (void*) glXGetProcAddress;
} else if(!strcmp(name, "glXGetProcAddress")) {
fprintf(stderr, "with_smaa: dlsym: redirecting glXGetProcAddress\n");
return (void*) glXGetProcAddress;
} else if(!strcmp(name, "glXSwapBuffers")) {
fprintf(stderr, "with_smaa: dlsym: redirecting glXSwapBuffers\n");
return (void*) glXSwapBuffers;
}
return real_dlsym(handle, name);
} |
|
Das funktioniert.
Nächster Schritt: LD_PRELOAD für Steam setzen, damit es übers Environment bei TF2 ankommt und ich auch online spielen kann.
Problem: __libc_dlsym scheint nicht 100 % das gleiche Verhalten wie dlsym zu haben. Ich vermute mal, dass dlsym sich irgendeinen glibc-internen Lock holt und erst dann eine interne Funktion aufruft, die ich hier als __libc_dlsym oder auch _dl_sym oder so sehen kann. Das verursacht m.E. die Crashes und Probleme mit Steam (oder vll. auch die Race-Condition zu real_dlsym, aber da müsste schon ein Funktionsaufruf während real_dlsym geschrieben wird stattfinden, und dafür ist mir das zu reproduzierbar), denn: wenn ich alles rauskommentiere was danach kommt und nur noch real_dlsym aufrufe, bestehen die Probleme. Nehme ich es ganz raus: Läuft 1a.
Ich sehe also ca. folgende Problemlösungen hier:
a) dlsym nicht überschreiben und stattdessen per Code-Injection in den Tabellen im Speicher der libGL.so rumstochern. Das könnte funktionieren.
b) Code-Injection, glXSwapBuffers in der libGL finden und durch JMP zu meinen glXSwapBuffers ersetzen. So wie Detours das unter Windows macht. Das funktioniert garantiert, egal auf welche der (mindestens) drei Methoden die Zielanwendung an den Funktionspointer zu glXSwapBuffers kommt.
Für b) möchte ich gern eine Library haben, damit ich da nicht selber Assembler-Code schreiben muss. Weil das garantiert schief geht 
Unabhängig davon habe ich noch eine Blacklist, wo basename(readlink("/proc/self/exe")) mit abgeglichen wird (und dann "steam" drin steht), weil SMAA auf eine GUI echt Scheiße aussieht.
/e: Ach was soll der Geiz, ich wrappe einfach (fast) alles in dlsym in einen globalen Mutex. Wenn's dann noch Probleme gibt, habe ich ein ganz anderes Problem.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 11.11.2014 20:59]
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Bei Archlinux muss man keine Mailinglisten lesen, alles notwendige sagt einem Pacman oder die Website.
| |
"Mailinglisten" war selbstverständlich eine Überspitzung von "man muss _überhaupt_ etwas lesen bevor man sein System gefahrlos updaten kann: wtf." Ich bin mir aber sicher, dir war das vollkommen klar und du hast nur neben der bequemen Abkürzung über meine Wortwahl keinen anderen Weg gesehen, um diese irrsinnige Praxis zu rechtfertigen. Und damit zurück ins Studio.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ist nicht so dramatisch, keiner nutzt windows und es ist karneval. 
|
|
|
|
|
|
|
|
|
|
|
Und das betrifft auch nur alles seit 2003. 
|
|
|
|
|
|
|
|
|
|
|
Hat jemand das Bild mit dem Chemiehund und "I have no idea what I'm doing"?
(Immerhin, er kommt bis _abs, dann crasht er natürlich, weil _real_abs nix gibt ; ich hab keine Ahnung wie ich da drumherum arbeiten soll. Plus, ich habe fast keine Ahnung von x86 Assembly, plus ich weiß nicht, wie Calling Conventions funktionieren. Ich glaube, ich geh lieber wieder Detours-artige Bibliotheken für Linux googeln.)
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 11.11.2014 23:06]
|
|
|
|
|
|
|
|
|
Sollte ich jemals meinen Abschluss bekommen, ziehe ich ernsthaft in Erwägung mit sowas auf einem T-Shirt bei der Verleihung aufzukreuzen:
e: Detours? Oui! Leidensgenosse. Nur dass ich das für Windows stricken darf. Mag mir jemand sagen, warum:
IoCreateDevice(...) für \\.\TestDriver klappt, winobj auch das Device zeigt aber dessen Eigenschaften nicht anzeigen kann, weil die angegebene Datein nicht gefunden werden kann. Die Userland-App sagt auch, dass CreateFile(..., \\.\TestDriver, ...) fehlschlägt weil es die Datei nicht gäbe?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von teK am 11.11.2014 23:13]
|
|
|
|
|
|
|
|
|
Für Windows gibt es immerhin ziemlich viele brauchbare Detours-Implementierungen. Für Linux finde ich einfach... gar nüscht. Außer besagtes baiduhook, was aber zum einen C++ ist und ich zum anderen nicht ans Laufen kriege.
Ich mein, ich kann doch schlecht der einzige sein, für dessen Anwendung LD_PRELOAD zu schwach ist?
Zu meinem Problem von oben ("wie rufe ich denn jetzt die Originalfunktion auf, wenn ich sie mit meinem PUSH/JMP überschrieben habe?"):
- Wenn der Originalcode mit -fPIC kompiliert wurde, dann müsste der doch auch noch funktionieren, wenn ich den $sonstwo hinkopiere, oder? (Knackpunkt!) (e: Aha, PIC scheint sich mehr auf das Objekt/Image als ganzes zu beziehen und nicht auf eine einzelne Funktion. Tja, dann äh, muss ich den Anfang der Funktion disassemblieren(!), die would-be-überschriebenen Opcodes irgendwohin kopieren, PUSH/RET auf die Originalfunktion + Offset vom letzten geretteten Opcode machen?)
- D.h.: ELF der .so lesen, Funktion im Image nach der gehookten Funktion raussuchen
- Speicherblock passender Größe besorgen
- memprotect
- Funktion rüberkopieren, Pointer merken
- Im Hook: Pointer zu C-Funktionspointer casten, aufrufen
(e: In x64 mache ich PUSH <imm64> / RET fürs Trampolin, in x86 kann ich das einfacher haben mittels JMP <imm32>, oder?)
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von csde_rats am 11.11.2014 23:28]
|
|
|
|
|
|
|
|
|
Nein, ich bin schlechter dran 
Viel Erfolg noch.
|
|
|
|
|
|
|
|
|
|
|
Ah.
Mir ist die Idee gekommen: Die ersten paar Instruktionen so einer Funktionen gehören ja zur ABI und sind damit durch ABI und Signatur eindeutig bestimmt. Also brauche ich nix zu disassemblieren, man schaut nur einmal mittels objdump* nach, wie die ersten paar Instruktionen (ich brauche ja nur 10 Byte) aussehen und packt die als Array in den eigenen Quellcode. Davor noch den absoluten Sprung, den Kram in einen Buffer kopieren, mprotect, Zeiger merken, fertig. Mal ausprobieren.
|
|
|
|
|
|
|
|
|
|
|
du könntest dir natürlich auch automatisch eben einen wrapper für die exportierten libgl sachen generieren lassen und die richtige libgl umbenennen bzw. den symlink umbiegen.
dann kannst du in deiner libgl einfach alles abfangen und machen was du willst. du musst dann nur den ganzen kram einmal sauber forwarden.
|
|
|
|
|
|
|
|
|
|
|
...und wenn die Anwendung dlopen("/usr/lib/libGL.so") macht?
Andererseits wäre das wohl die sauberere Lösung...
|
|
|
|
|
|
|
|
|
|
| |
| Code: |
sudo cp ~/mylibGl.so /usr/lib/libGL.so
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Top kek
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Top kek
| |
die marke gibt es bei unserer haus-döneria wirklich!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wow, tolle Sache. War das abzusehen?
|
|
|
|
|
|
|
|
|
|
|
Auch die DRM Sachen? Schliesst das Silverlight mit ein?
Sonst ist es nutzlos.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Daddi89
Wow, tolle Sache. War das abzusehen?
| |
Ich glaube nicht, dass sich Microsoft damit abgefunden hat, dass Windows nicht überall benutzt wird. Vielmehr haben sie es jetzt wohl eingesehen und arbeiten daran, dass wieder mehr Windows genutzt wird. zB. indem man Sachen open-sourced, um in die anderen Märkte reinzukommen ("Plattform XYZ jetzt in ganz Toll auch auf OSX und Linux"). Später gibt es dann bestimmte Features nur für Windows ("... erstmal nur für Windows, ist ja auch unsere Hauptplatform. Später auch anderswo, versprochen!"), vielleicht auch mit der einen oder anderen kleinen Inkompatibilität. Write once, debug everywhere. Am Ende bleiben die Leute dann doch wieder an Windows gebunden.
tl;dr würde ich keineswegs wundern, wenn die gleiche MS-Strategie wie so oft dahinter steckt. Ich sage nur Visual J++.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 12.11.2014 19:54]
|
|
|
|
|
|
|
|
|
Ich soll demnächst gut 40 Rechner ohne administrativen Mehraufwand aufstellen. Die Teile sollen eine minimale Weboberfläche in Silverlight (urgs, spuck, würg) ausführen. Mein letzter Strohhalm ist pipelight.
Alternativ kommen erstmal dann 40 Festplatten, mehr Rechenleistung, 40x1xxEUR Lizenzen und Administrations-/Installationsaufwand auf uns zu.
Keine Ahnung, warum das Teil SL können muss (es handelt sich um eine BDE-Obefläche zur Rückmeldung von Produktionsmengen).
|
|
|
|
|
|
|
|
|
|
|
|
Warum ist überhaupt irgendwas in Silverlight, was nicht von MS kommt oder deren DRM Zeug nutzt?
|
|
|
|
|
|
|
|
|
|
|
Willst du nicht wissen. Das umgebende Produkt nutzt, soweit mir bekannt: IIS, Tomcat, MSSQL (oder Oracle), Java-Applets, Java, Flash, Spring und für die Maske Silverlight.
FML
|
|
|
|
|
|
|
|
|
|
|
|
Der SIP Client unserer PBX basierte auch auf Silverlight. Der war nach genau einer Version wieder Geschichte.
|
|
|
|
|
|
|
|
|
|
|
Mal ne 101-Frage zu IPv6: Wie geht das?
Ich bin mit v4-NAT aufgewachsen und steh jetzt wie der Depp vorm Feld und frage mich, wie ich das was ich bisher mit v4 hatte mit v6 abbilde. Konkret: An welchen Stellen und mit welchen Mitteln definiere ich, wie ein Rechner kommunizieren darf?
Beispiel: Ich hätte nen ISP mit nativem v6. Ich bekomme ein Netz zugeteilt, kann meinen Geräten daheim Adressen aus diesem Netz geben ... und dann? Muss sich jetzt das Gerät, das als erstes am Kabel hängt und physikalisch den gesamten eingehenden Traffic bekommt um Regelwerke und weiteres Routing nach innen kümmern?
Anderes Beispiel: Habe (bisher) einen nginx-proxy mit öffentlicher v4-IP, der mehrere Backends mit privaten v4-IPs hinter sich hat. Wie addressiere ich die Backends mit v6 ohne sie gleich irgendwie global erreichbar zu machen?
Ich glaub, ich steh da einfach fett auf dem Schlauch.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rufus am 12.11.2014 20:26]
|
|
|
|
|
|
|
|
|
| | Zitat von TheRealHawk
Der SIP Client unserer PBX basierte auch auf Silverlight. Der war nach genau einer Version wieder Geschichte.
| |
Von den Key-Usern, die die Schulung für das Teil gemacht haben, kam auch die Rückmeldung: "hat nicht mal auf dem Rechner des Beraters funktioniert ist bei uns regelmäßig abgestürtzt". 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Daddi89
Wow, tolle Sache. War das abzusehen?
| |
ja, seit dem sie anfang des jahres den ASP.NET kram und die C# compiler infrastruktur auf gemacht haben.
der jetzige kram wird halt benötigt, damit der kram sauber läuft, da der mono rotz halt genau das ist, rotz. da fehlt an allen ecken und kanten was und es ist einfach in sehr vielen bereichen nicht zu der MS .NET version kompatibel.
| | Zitat von theromi
Auch die DRM Sachen?
| |
nein, die sind nicht direkter bestandteil von .NET sondern der windows media foundation (oder wie auch immer das subsystem inzwischen heissen mag).
| | Zitat von theromi
Schliesst das Silverlight mit ein?
| |
eher weniger, weil silverlight seit jahren (2010 rum müsste die notice gekommen sein) deprecated und nur noch künstlich mit security fixes am leben erhalten wird, bis es 2021 dann endgültig vollständig unsupported ist.
| | Zitat von csde_rats
man Sachen open-sourced, um in die anderen Märkte reinzukommen
| |
aus dem kontext gezogen. das ist deren vermutliche idee dahinter. windows server haben sich bisher nirgends durchgesetzt wo last vorhanden ist oder wo du wirkliche services hast.
die einzigen, die das einsetzten sind hoffnungslose firmen, die ihrem domain kram nicht anders gemanaged bekommen und noch nie was von ldap gehört haben und die, die direkt mit MS verträge haben, was leider viel zu viele sind, weil die entscheider einfach in vielen fällen zu dumm sind.
| | Zitat von csde_rats
vielleicht auch mit der einen oder anderen kleinen Inkompatibilität.
| |
die haben wir jetzt schon, die nennt sich mono.
das kann also irgendwo/wie nur besser werden und wenn sie das wirklich so durchziehen, wie sie es jetzt seit knapp nem jahr propagieren, dann könnte das recht nett werden.
davon abgesehen, der code steht entweder unter GPL oder MIT lizenz. sobald der einmal raus ist, kann MS da nicht mehr viel machen, andernfalls forkt sich den kram jemand.
| | Zitat von csde_rats
Write once, debug everywhere.
| |
das wird es so oder so werden, genau wie bei java und allen anderen "write once, run everywhere" sprachen und frameworks auch.
will man sachen haben, die vernünftig überall funktionieren, dann muss man die entsprechend anpassen. die gloreiche java idee, von der obiger spruch stammt, sollte endlich mal aus dem köpfen von vielen vielen menschen verschwinden, denn das system (nicht OS) gibt es nicht, bei dem das so läuft.
| | Zitat von csde_rats
tl;dr würde ich keineswegs wundern, wenn die gleiche MS-Strategie wie so oft dahinter steckt.
| |
die strategie ist, dass sie ihre technologie namens ASP.NET verbreiten wollen, als gegenspieler zu PHP und Java.
sie haben nur inzwischen mal eingesehen, dass sie das nicht mit einer windows server lizenz verknüpfen können, da die leute dann keine lust mehr drauf haben.
windows ist nunmal einfach kein server system. es ist und bleibt einfach ein desktop system.
um es kurz klar zu stellen, MS gibt da nicht den vollen .NET stack frei, sondern den server core.
das ist die infrastruktur, die benötigt wird, damit ASP.NET und die von MS gekauften/entwickelten frameworks darauf laufen.
dazu zählt natürlich auch die core runtime, ohne die funktioniert halt nichts höheres.
dazu zählt aber ganz sicher NICHT die WPF oder ähnliche sachen aus der kategorie.
das hier ist übrigens ein wenig inhaltlich korrekter: http://blogs.msdn.com/b/somasegar/archive/2014/11/12/opening-up-visual-studio-and-net-to-every-developer-any-application-net-server-core-open-source-and-cross-platform-visual-studio-community-2013-and-preview-of-visual-studio-2015-and-net-2015.aspx
und etwas klarer: http://www.hanselman.com/blog/AnnouncingNET2015NETasOpenSourceNETonMacandLinuxandVisualStudioCommunity.aspx
was ich an dem artikel übrigens sehr viel interessanter finde ist der punkt, dass VS 2015 nativ Clang inkl. debugger unterstützen wird! das darf man dann wohl als FUCK YEAH bezeichnen.
oh und natürlich das VS 2013 professionell jetzt keine 4k euro mehr kostet sondern kostenlos ist.  mit vollem funktionsumfang.
|
|
|
|
|
|
|
|
| Thema: 100 gute Gründe für Linux ( Gute Informatiker für ++30 ) |
