When you buy a cheap ham radio handy-talkie, you usually get a little “rubber ducky” antenna with it. You can also buy many replacement ones that are at least longer. But how good are they? [Learnelectronics] wanted to know, too, so he broke out his NanoVNA and found out that they were all bad, although some were worse than others. You can see the results in the — sometimes fuzzy — video below.

Of course, bad is in the eye of the beholder and you probably suspected that most of them weren’t super great, but they do seem especially bad. So much so, that, at first, he suspected he was doing something wrong. The SWR was high all across the bands the antennas targeted.

It won’t come as a surprise to find that making an antenna work at 2 meters and 70 centimeters probably isn’t that easy. In addition, it is hard to imagine the little stubby antenna the size of your thumb could work well no matter what. Still, you’d think at least the longer antennas would be a little better.

Hams have had SWR meters for years, of course. But it sure is handy to be able to connect an antenna and see its performance over a wide band of frequencies. Some of the antennas weren’t bad on the UHF band. That makes sense because the antenna is physically larger but at VHF the size didn’t seem a big difference.

He even showed up a little real-world testing and, as you might predict, the test results did not lie. However, only the smallest antenna was totally unable to hit the local repeater.

Of course, you can always make your own antenna. It doesn’t have to take much.

youtube.com/embed/3aE8Q8kgkGk?…

LCD televisions are a technological miracle, but if they have an annoying side it’s that some of them are a bit lacklustre when it comes to displaying black. [Mousa] has a solution, involving a small LCD and a bit of lateral thinking.

These screens work by the LCD panel being placed in front of a bright backlight, and only letting light through at bright parts of the picture. Since LCD isn’t a perfect attenuator, some of the light can make its way through, resulting in those less than perfect blacks. More recent screens replace the bright white backlight with an array of LEDs that light up with the image, but the electronics to make that happen are not exactly trivial.

The solution? Find a small LCD panel and feed it from the same HDMI source as a big panel. Then place an array of LDRs on the front of the small LCD, driving an array of white LEDs through transistor drivers to make a new responsive backlight. We’re not sure we’d go to all this trouble, but it certainly looks quite cool as you can see below the break.

This may be the first responsive backlight we’ve brought you, but more than one Ambilight clone has graced these pages.

youtube.com/embed/VY57LZGHuSw?…

This week Jonathan Bennett and Dan Lynch chat with Paweł Karaś about Amber, a modern scripting language that compiles into a Bash script. Want to write scripts with built-in error handling, or prefer strongly typed languages? Amber may be for you!

youtube.com/embed/eVmSU5T1uTg?…

– github.com/Ph0enixKM/Amber
– amber-lang.com/
– docs.amber-lang.com/

Did you know you can watch the live recording of the show Right on our YouTube Channel? Have someone you’d like use to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.

play.libsyn.com/embed/episode/…

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Places to follow the FLOSS Weekly Podcast:

• Spotify
• RSS

If you’re designing a universal port, you will be expected to provide power. This was a lesson learned in the times of LPT and COM ports, where factory-made peripherals and DIY boards alike had to pull peculiar tricks to get a few milliamps, often tapping data lines. Do it wrong, and a port will burn up – in the best case, it’ll be your port, in worst case, ports of a number of your customers.
Want a single-cable device on a COM port? You might end up doing something like this.
Having a dedicated power rail on your connector simply solves this problem. We might’ve never gotten DB-11 and DB-27, but we did eventually get USB, with one of its four pins dedicated to a 5 V power rail. I vividly remember seeing my first USB port, on the side of a Thinkpad 390E that my dad bought in 2000s – I was eight years old at the time. It was merely USB 1.0, and yet, while I never got to properly make use of that port, it definitely marked the beginning of my USB adventures.

About six years later, I was sitting at my desk, trying to build a USB docking station for my EEE PC, as I was hoping, with tons of peripherals inside. Shorting out the USB port due to faulty connections or too many devices connected at once was a regular occurrence; thankfully, the laptop persevered as much as I did. Trying to do some research, one thing I kept stumbling upon was the 500 mA limit. That didn’t really help, since none of the devices I used even attempted to indicate their power consumption on the package – you would get a USB hub saying “100 mA” or a mouse saying “500 mA” with nary an elaboration.

