|
|
|
|
| Zitat von csde_rats
Hach Flash. Ich weiß ehrlich gesagt auch nicht, wann ich das letzte Mal überhaupt diese "Jomei, des Ploguan hoam wa ned!" Fehlermeldung gesehen habe. Muss schon ein paar Jahre her sein.
| |
z0r.de
|
|
|
|
|
|
|
| Zitat von csde_rats
Hach Flash. Ich weiß ehrlich gesagt auch nicht, wann ich das letzte Mal überhaupt diese "Jomei, des Ploguan hoam wa ned!" Fehlermeldung gesehen habe. Muss schon ein paar Jahre her sein.
| |
Ikea.de PAX-Planer. Ich musste wirklich Chrome dafür benutzen und habe mich schmutzig gefühlt.
Er ist auch noch scheiße.
|
|
|
|
|
|
|
Flash <=> Anwendung ist scheiße (p<0.01).
-
| Group sex app leaks locations, pics and personal details (pentestpartners.com) | |
*kicher*
| You’ll see the latitude and longitude of the user is disclosed. No need for trilateration.
Now, the user can restrict the sending of the lat/long so as not to give away their position.
BUT, that data is only filtered in the mobile app itself, not on the server. It’s just hidden in the mobile app interface if the privacy flag is set. The filtering is client-side, so the API can still be queried for the position data. FFS!
...
This data can be used to stalk users in near real-time, expose their private activities and worse.
Then it got really worrying. Private photos are exposed too, even when privacy settings were in place. The URIs are disclosed in API responses: | |
Wurde 3fun von einem gewissen britischen Spieleentwickler gebaut?
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 09.08.2019 14:39]
|
|
|
|
|
|
| Zitat von Traxer
ich hab heute übrigens die molex sl geliefert bekommen, die sind dann die korrekte wahl dafür.
danke für den tipp.
| |
ok, heute kamen dann auch die kontakte.
ich dachte ich hatte eine passende crimpzange. dachte. gibt es da eine gute und günstige empfehlung für diese teile, für jemanden, der vielleicht 20 crimps pro jahr macht?
|
|
|
|
|
|
|
Wie fucking schlecht X-Fi Karten (zumindest meine, noch mit PCI) sind. Die Creative-Treiber und "Einstellsoftware" haben ihren legendär schlechten Ruf wirklich wirklich verdient, aber selbst von der Hardware her. Ich mein klar, ich erwarte ja in 2019 gar nicht mehr, dass ne Soundkarte Kopfhörer treiben kann und habe eh schon immer irgendeine Form von Kopfhörer-Verstärker im Einsatz (früher ein kleines 3-Kanal Mischpult, an dem dann der Zweitlaptop für Musik hing, seit ich das so nicht mehr mache, habe ich nen Eigenbau KHV mit umschaltbarem Ausgang, damit ich leichter zwischen In-Ears und DT 770 wechseln kann). Und das kann so eine X-Fi halt sowieso gar nicht, aber ok, wundert halt nicht. Aber der Mikrofon-Vorverstärker in dem Ding ist ja so UNFUCKING UNFASSBAR schlecht, das ist wirklich Wahnsinn. Selbst im Line-In Modus hat das Ding locker 10 dB mehr Rauschen drauf als der Billo-Realtek Chip auf dem Motherboard. Holy. Fucking. Shit. Wie schlecht. Wie einfach nur schlecht diese Hardware ist.
tl;dr nie wieder Creative.
Was soll ich kaufen bei meinem Ryzengrade? Darf man heutzutage direkt nen Pro-Audio-Interface der unteren Preiskategorie (dreistellig) kaufen? Ach halt ne, warte, die Scarlett Dinger habe ja auch nen verrauschten Kopfhörerausgang. BEI NEM 150 EURO AUDIO INTERFACE.
|
|
|
|
|
|
|
Spitzzange oder einfach verlöten. Letzteres ist weniger fummelig und hält besser, sofern nix in den Kontakt selbst reingesaugt wird. Was je nach Bauform nicht so ganz einfach ist.
|
|
|
|
|
|
|
Wir sollten einen netten USB-Mic-Amp mit DAC und KHV kickstarten.
|
|
|
|
|
|
|
ich hab hier so ein gebrauchtes motu 828 mk2 firewire. macht was es soll, auch wenn einer der potis getauscht werden muss.
die gibts teilweise recht günstig bei der bucht. ich hab meines vom stiefvater, weil er auf nen rme fireface ucx umgestiegen ist.
|
|
|
|
|
|
|
Ich bin mit meinem Scarlett eigentlich zufrieden
(Zumindest mit dem 250 Ohm Kopfhörern und es ist nen 300¤ Scarlett, weil mehr Inputs brauche).
Es gibt wohl nicht umsonst einen Markt für USB Kopfhörer-Verstärker.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von audax am 09.08.2019 21:58]
|
|
|
|
|
|
Bei den 2i2(? - dem kleinen Ding jedenfalls) hatte ich mal Interesse aber es gab so viele Berichte über Rauschen und andere Störgeräusche, Treiberproblem usw. da hatte ich dann ziemlich schnell kein Interesse mehr
|
|
|
|
|
|
|
2i2 hatte ich auch, zweite Generation. Die war dann in Ordnung und klang prima. Jetzt hab ich nen 16i8 oder so, das ist auch vernünftig.
|
|
|
|
|
|
|
Ich habe hier ein thinkpad USB c dock, und würde gerne auch meinen alten Dell xps 13 Laptop damit verbinden. Die Anforderungen des Docks an den Laptop sind:
|
Power Delivery (PD)
Display Port Alternative Mode
USB 3.0 Data Support
| |
Der Dell (dieser) hat USB 3 und mini dp. Gibt es einen Adapter, der zwischen dock und Dell vermitteln kann? Power kann meinetwegen ins Leere laufen, hat ja nen Akku.
|
|
|
|
|
|
|
Das USB C oder das thunderbolt dock?
Wenn ersteres ist das Zauberwort DisplayLink, mit dem der Bildschirm über den USB3 "betrieben" wird. Dazu gibt es Treiber unter Windows und ein Kernelmodul unter Linux namens evdi. Sollte einfach so funktionieren, allerdings nur mit akzeptabler Performance bis full HD.
Thunderbolt ist sowieso kompatibel, musst es unter Linux zur authentifizieren eventuell (ein Tool dafür heißt boltctl).
|
|
|
|
|
|
|
Nee, ist USB C. Laut Interwebs spare ich mir viel Frust wenn ich einfach ein kvm switch und eigenes dock für den anderen Laptop nehme.
|
|
|
|
|
|
|
Wir haben solche Docks im Büro und. Ich habe sie tadellos mit HP, Lenovo und Dell funktionieren sehen, Treiber vorausgesetzt. So tadellos wie DisplayLink eben funktioniert. Es könnte sich im Zweifel lohnen die Firmware auf dem Dock aktuell zu halten. Geht natürlich nur mit einem Windows Tool.
|
|
|
|
|
|
|
| Die Gewinnerin des Vorjahres etwa habe jedes Mal, wenn sich jemand namentlich am Telefon meldete, etwas gesagt wie "Ach, so heißt meine Schwester auch!", erzählt Hadnagy - und jedes Mal habe man hören können, dass die Opfer gleich ein wenig glücklicher klangen. | |
"Timothy Schwengelhart, Deutshe Bank Compliance?" - "Ach, so heißt meine Schwester auch!"
|
|
|
|
|
|
|
|
|
|
|
"ey lass mal über Ring-Grenzen hinweg spekulativ Code ausführen" <-- da kann mir doch keiner mehr erzählen, dass da niemand "könnte das nicht ein Sicherheitsproblem sein?" gedacht hat.
|
|
|
|
|
|
|
| Zitat von hoschi
Xfce 4.14 ist endlich erschienen, mit vollständiger Migration auf Gtk3. Wer einen HiDPI-Monitor sein eigen nennt, sollte sich das Upgrade gönnen. Hat nur acht Jahre gedauert
| |
Hmja, ich werde nicht ganz schlau aus der Multi-Monitor Geschichte. Fenster gehen in unterschiedlichen Situationen auf das "falsche" Display, beim Abstecken auch gerne off-screen (vom Display das übrig bleibt ).
Panel auf beiden Monitoren? Mission Impossible. *shrug*
Getestet hat das jedenfalls keiner.
Und ab wann gilt ein Monitor eigentlich als HiDPI?
|
|
|
|
|
|
|
Hier unter GNOME3 funktioniert es gut. Wenn ich ausdocke, sind alle Anwendung auf dem Laptopbildschirm. Wenn ich eindocke, sind alle Anwendung die vorher auf dem externen Monitor waren - genau da. Schon seit, immer
Da kommen allerdings viele Variablen zusammen, einerseits hängt es vom Desktop ab, welcher die Anordnung der Monitore verwaltet und dem Displaymanager welche die Fenster kontrolliert andererseits vom Toolkit und wie es mit X11, Wayland, GDI, Cococa(?) kommuniziert.
Meine Anwendung fragt zum Beispiel über Gtk und Gdk nach dem primären Monitor und verwendet dann 1/3 der Bildschirmgröße als Fenstergröße. Andere Möglichkeiten werden das eigene Layout oder die Schriftgröße. Das funktioniert wunderbar unter Windows und Linux/X11, auch mit HiDPI und Skalierung. Gtk3 gibt unter Wayland jedoch keinen primären Monitor zurück, nullptr. Zum Glück hatte ich Defaultwerte gesetzt. Mit Gtk4 wird es unter Wayland eine Abfragemöglichkeit geben, wobei ich irgendwie hoffe, dass das noch länger dauert. Vermutlich hat das seinen Grund darin, das Wayland zu Beginn keine passende API zur Abfrage geboten hat.
Ich freu mich ja, dass hier auch eine Anwendung mit Tcl/Tk, unfallfrei läuft.
|
[Dieser Beitrag wurde 6 mal editiert; zum letzten Mal von hoschi am 13.08.2019 22:30]
|
|
|
|
|
|
Moin.
Kann man den Linux-Kernel davon überzeugen angeschlossene (USB-)Geräte nicht direkt mit einem passenden geladenen Modul oder sogar fest einkompiliertem Treiber anzusprechen?
Ich habe ein Stück Hadrware mit einem FTDI FT232H. Der darf aber nicht vom Kernel als Seriellnupsi übernommen werden. Vermutlich benutzt der Hersteller die alternative Methode das Ding anzuquatschen:
| https://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232H.pdf
FTDI’s royalty-free Virtual Com Port (VCP) and Direct (D2XX) drivers eliminate the requirement for USB driver development in most cases. | |
Unter Windows geht das, unter Linux muss ich dafür bisher leider komplett usbserial und ftdi_sio blacklisten*.
Spätestens seit man USB- (und inzwischenandere(?)) Geräte an virtuelel Maschinen weiterreichen kann, gibt es aber doch bestimmt einen Mechanismus dafür um das für einzelne Geräte individuell zu regeln?
*bei Arch ist usbserial kein Modul, also darf man erstmal einen neuen Kernel bauen. Yay Arch
|
|
|
|
|
|
|
Da kann man bestimmt was mit einer Udev regel drehen. Aber frag mich nicht wie
|
|
|
|
|
|
|
das geht recht einfach, sofern das ftdi dingen einen eindeutigen namen bzw. seriennummer hat. andernfalls kannste das knicken. was aber unter windows auch nicht wirklich anders ist.
hast du das, dann kannst du entweder hingehen und dir ne udev ignore regel bauen, die von deiner udev version abhängt, oder aber das device während der enumeration via /sys/.../authorized „blacklisten“. letzteres erfordert möglicherweise ein klein wenig scripting.
bitte immer schön bedenken, die usb port zuordnung ist nicht garantiert deterministisch. system reboot und die devices hängen potentiell an anderen ports, anderes gerät angesteckt und die nummerierung kann sich ändern.
|
|
|
|
|
|
|
|
|
|
|
Wird morgen getestet! :icon14:
|
|
|
|
|
|
aus der kategorie...
|
...spassige sachen mit intel server boards.
vorhin mal kurz das S3210SHLX mit nem core2 duo zu betreiben.
installation lief soweit, auch wenn die on-board PCIe NIC nicht gefunden wurde. ich hab da mal auf nen treiberproblem oder so getippt.
gut macht nichts, dass board hat ja noch ne zweite NIC. ne PCI variante. die tat dann auch.
system installiert. scheint zu laufen, bis auf die PCIe on-board NIC, die nach wie vor nicht gefunden wird. also denke ich mir, installierste dir mal nen paar tools zum diagnostizieren.
ging nicht, da angeblich keine verbindung zum internet.
ok, resolv.conf überprüft, ip l überprüft.
resultat, resolv.conf ok, ip l meldet no-carrier.
eigenartig.
kabel kontrolliert, alles wie es soll. nur sind auch keine LEDs an, der switch schon, aber auch da keine LEDs für den port an.
immer noch eigenartig.
wie war das noch mit dem rebooten hilft? also mal kurz nen reboot gemacht.
noch mal alles kontrolliert... bzw. ich wollte es kontrollieren.
nun fehlt auch die PCI NIC und das system findet weder die eine, noch die andere.
jetzt könnte man denken, ok, irgendwas treiber und so.
dmesg meldete bei der e1000 (PCI) einen "Hardware Error". mehr nicht.
problem ist jetzt aber, dass lspci keine der beiden chips mehr findet.
also mal kurz den strom weg um zu sehen ob das was resettet.
gemacht. system gebootet.
keine NICs via lspci zu finden. auch nicht anderweitig.
komisch.
reboot und ins BIOS wo die ja auch angezeigt werden, so mit MAC und co.
BIOS findet keine der beiden chips. da ist dann jetzt nen leeres feld, wo früher mal die infos zu den chips standen.
ich hab das system dann jetzt mal abgeschaltet, bevor mir da gleich noch mehr verschwindet.
so hardware die sich nach und nach, beim zusehen selbstzerlegt ist mir auch beim x-ten mal immer noch suspekt.
ich hab da aktuell nur ein einfaches WTF? für parat.
irgendwer ne gute empfehlung für nen 775 board für sowas, was IPMI kann und für server geeignet ist und was nicht von intel ist? die scheinen das irgendwie mit dem server boards herstellen nicht so zu können. sag ich jetzt zumindest so, weil ich jetzt in den letzten 3 jahren ca. 5 davon hatte und alle irgendwelche irren probleme hatten. also nicht so sachen wie treiber passt nicht oder so, sondern mehr sowas wie, netzwerkchips die sich auflösen, raid controller die auf einmal vergessen, welche raid level die so können, IPMI chips, die das system nach lust und laune resetten, obwohl weder watchdog noch sonst irgendwas aus der kategorie an ist, BMCs die sich aufhängen und das system mitnehmen, wenn man sich mit nem client auf das SOL zeugs einklinkt. sowas halt. so standard sachen, bei denen man erwarten können sollte, das sie tun, weil sind jetzt nicht so sonderlich neue sachen oder so, noch in irgendeiner weise speziell.
nicht, dass die boards teilweise recht teuer sind und so. in meinem fall jetzt eher weniger, aber sonst schon.
|
|
|
|
|
|
|
https://googleprojectzero.blogspot.com/2019/08/down-rabbit-hole.html
tl;dr großes Uff:
| It turns out it was possible to reach across sessions and violate NT security boundaries for nearly twenty years, and nobody noticed. | |
... allows you to instantiate and interact with COM objects remotely in any process ...
... marshalling protocol ... server tells you where its stack is ...
... calling any function index in a vtable ... effectively dereferencing attacker-provided function pointer ...
... no authentication ...
... no ACL ...
... all Win32 processes connect to the server ...
... system wide service, no privilege separation ...
... LoginUI.exe ...
... local-user to SYSTEM ...
... allows any CTF client to read and write the text of any window, from any other session ...
... Even sandboxed AppContainer processes can perform the same attack ...
... taking control of the UAC consent dialog ...
... protocol bugs that allow taking complete control of almost any other application ...
Eh, klassischer Microsoft-Code, Jahrgang aus den späten 90ern, durchaus gut genießbar!
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 15.08.2019 2:32]
|
|
|
|
|
|
immerhin kann man den code gut lesen. ist auch gut dokumentiert.
|
|
|
|
|
|
|
für die masochisten unter euch:
das ist valider C++ code, der exakt macht, was er soll.
wer hat, ohne nachzuschauen und es zu kompilieren ne ahnung, was rauskommt?
|
|
|
|
|
|
|
0
|
|
|
|
|
|
Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |