FibreSeeker 3: Continuous Carbon Fiber vs Chopped CF

Although you can purchase many types of FDM filaments containing ‘carbon fiber’ these days, they are in no way related to the carbon fiber (CF) composite materials used for rocket hulls and light-weight bicycles. This is because the latter use continuous fibers, often in weaved CF mats, whereas the FDM filaments just use small, chopped, fragments of CF. Obviously this will not result in the same outcome, which makes it interesting that a company called Fibre Seek is now running a KickStarter for a very affordable co-extrusion FDM printer that can add continuous CF to any part. They also sent a few test parts to [Dr. Igor Gaspar] for testing against regular FDM CF prints.

It should be noted here that continuous CF with FDM is not new, as Markforged already does something similar, though at a ‘Contact us for a price quote’ level. The advantage of the Fibre Seek solution is then the co-extrusion that would make printing with continuous CF much more flexible and affordable. Based on the (sponsored) [CNC Kitchen] video of a few weeks ago at a tradeshow, the FibreSeeker 3 printer is effectively a standard CoreXY FDM printer, with the special co-extrusion dual print head that allows for CF to be coated with the target thermoplastic before being printed as normal.

Unfortunately for [Igor] he did not have a FibreSeeker 3 to print on, and the print request for his usual test samples got mixed up by Fibre Seek, leaving him with only 4 out of 10 items to test with. This makes this a bit of an abbreviated test, but should still provide some useful data relative to the Polymaker PETG-CF filament that was used for comparison.

Based on the limited test set, it can be said that the FibreSeeker 3 parts did generally better than the PETG-CF parts, albeit with a few asterisks. Accordingly, [Igor] is left feeling somewhat confused by Fibre Seek, but sees the potential of this new co-extrusion technology. It just feels like the FibreSeeker 3 printer is not quite finished yet, and that the true value of this approach and this new printer will have to prove themselves.

youtube.com/embed/k9qs7uOwA64?…

youtube.com/embed/dQp7yz6fzH0?…

hackaday.com/2025/12/25/fibres…

Malware macOS nordcoreano sfrutta finti colloqui di lavoro per rubare credenziali

Un’analisi approfondita statica e dinamica ha portato all’individuazione di un malware per macOS denominato DriverFixer0428, classificato come ladro di credenziali e attribuito con un livello di confidenza medio-alto alla campagna nordcoreana nota come “Contagious Interview”. Il campione si presenta come una presunta utility di sistema, progettata per indurre l’utente a fidarsi dell’applicazione e a interagire con essa.

Il comportamento principale del malware consiste nella raccolta delle credenziali di accesso del sistema macOS. Per ottenere questo risultato, DriverFixer0428 utilizza finestre di dialogo artefatte che riproducono fedelmente i prompt di sicurezza del sistema operativo e le richieste di autorizzazione di Google Chrome, sfruttando tecniche di ingegneria sociale. Le credenziali inserite vengono successivamente inviate a infrastrutture controllate dagli attaccanti attraverso l’API di archiviazione cloud di Dropbox.

Il nome del campione deriva da riferimenti interni presenti nel binario analizzato. Durante l’analisi statica sono emersi identificatori come DriverFixer0428, OverlayWindowController e riferimenti a file Swift, suggerendo una struttura applicativa coerente con un progetto legittimo. Il suffisso “0428” viene interpretato come un possibile riferimento alla data di compilazione del malware, il 28 aprile, oppure a una numerazione interna di versione utilizzata dagli sviluppatori della minaccia.

Dal punto di vista tecnico, il campione analizzato corrisponde a un binario universale Mach-O, compatibile con architetture x86_64 e ARM64, scritto in Swift e basato su AppKit. Il file ha una dimensione di circa 235 KB, utilizza l’identificativo di pacchetto chrome.DriverFixer0428 ed è associato al percorso sorgente DriverFixer0428/ViewController.swift. L’hash SHA-256 del campione è 9aef4651925a752f580b7be005d91bfb1f9f5dd806c99e10b17aa2e06bf4f7b5.