Fifteen more years have passed, and I am here, having gone through hundreds of laptop schematics, investigated and learned from design decisions, harvested laptops for both parts and even ICs on their motherboards, designed and built laptop mods, nowadays I’m even designing my own laptop motherboards! If you ever read about the 500 mA limit and thought of it as a constraint for your project, worry not – it’s not as cut and dried as the specification might have you believe.

Who Really Sets The Current Limit?

The specification originally stated – you aren’t supposed to consume more than 500mA from a USB port. At some points, you’re not even supposed to consume more than 100mA! It talked unit loads, current consumption rates, and a good few other restrictions you would want to apply to a power rail. Naturally, that meant enforcement of some kind, and you would see this limit enforced – occasionally.

On the host side, current limiting had to be resettable, of course, and, at the time, that meant either PTC fuses or digital current limiting – both with their flaws, and a notable price increase – per port. Some bothered (mostly, laptops), but many didn’t, either ganging groups of ports together onto a single limited 5 V rail, or just expecting the board’s entire 5 V regulator to take the fall.
Current limiting a port is this simple
Even today, hackers skimp on current limiting, as much as it can be useful for malfunctioning tech we all so often hack on. Here’s a tip from a budding motherboard designer: buy a good few dozen SY6280’s, they’re 10 cents apiece, and here’s a tiny breakout PCB for them, too. They’re good for up to 2 A, and you get an EN pin for free. Plus, it works for both 3.3 V, 5 V, and anything in between, say, a single LiIon cell’s output. Naturally, other suggestions in comments are appreciated – SY6280 isn’t stocked by Western suppliers much, so you’ll want LCSC or Aliexpress.

Another side of the equation – devices. Remember the USB cup warmer turned hotplate that required 30 paralleled USB ports to cook food? It diligently used these to stay under 500 mA. Mass-manufactured devices, sadly, didn’t.

Portable HDDs wanted just a little more than 2.5 W to spin-up, 3G modem USB sticks wanted an 2 A peak when connecting to a network, phones wanted more than 500 mA to charge, and coffee warmers, well, you don’t want to sell a 2.5 W coffee warmer when your competitor boasts 7.5 W. This led to Y-cables, but it also led to hosts effectively not being compatible with users’ devices, and customer dissatisfaction. And who wants complaints when a fix is simple?

It was also the complexity. Let’s say you’re designing a USB hub with four ports. At its core, there’s a USB hub IC. Do you add current consumption measurement and switching on your outputs to make sure you don’t drain too much from the input? Will your users like having their devices randomly shut down, something that cheaper hubs won’t have a problem with? Will you be limiting yourself to way below what the upstream port can actually offer? Most importantly, do users care enough to buy an overly compliant hub, as opposed to one that costs way less and works just as well save for some edge cases?

Stretching The Limit

500 mA current monitoring might have been the case originally, but there was no real need to keep it in, and whatever safety 500 mA provided, came with bothersome implementation and maintenance. The USB standard didn’t expect the 2.5 W requirement to budge, so they initially had no provisions for increasing, apart from “self-powering” aka having your device grab power from somewhere else other than the USB port. As a result, both devices and manufacturers pushed the upper boundary to something more reasonable, without an agreed-upon mechanism on how to do it.

USB ports, purely mechanically, could very well handle more than 0.5 A all throughout, and soon, having an allowance of 1 A or even 1.5 A became the norm. Manufacturers would have some current limits of their own in mind, but 500 mA was long gone – and forget about the 100 mA figure. Perhaps the only place where you could commonly encounter 500 mA was step-ups inside mobile phones, simply because there’s neither much space on a motherboard nor a lot of power budget to spend.

Smartphone manufacturers were in a bind – how do you distinguish a port able to provide 500 mA from a port able to provide 1000 mA, or even 2 A outright? That’s how D+/D- shenanigans on phone chargers came to be – that, and manufacturers’ greed. For Android, you were expected to short data lines with a 200 Ohm resistor, for Apple, you had to put 2.2 V or 2.7 V on the data pins, and if you tried hard enough, you could sometimes use three resistors to do both at once.

Bringing The Standard In Line

The USB standard group tried to catch up with the USB BC (Battery Charging standard), and adopted the Android scheme. Their idea was – if you wanted to do a 1.5 A-capable charger, you would short D+ and D-, and a device could test for a short to check whether it may consume this much. Of course, many devices never checked, but it was a nice mode for smartphones specifically.

When you’re making a device with a LiIon that aims to consume over an amp and be produced in quantity of hundreds of thousands, safety and charger compatibility is pretty crucial. A less common but nifty charging mode from the BC standard, CDP (Charging Downstream Port), would even allow you to do USB2 *and* 1.5 A. Support for it was added to some laptops using special ICs or chipset-level detection – you might have had a yellow port on your laptop, dedicated for charging a smartphone and able to put your phone’s port detection logic at ease.

Further on, USB3 took the chance to raise the 500 mA limit to 90 0mA. The idea was simple – if you’re connected over USB2, you may consume 500 mA, but if you’re a USB3 device, you may take 900 mA, an increased power budget that is indeed useful for higher-speed USB3 devices more likely to try and do a lot of computation at once. In practice, I’ve never seen any laptop implement the USB2 vs USB3 current limit checking part, however, as more and more devices adopted USB3, it did certainly raise the bar on what you could be guaranteed to expect from any port.

As we’ve all seen, external standards decided to increase the power limit by increasing voltage instead. By playing with analog levels on D+ and D- pins in a certain way, the Quick Charge (QC) standard lets you get 9 V, 12 V, 15 V or even 20 V out of a port; sadly, without an ability to signal the current limit. These standards have mostly been limited to phones, thankfully.

USB-C-lean Slate

USB-C PD (Power Delivery) has completely, utterly demolished this complexity, as you might notice if you’ve followed my USB-C series. That’s because a device can check the port’s current capability with an ADC connected to each of the two CC pins on the USB-C connector. Three current levels are defined – 3 A, 1.5 A and “Default” (500 mA for USB2 devices and 900 mA for USB3). Your phone likely signals the Default level, your charger signals 3 A, and your laptop either signals 3 A or 1.5 A. Want to get higher voltages? You can do pretty simple digital communications to get that.

Want to consume 3 A from a port? Check the CC lines with an ADC, use something like a WUSB3801, or just do the same “check the PSU label” thing. Want to consume less than 500 mA? Don’t even need to bother checking the CCs, if you’ve got 5 V, it will work. And because 5 V / 3 A is a defined option in the standard, myriad laptops will effortlessly give you 15 W of power from a single port.

On USB-C ports, BC can still be supported for backwards compatibility, but it doesn’t make as much sense to support it anymore. Proprietary smartphone charger standards, raising VBUS on their own, are completely outlawed in USB-C. As device designers have been provided with an easy mechanism to consume a good amount of power, compliance has become significantly more likely than before – not that a few manufacturers aren’t trying to make their proprietary schemes, but they are a minority.

Splunk, un leader nella fornitura di software per la ricerca, il monitoraggio e l’analisi dei big data generati dalle macchine, ha rilasciato aggiornamenti di sicurezza urgenti per il suo prodotto di punta, Splunk Enterprise.

Questi aggiornamenti affrontano diverse vulnerabilità critiche che rappresentano significativi rischi per la sicurezza, inclusa la possibilità di esecuzione di codice remoto (RCE). Le versioni interessate includono *9.0.x, 9.1.x e 9.2.x, e le vulnerabilità sono state identificate sia da ricercatori interni che esterni.

Vulnerabilità Chiave Affrontate

Le vulnerabilità critiche corrette in questi aggiornamenti sono le seguenti:

1. CVE-2024-36984: Questa vulnerabilità riguarda l’esecuzione arbitraria di codice tramite payload di sessione serializzati. Gli attaccanti potrebbero sfruttare questo difetto per eseguire comandi arbitrari sul server manipolando i dati della sessione.
2. CVE-2024-36985: Questa vulnerabilità RCE è legata a una ricerca esterna nell’applicazione splunk_archiver. Gli attaccanti che sfruttano questa vulnerabilità possono eseguire codice in remoto, potenzialmente ottenendo il controllo sui sistemi interessati.
3. CVE-2024-36991: I dettagli di questo problema critico non sono stati divulgati, ma è stato categorizzato come un rischio di sicurezza significativo che richiede attenzione immediata.
4. CVE-2024-36983: Un’altra grave vulnerabilità è l’iniezione di comandi tramite ricerche esterne. Iniettando comandi nei campi di ricerca, gli attaccanti possono eseguire comandi arbitrari, portando a una compromissione del sistema.
5. CVE-2024-36982: Questo problema riguarda un riferimento nullo al puntatore che può causare il crash dei daemon. Anche se potrebbe non portare all’esecuzione diretta di codice, può interrompere la disponibilità del servizio e potenzialmente essere sfruttato in attacchi di tipo denial-of-service.