L’attribuzione alla Corea del Nord si basa su una correlazione delle tecniche, tattiche e procedure con campagne già documentate pubblicamente. Sebbene l’hash specifico non risulti presente nei principali database di threat intelligence, le somiglianze operative collegano il campione alle famiglie FlexibleFerret, FrostyFerret, ChromeUpdate e CameraAccess, tutte associate alla stessa attività di minaccia. In particolare, l’infrastruttura di rete coincide con quella descritta da SentinelOne nel febbraio 2025.

Le comunicazioni di rete osservate includono il contatto con api.ipify.org per determinare l’indirizzo IP pubblico del sistema compromesso e l’utilizzo delle API di Dropbox per la gestione dei token OAuth e il caricamento dei dati esfiltrati. Questa scelta consente al malware di mascherare il traffico malevolo dietro servizi cloud legittimi, riducendo la probabilità di rilevamento da parte dei controlli di sicurezza basati sulla rete.

L’analisi dinamica condotta tramite il debugger LLDB ha evidenziato un articolato sistema di evasione delle sandbox. DriverFixer0428 esegue controlli runtime per individuare ambienti virtualizzati interrogando API di sistema come sysctlbyname, il registro IOKit e l’API NSScreen. In presenza di una macchina virtuale o di un ambiente di analisi, il malware evita di attivare il payload e rimane in uno stato di esecuzione inattivo.

Questo comportamento di “fallimento silenzioso” spiega la discrepanza tra i risultati dell’analisi statica, che indicano chiaramente attività malevole, e i punteggi relativamente bassi ottenuti nelle sandbox automatizzate, dove il campione viene classificato come probabilmente benigno. Secondo gli analisti, questa capacità operativa riflette un livello di maturità compatibile con attori sponsorizzati da uno Stato e conferma i limiti degli strumenti di rilevamento automatici nel contrasto a minacce avanzate.

L'articolo Malware macOS nordcoreano sfrutta finti colloqui di lavoro per rubare credenziali proviene da Red Hot Cyber.

Siamo tutti grandi e perciò ci facciamo regali di Natale sono se ci troviamo intorno alla stessa tavola il giorno di Natale.

Ok un set lego: non sono mai troppi e non fanno male.
Ok la 𝙏𝙧𝙞𝙡𝙤𝙜𝙞𝙖 𝙙𝙚𝙡𝙡𝙖 𝙛𝙧𝙤𝙣𝙩𝙞𝙚𝙧𝙖 di Cormac McCarthy: 2 su 3 non li avevo letti.

Ma come 🚀 può venire in mente a qualcuno di regalarmi una candela di sale dell'Himalaya?

In quale possibile universo può esistere una versione di me che potrebbe apprezzare una 𝗰𝗮𝗻𝗱𝗲𝗹𝗮-𝗱𝗶-𝘀𝗮𝗹𝗲-𝗱𝗲𝗹𝗹'𝗛𝗶𝗺𝗮𝗹𝗮𝘆𝗮?
Mi chiedo.

MQTT Pager Build is Bringing Beepers Back

Pagers were once a great way to get a message to someone out in public; they just had to be cool enough to have one. These days, they’re mostly the preserve of doctors and a few other niche operators. [Kyle Tryon] is bringing the beeper back, though, with a custom ESP32-based build.

The ESP32 is a great microcontroller for this kind of project, because it’s got WiFi and Bluetooth connectivity built right in. This let [Kyle] write some straightforward code so that it could receive alerts via MQTT. In particular, it’s set up to go off whenever there’s an app or service notification fired off by the Sentry platform. For [Kyle]’s line of work, it’s effectively an on-call beeper that calls them in when a system needs immediate attention. When it goes off, it plays the ringtone of your choice—with [Kyle] making it capable of playing tunes in Nokia’s old-school RTTTL music format.

The code was simple enough, and the assembly wasn’t much harder. By starting with an Adafruit ESP32 Reverse TFT Feather, the screen and buttons were all ready to go right out of the box. [Kyle] merely had to print up a rad translucent case on a resin printer to make it look like a sweet fashionable beeper from the 90s.

It’s a fun little project that should prove useful, while also being nicely reminiscent of a technology that has largely fallen by the wayside.

youtube.com/embed/lnWRui3_0X0?…

hackaday.com/2025/12/25/mqtt-p…