Ulteriori Vulnerabilità

Oltre ai problemi critici sopra menzionati, sono state affrontate diverse vulnerabilità di Cross-Site Scripting (XSS). Le vulnerabilità XSS consentono agli attaccanti di iniettare script dannosi nelle pagine web visualizzate da altri utenti, portando potenzialmente al furto di dati, al dirottamento delle sessioni o ad altre attività dannose.

Mitigazione e Raccomandazioni

Splunk ha rilasciato patch per mitigare queste vulnerabilità. Gli utenti che utilizzano versioni interessate di Splunk Enterprise sono fortemente incoraggiati ad aggiornare alle seguenti versioni:

• 9.0.10
• 9.1.5
• 9.2.2

Queste versioni contengono le correzioni necessarie per proteggere i sistemi dalle vulnerabilità identificate. L’applicazione tempestiva di questi aggiornamenti è fondamentale per mantenere la sicurezza e l’integrità degli ambienti Splunk.

Per gli utenti della Splunk Cloud Platform, gli aggiornamenti vengono applicati automaticamente e il monitoraggio continuo è in atto per garantire la sicurezza delle istanze cloud.

Importanza degli Aggiornamenti Tempestivi

Il rilascio di questi aggiornamenti sottolinea l’importanza di una rapida applicazione delle patch per mantenere un ambiente IT sicuro. Data la natura delle vulnerabilità, in particolare quelle che consentono l’esecuzione di codice remoto, l’impatto potenziale di un exploit potrebbe essere grave, variando dall’accesso non autorizzato ai dati alla completa compromissione del sistema.

Le organizzazioni che fanno affidamento su Splunk Enterprise per l’analisi e il monitoraggio dei dati critici dovrebbero prioritizzare questi aggiornamenti nei loro protocolli di sicurezza. Oltre ad applicare le patch, è consigliabile rivedere le configurazioni di sicurezza, auditare i log di sistema per attività insolite e assicurarsi che vengano condotte valutazioni di sicurezza regolari.

Conclusione

La scoperta e la mitigazione di queste vulnerabilità critiche in Splunk Enterprise evidenziano le sfide continue nella sicurezza dei sistemi software complessi. Con l’evolversi delle minacce, le misure proattive, tra cui l’applicazione tempestiva delle patch e il monitoraggio continuo, sono essenziali per proteggere contro potenziali exploit. La rapida risposta di Splunk nell’affrontare questi problemi serve a ricordare il ruolo critico che gli aggiornamenti di sicurezza tempestivi giocano nella protezione degli asset e dell’integrità dei dati delle organizzazioni.

L'articolo Vulnerabilità Critiche in Splunk Enterprise Consentono l’Esecuzione di Codice Remoto proviene da il blog della sicurezza informatica.

@Notizie dall'Italia e dal mondo

In Abruzzo di un’organizzazione criminale (svincolata da contesti di criminalità organizzata di tipo mafioso) formata da cittadini italiani, spagnoli, argentini e colombiani, era dedita al traffico, anche internazionale, di sostanze stupefacenti del tipo hashish e cocaina.

Le sostanze stupefacenti, approvvigionate in Spagna da alcuni indagati residenti nel Paese iberico, venivano trasportate, via gomma, in Italia da corrieri che lo occultavano all’interno di autotreni nella disponibilità dell’organizzazione, per poi essere stoccati in Abruzzo a favore delle piazze di spaccio abruzzesi e marchigiane.

Il sodalizio criminale con vertice, uomini di fiducia e sodali sul territorio nazionale ed estero, poteva contare su punti di riferimento in Spagna e Germania.
Gli inquirenti, durante il lungo periodo d’indagine, hanno posto in essere diversi sequestri, per un totale di circa 100 chili di hashish e 1 chilo di cocaina, riuscendo a ricostruire i vari ruoli degli associati.

Oltre 12 arresti e 2 ulteriori misure cautelari, sono state eseguite diverse perquisizioni nei confronti di altri indagati, residenti in Spagna.

Ad operare sono stati i I Carabinieri del #ROS, che hanno avuto la collaborazione dei militari dei Comandi provinciali di Teramo, Pescara, Fermo, Ascoli Piceno, Brescia e Perugia, e in coordinamento con il #Landeskriminalamt del Nord Reno – Westfalia (Germania), l’Udyco Central della #PoliciaNacional (Spagna), la Police Judiciaire Fédérale di Mons (Belgio) e il Dipartimento Anti-Narcotici della Polizia Nazionale dell’Ucraina, hanno eseguito 14 misure cautelari (10 in carcere, 2 agli arresti domiciliari e 2 obblighi di presentazione alla Polizia Giudiziaria) – emesse dai GIP dei Tribunale de L’Aquila e Teramo, su richiesta rispettivamente della Direzione Distettuale Antimafia de L’Aquila e della Procura Ordinaria di Teramo.

Tutte le persone interessate dal provvedimento sono ritenute responsabili, a vario titolo, di associazione finalizzata al traffico illecito di sostanze stupefacenti o psicotrope e alla produzione, traffico e detenzione illeciti di sostanze stupefacenti o psicotrope (artt. 74 e 73 D.P.R. 309/1990).

L’attività investigativa, avviata nel dicembre 2021 dalla Sezione del ROS de L’Aquila e condotta con numerose e impegnative attività tecniche e dinamiche, è stata sviluppata in coordinamento con la #DCSA (Direzione Centrale per I Servizi Antidroga) anche attraverso la collaborazione di #EUROJUST e #EUROPOL, nonché col supporto della Rete @ON, a guida italiana della #DIA (Direzione Investigativa Antimafia), finanziata dalla Commissione UE.

#rete@ON #PoliceJudiciaireFédérale #НаціональнаполіціяУкраїни

Eccoci qui. Dopo aver trascorso gli ultimi anni leggendo tra il fediverso e il web alternativo, ho deciso di creare il mio posto dove le persone orientate alla libertà possano discutere di libertà nell'informatica e nella società. Lo scopo generale è ricreare le vibrazioni familiari dell'era BBS mettendo insieme strumenti vecchi e moderni, da IRC a Mastodon. Ecco dove spiego tutto:

- [ENG] dmi.unict.it/nfarceri/articles…
- [ITA] dmi.unict.it/nfarceri/articles…

Benvenuti a casa... vostra!

Questo è il primo articolo di questo sito, dove vengono introdotti gli scopi del sito stesso. In sintesi, il sito ha lo scopo di ricreare il feeling familiare e comunitario delle BBS degli anni '80 e '90 aggregando insieme più strumenti, vecchi e mod…

^{www.dmi.unict.it}

At the request of Pirate Party MEP Patrick Breyer, EU Internal Market Commissioner Breton has commented on manufacturers who equip their products with “kill switches”. This question was prompted by a recent case in which the Polish train manufacturer NewAg was found to have installed “kill switches” in several electric multiple units, which switch off the train’s power supply and compressors under certain conditions (location or operating time). Among other things, the manufacturer implemented the switch-off function to prevent the trains from being repaired by competitors and also to prevent the train software from being analysed. In his response, EU Commissioner Breton admits that existing or planned EU rules on the right to repair are largely limited to the protection of consumers and do not apply to businesses.

Patrick Breyer comments:

“The practice by some manufacturers to prevent independent companies from repairing and servicing products is unacceptable. The EU should put clear rules in place to prevent such abuses and protect the rights of users, as well as the competitiveness of independent repair services. The right to repair should also apply to business customers.

However, a mere right to repair falls short of what is needed in the digital era. Users must be given full control over the technology they use in their daily lives. We need a right to modify, customise and improve our legally acquired devices. The fact that copyright law currently prohibits this is disempowering and invites abuse, as the Polish case shows.”

A similar problem is also observed with computer games, where manufacturers make popular games unusable at will. In collaboration with the gamer initiative “Stop killing games”, the pirate party is calling for cultural protection of video games.

patrick-breyer.de/en/stopkilli…