They don’t call slot machines one-armed bandits for nothing. And although it’s getting harder and harder to find slot machines with actual pull-able handles instead of just big buttons, you can easily simulate the handle at home with the right kind of limit switch, as [Andrew Smith] did with their micro slot machine.

This baby slot machine is built around the Adafruit 5×5 NeoPixel grid, which is an add-on for the QT Py. As you’ll see in the brief demo video after the break, the switch actuates on release, which starts the lights a-spinning. [Andrew] says the constraints of the SAMD21-powered QT Py made this a particularly fun challenge.

Whereas most physical slot machines have different reel sequences, this build uses just one. [Andrew] declared hex values to ID each color, and then created the reel manually with different color frequencies. When the lever is released, the columns are animated and slowly to come to rest at a random offset. You can check out the code on GitHub.

youtube.com/embed/NdhRO1JrY0I?…

hackaday.com/2024/09/11/2024-t…

One major flaw of designing societies around cars is the sheer amount of signage that drivers are expected to recognize, read, and react to. It’s a highly complex system that requires constant vigilance to a relatively boring task with high stakes, which is not something humans are particularly well adapted for. Modern GPS equipment can solve a few of these attention problems, with some able to at least show the current speed limit and perhaps an ongoing information feed of the current driving conditions., Trains, on the other hand, solved a lot of these problems long ago. [Philo] and [Tris], two train aficionados, were recently able to get an old speed indicator from a train and get it working in a similar way in their own car.

The speed indicator itself came from a train on the Red Line of the T, Boston’s subway system run by the Massachusetts Bay Transportation Authority (MBTA). Trains have a few unique ways of making sure they go the correct speed for whatever track they’re on as well as avoid colliding with other trains, and this speed indicator is part of that system. [Philo] and [Tris] found out through some reverse engineering that most of the parts were off-the-shelf components, and were able to repair a few things as well as eventually power everything up. With the help of an Arduino, an I/O expander, and some transistors to handle the 28V requirement for the speed indicator, the pair set off in their car to do some real-world testing.

This did take a few tries to get right, as there were some issues with the power supply as well as some bugs to work out in order to interface with the vehicle’s OBD-II port. They also tried to use GPS for approximating speed as well, and after a few runs around Boston they were successful in getting this speed indicator working as a speedometer for their car. It’s an impressive bit of reverse engineering as well as interfacing newer technology with old. For some other bits of train technology reproduced in the modern world you might also want to look at this recreation of a train whistle.

youtube.com/embed/KPlC6PoRjn8?…

hackaday.com/2024/09/11/train-…

A few years back NVIDIA created a dedicated cryptocurrency mining GPU, the CMP 170HX. This was a heavily restricted version of its flagship A100 datacenter accelerator, using the same GA100 chip. It was intended for accelerating Ethash, the Etherium proof-of-work algorithm, and nothing else. [niconiconi] bought one to use for accelerating PCB electromagnetic simulations and put a lot of effort into repairing the card, converting it to water-cooling, and figuring out how best to use this nobbled GPU.

Typically, the GA100 silicon sits in the center of the mighty A100 GPU card and would be found in a server rack, cooled by forced air. This was not an option at home, so an off-the-shelf water-cooling block was wedged in. During this process, [niconconi] found that the board wouldn’t power on, so they went on a deep dive into the power supply tree with the help of a leaked A100 schematic. The repair and modifications can be found in the appendix, right down to the end of the article. It is a long read to get there.

This Nvidia GA100 GPU is severely crippled on this board
NVIDIA has a history of deliberately restricting silicon in consumers’ hands to justify the hefty price tags of its offerings to big businesses, and this board is no different. The plan was to restrict the peak performance of the board to only applications with the same compute requirements as Ethash, specifically memory-intensive algorithms. The FP64 performance was severely limited, but instructions were not removed. This meant the code would run really badly, considering what the GPU is capable of.

The memory was limited to 8 GB, despite some A100 cards hosting a whopping 80 GB. The strategy was to use fuses to limit the crucial instructions, particularly the FP32 FMA and MAD instructions, which are used for multiply-add operations and are crucial for general computing applications. Finally, the PCIe bus was nobbled to run only as a Gen 1 interface with a single lane. They reduced the lane count by removing the coupling capacitors on the PCB, which meant they could just be added later, but it’s still only a slow interface.

[niconconi] went into great detail benchmarking the instruction types, keeping their EM simulation application in mind. After a few tweaks to make it work, they determined it was a good purchase. This article is worth reading for all those hardcore GPU nerds!

If you need a primer on GPU mining, we’ve got you covered. Once you’ve understood proof-of-work crypto, perhaps take a look at Chia?

Thanks to [gnif] for the tip!

hackaday.com/2024/09/11/hackin…

IBM got their PCs and PS/2 computers into schools in the 1980s and 1990s. We fondly remember educational games like Super Solvers: Treasure Mountain. However, IBM had been trying to get into the educational market long before the PC. In 1969, the IBM Schools Computer System Unit was developed. Though it never reached commercial release, ten were made, and they were deployed to pilot schools. One remained in use for almost a decade! And now, there’s a new one — well, a replica of IBM’s experimental school computer by [Menadue], at least. You can check it out in the video below.

The internals were based somewhat on the IBM System/360’s technology. Interestingly, it used a touch-sensitive keypad instead of a traditional keyboard. From what we’ve read, it seems this system had a lot of firsts: the first system to use a domestic TV as an output device, the first system to use a cassette deck as a storage medium, and the first purpose-built educational computer. It was developed at IBM Hursley in the UK and used magnetic core memory. It used BCD for numerical display instead of hexadecimal or octal, with floating point numbers as a basic type. It also used 32-bit registers, though they stored BCD digits and not binary. In short, this thing was way ahead of its time.

[Menadue] saw the machine at the IBM Hursley museum and liked it so much that he proceeded to build a prototype machine based partially on a document shown at the museum that showed the instructions. Further research revealed a complete document explaining the instruction set. The initial prototype was made on a small PCB with a Raspberry Pi Pico W, an OLED display, and key switches, which proved that he understood the system enough to replicate it.
An inside view
After that prototype, work began on the replica. It’s a half-scale model, but it does use a touch keyboard like the original. The attention to detail is nice, with the colours of the case matching and even a small IBM logo replica on the front! It’s made from a metal chassis, with the keyboard surround being plastic (as on the original) so as not to interfere with the touch keyboard. It’s programmed using the same set of instructions as the original — a combination of low-level commands, similar to assembly for microprocessors, but with an extra set of slightly higher-level instructions that IBM called Extra Codes. For a more in-depth explanation, check out the video going over the original system and the prototype replica!

youtube.com/embed/5U0TUGt13F4?…

Photos courtesy of IBM Hursley Museum

hackaday.com/2024/09/11/ibms-1…

This week Jonathan Bennett and Aaron Newcomb chat with Andreas Kling about Ladybird, the new browser in development from the ground up. It was started as part of SerenityOS, and has since taken on a life of its own. How much of the web works on it? How many people are working on the project? And where’s the download button? Listen to find out!

• awesomekling.com/
• ladybird.org/
• ladybird.org/posts/fork/
• ladybird.org/posts/announcemen…
• ladybird.org/posts/why-ladybir…

youtube.com/embed/ea086YeIrPA?…

Did you know you can watch the live recording of the show Right on our YouTube Channel? Have someone you’d like us 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

hackaday.com/2024/09/11/floss-…

Oscilloscopes are one of our favorite tools for electronics development. They make the hidden dances of electrons visually obvious to us, and give us a clear understanding of what’s actually going on in a circuit.

The question few of us ever ask is, how do they work? Most specifically—how do you design a circuit that’s intended to measure another circuit? Aleksa Bjelogrlic has pondered that very idea, and came down to explain it all to us at the 2023 Hackaday Supercon.

All Up Front

youtube.com/embed/6kINL2e2XGs?…
Aleksa’s scope design had humble beginnings.
Aleksa has spent five years designing an open-source oscilloscope known as the ThunderScope. He wanted an oscilloscope that could measure a circuit while streaming out samples at speed to a computer, so he decided to build his own. His idea was to put the analog part of a high-speed scope in a box, while offloading the digital processing to an attached computer. This would allow the software side of things to be regularly updated to stay with the times. It would be easy to add new triggers or protocol decoders to the setup without having to mess with the hardware.

His early experiments saw him streaming samples from a test scope he built, but it wasn’t perfect. He used USB 3 Gen 1, but it was only giving him 350 MB/s transfer rates. He needed closer to 1 GB/sec to properly stream samples of high-speed signals. He also had issues with his front-end design, with poor frequency response. He soon switched over to PCI-Express for higher transfer rates, and built a new scope with a better front-end. This was the first revision of ThunderScope. Later revisions improved the front end further, tackled clock-generator issues, and generally refined the design into something more functional and useful.
The front end has been one of the main areas of improvement and revision as Aleksa has worked on the ThunderScope.
The development process is mere context, though. The real purpose of Aleksa’s talk was to dive into the nitty gritty of oscilloscope front-end designs. While his scope has had four major revisions, the front end has had over a dozen updates. The front end’s job is to take an analog signal, and finesse it into something that the scope’s analog-to-digital converter can actually handle. It’s job is, in part, to act as an electrical interface to allow the scope to measure all kinds of different signals. Aleksa explains that it can allow you to view AC signals superimposed on large DC voltages, or measure large signals beyond the voltage range of the scope’s ADC. It can also help scale signals that might otherwise be out of range for the ADC itself.

Aleksa explains input impedance, capacitance of the front end, and why you have to compensate a probe to suit your individual scope. He also covers the eternal challenge facing the designer—minimizing noise while maximising bandwidth, while also maintaining a flat response from DC all the way up to high frequency signals. And of course, you need to be able to measure and quantify how your front end is performing, so Aleksa dips into the basics in that regard.

AC and DC coupling is also covered. This is critical for when you want to look at an AC waveform without all that annoying DC bias in the way. Naturally, this is achieved with an in-line capacitor, which blocks DC while allowing the AC component to pass. Then there’s the helpful discussion about how resistors come with stray capacitance and inductance “for free”—and capacitors in turn come with resistance and inductance, too. When you’re chasing around weird dips in your response curve, you’ve got to be across these things.
That’s a horrifying response curve, but Aleksa was eventually able to track down the culprit and eliminate the dip.
If you’ve ever considered creating your own oscilloscope from scratch, Aleksa’s talk is a great primer. It’s really useful stuff. After all, getting the front end right is as important as getting the right tires on your car. If it’s not up to the task, all your measurements will be suspect from the drop. It’s a deep and rich topic, and one that you could spend years studying in detail. Indeed, Aleksa has, and his work on the ThunderScope is the ultimate proof of that.

hackaday.com/2024/09/11/superc…

La Cybersecurity and Infrastructure Security Agency ( CISA ) degli Stati Uniti D’America ha emesso un avvertimento su tre pericolose vulnerabilità che vengono attivamente sfruttate dagli aggressori. Questi errori minacciano molti programmi e sistemi popolari, creando seri rischi per organizzazioni e utenti.

La prima vulnerabilità, CVE-2016-3714 (punteggio CVSS: 8,4), colpisce ImageMagick, un popolare pacchetto software di elaborazione delle immagini. Il problema è legato a un’insufficiente convalida dei dati di input, che porta alla possibilità di esecuzione di codice arbitrario nel sistema durante l’elaborazione di un’immagine appositamente predisposta.

Una seconda vulnerabilità, CVE-2017-1000253 (punteggio CVSS: 7,8), è stata scoperta nel kernel Linux. È correlato alla corruzione del buffer dello stack nella funzione load_elf_binary(). Lo sfruttamento di questa falla consente a un utente malintenzionato locale di aumentare i privilegi e ottenere l’accesso non autorizzato ai dati critici del sistema.

La terza vulnerabilità, CVE-2024-40766 (punteggio CVSS: 9,8), colpisce il sistema operativo SonicWall SonicOS, utilizzato nei firewall. Una falla nel controllo degli accessi consente agli aggressori di accedere alle risorse di sistema e causare il crash del firewall. Nonostante la mancanza di informazioni sui possibili casi di utilizzo della vulnerabilità negli attacchi, il suo impatto sulla sicurezza della rete rimane critico.

La CISA consiglia di installare urgentemente gli aggiornamenti forniti dagli sviluppatori o di rifiutarsi di utilizzare software vulnerabile se non sono disponibili soluzioni. Il termine ultimo per l’attuazione delle misure è il 30 settembre 2024.

L’agenzia sottolinea la necessità di attuare rapidamente misure di protezione e aggiornamenti. Si consiglia alle organizzazioni di non ritardare l’aggiornamento dei propri sistemi per prevenire possibili attacchi informatici e violazioni dei dati.

L'articolo Dal CISA tre bug di sicurezza che devono essere risolti entro il 30 Settembre proviene da il blog della sicurezza informatica.

Following in the tracks of unconventional science projects, [The Thought Emporium] seeks to answer the question of whether you can use a potato as a photograph recording medium. This is less crazy than it sounds, as ultimately analog photographs (and photograms) is about inducing a light-based change in some kind of medium, which raises the question of whether there is anything about potatoes that is light-sensitive enough to be used for capturing an image, or what we can add to make it suitable.

Unfortunately, a potato by itself cannot record light as it is just starch and salty water, so it needs a bit of help. Here [The Thought Emporium] takes us through the history of black and white photography, starting with a UV-sensitive mixture consisting out of turmeric and rubbing alcohol. After filtration and staining a sheet of paper with it, exposing only part of the paper to strong UV light creates a clear image, which can be intensified using a borax solution. Unfortunately this method fails to work on a potato slice.

The next attempt was to create a cyanotype, which involves covering a surface in a solution of 25 g ferric ammonium oxalate, 10 g of potassium ferricyanide and 100 mL water and exposing it to UV light. This creates the brilliant blue that gave us the term ‘blueprint’. As it turns out, this method works really well on potato slices too, with lots of detail, but the exposure process is very slow.

Speeding up cyanotype production is done by spraying the surface with an ammonium oxalate and oxalic acid solution to modify the pH, exposing the surface to UV, and then spraying it with a 10 g / 100 mL potassium ferricyanide solution, leading to fast exposure and good details.

This is still not as good on paper as an all-time favorite using silver-nitrate, however. These silver prints are the staple of black and white photography, with the silver halide reacting very quickly to light exposure, after which a fixer, like sodium thiosulfate, can make the changes permanent. When using cyanotype or silver-nitrate film like this in a 35 mm camera, it does work quite well too, but of course creates a negative image, that requires inverting, done digitally in the video, to tease out the recorded image.

Here the disappointment for potatoes hit, as using the developer with potatoes was a soggy no-go. Ideally a solution like that used with direct positive paper that uses a silver solution suspended in a gel, but creates a positive image unlike plain silver-nitrate. As for the idea of using the potato itself as the camera, this was also briefly attempted to by using a pinhole in a potato and a light-sensitive recording surface on the other side, but the result did indeed look like a potato was used to create the photograph.

youtube.com/embed/BlWyKKJF0r4?…

hackaday.com/2024/09/11/using-…

Everyone loves, and should respect, lithium-ion batteries. They pack a ton of power and can make our projects work better. I’ve gathered a number of tips and tricks about using them over the years, based on my own hacking and also lessons I’ve learned from others.

This installment includes a grab-bag of LiIon tricks that will help you supercharge your battery use, avoid some mistakes, and make your circuits even safer. Plus, I have a wonderful project that I just have to share.

Hot-swapping Cells

When your device runs out of juice, you might not always want to chain yourself to a wall charger. Wouldn’t it be cool if you could just hot-swap cells? Indeed it is, I’ve been doing it for years, it’s dead simple to support, but you can also do it wrong. Let me show you how to do it right!

Recently, a new handheld has hit the hacker markets – the Hackberry Pi. With a Blackberry keyboard and a colour screen, it’s a pretty standard entry into the trend of handheld Pi Zero-backed computers with Blackberry keyboards. It’s not open-source and the author does not plan to open-source its hardware, so I want to make it absolutely clear I don’t consider it hacker-friendly or worth promoting. It did publish schematics, though, and these helped me find a dangerous mistake that the first revision made when trying to implement LiIon battery hot-swap.
This is not how you connect batteries in parallel,
It uses BL-5C cells, which are widely available as aftermarket batteries for Nokia phones. It’s a smart choice, though it’s worth remembering that vendors constantly inflate the capacity on the label, and my gut feel is that the more inflated the number is, the more shady the cell you’re getting. Remember, there’s a physical limit to the capacity you can shove into a certain cell volume, with 18650s limited to about 3500 mAh, as the market offerings show. (And if you try to put more capacity into a cell of certain volume, you get the Galaxy Note 7. Ahem.)

The batteries in the Hackberry Pi should be hot-swappable – no supercaps, they’re just in parallel with nothing in between the cells. Nothing in between? Question – what happens when you connect two batteries, one charged and one discharged, in parallel? Remember, LiIon batteries can give out a ton of current, and phone batteries doubly so due to the GSM modem peak current requirements. Decent voltage difference, very low resistance – you get a lot of current flowing, discharging the full cell needlessly or causing a brownout at best, and charring PCB tracks at worst.
but just two more components make it a fair bit better.
The easy solution is to use PTC resettable fuses in series with the positive or negative terminal, either between each cell, or just one between two cells. If current surges sharply, the fuse will heat up and increase its resistance, limiting the current.

But remember, a fuse’s current rating is deceiving, and a 2 A fuse won’t actually trip at exactly 2.1 A. This is beneficial for you, though – while doing hotswap, one cell will have to produce twice the current than normally, even if for a short moment. Also, remember to size the cell protection fuse not just for device consumption, but also the charging current it will receive!

It’s certain that the new Hackberry Pi revision will fix this, and if you have the first revision, just swap batteries carefully and you will be 100% fine. Hotswap doesn’t have to be complicated – now you all know how to do a very simple form of it. Oh, and, having adding the fuse, you can easily get a good few extra features with only a few components, like, say, polarity protection!

The Polarity Hacks

With 18650 holders, it’s easy to insert a cell the wrong way by accident – I’ve burned out a good few boards like that, spending precious hours and dollars replacing burned out components. A 18650 cell holds a ton of energy and can burn out a lot of silicon very easily. Or if you’re using pouch cells using JST-PH connectors, you have to watch out for two polarity conventions. In short, polarity reversal is a real risk. How do you protect from it?

The reverse polarity crowbar circuit is a dead simple way to add polarity protection – all you need is a diode across the battery, placed after the fuse, flipped in a way that it will conduct when the polarity is wrong, tripping the fuse before any circuitry is damaged. The diode’s rating has to be higher than the fuse’s trip point – otherwise, the diode will burn out before the fuse trips, negating the circuit. I’ve tested this, it works, it’s now being manufactured in hundreds.

You might also want the user, whether you or someone else (especially someone else!) to quickly notice that the polarity is flipped. The solution is simple – add a LED and a resistor flipped in a way it lights up when the cell is reversed, before the fuse. Use a red or orange LED to make it crystal clear that something is wrong; don’t use green or blue, or any colours that often mean “the device is working normally”; add silkscreen markings to indicate that this is a “wrong polarity” LED.

Back to cells with JST-PH connectors. Are you developing a project that will get into hackers’ hands, and you don’t want to have them rewire their entire LiIon cell arsenal just for your device? Thankfully, 0 R resistors save the day; it’s dead simple to add two pairs of 0603 0R’s next to a JST-PH 2-pin connector. Make one polarity the default, and leave the option of switching the polarity in there. Again, this goes before the fuse, and before the reverse polarity LED, too. Of course, your users will have to make sure the red wire goes to positive, but at least you’re helping them get there.

This quickly, we have dealt with a number of polarity problems, using barely any components, all of them cheap, no fancy ICs. Your boards deserve to be fail-proof, serving you no matter the mistakes you make.

A New 18650 Holder Enters The Scene

Leaf contact holders are great. Unlike spring holders, they’re low-inductance, high-current, resillient to shocks, reliable, and cheap to find. Unfortunately, the leaf often catches on the cell’s heatshrink ends when you unplug the battery, slowly tearing it off piece by piece, and at some point even causing the positive terminal protective ring to detach – which risks a massive short-circuit as you unplug the battery or just drop the holder hard enough. Not great!

I’ve developed a pretty unique holder for 18650s, that I currently use for a pretty substantial portable device project of mine. It’s got all the advantages of spring holders, but it wraps around the battery fully, protecting it from shocks and the elements, and closes with a twist-on locking cap. Plus, it’s belt-mountable, thanks to a 3D-printed holder. It lends itself wonderfully to hotswap, too! Most of all, it’s fully 3D printable. All you need is some threaded inserts and some leaf contacts from Keystone that I found on Mouser – a baggie with 25 of them is quite cheap, and worth the money. (Remember to scroll through categories for things like battery contacts, you will find cool stuff!) There are definitely drawbacks to this type of holder, but it’s seriously great.
Just a few threaded inserts and screws, and off you go!
It’s parametric, designed in FreeCAD, so you can change a fair few parameters without breaking a sweat. The holder is designed for quick swap – just twist the cap and the battery falls out. Swapping 18650 cells is a cakewalk. High current consumption: tested; portability: tested; not damaging the cell wrappers: tested. I’ve been actively using these holders for about nine months now – they fulfilled their purpose and far more.

There’s something that makes it feel like military equipment, but I can assure you that it’s not designed by the lowest bidder. Put these on a belt, screw these into a project, or slap two of them together back to back – maybe even lengthen it and use three cells in series! Thanks to someone’s advice from Twitter, there are also vent holes at the positive terminal’s place. (Of course, if your cell starts venting, you have a big problem on your hands no matter what you’re using.) Still, it’s got these holes, in addition to ten other features. And it’s printable vertically with no supports.

Are there possible failure modes? Absolutely. The main one is the cylinder breaking across the layer lines under pressure, especially if you drop it. I’ve tried printing the holder laying down, so that layer lines are aligned differently, but cleaning the tube from internal supports is damn brutal and the tolerances for the 18650 inside are pretty tight. I’m going to pick up a roll of PLA-Plus, since it supposedly is more strong, and print a new set of holders. If you print it, let us know!

Another failure mode is the spring’s compressing over time. I might be overcompressing the metal, so I just ought to check the datasheets and adjust the width. Of course, strong compression is a plus, but it’s of no use if the holder starts being super bump-sensitive after a few months of use. Last but not least, the positive wire is a failure point, though the channel i’ve recently introduced mostly fixes that.

More To Come

There are a few additions in the queue for the v3 holder. One is unifying the threaded inserts so that you don’t have to buy too many different ones, and improving mounting for the belt holster to limit the molten plastic backflow. Another is adding strips on the side that’d be a base for a long metal plate, which would acts as extra backing for the 18650 holder. The only problem is finding a suitable metal plate – flat, 70 mm long, about 4 mm wide, with screw holes alongside, or, at least, on both ends. Anyone have any ideas, especially if it’s something commonly found that can be repurposed?

I’m currently working on a custom PCB for this holder – involving protection, fuse holding, reverse polarity protection and warning LED, and maybe even an opamp circuit for roughly measuring the battery voltage. In short, including all of the tips shared here.

What are your favorite tricks for using lithium batteries?

Dopo tre anni di sviluppo, il team Flipper Zero ha annunciato il rilascio di una nuova versione firmware (1.0). L’aggiornamento include un nuovo sottosistema NFC, supporto JavaScript, caricamento dinamico di applicazioni di terze parti e molto altro.

Come scrive Pavel Zhovner nel suo canale Telegram : “Questa è la versione principale in 3 anni di sviluppo. In esso speriamo di sistemare le principali API per gli sviluppatori e di non interrompere le cose fondamentali per qualche tempo.”

Molte le differenze e i miglioramenti

Gli sviluppatori affermano che il nuovo firmware implementa 89 protocolli radio, 20 protocolli RFID e aggiunge 4 tipi di telecomandi IR universali. Anche Bluetooth e NFC sono stati accelerati, è apparso il supporto JavaScript, è apparso il caricamento dinamico di applicazioni di terze parti e la durata della batteria del dispositivo in modalità standby è ora di un mese.

Sebbene alcune delle funzionalità elencate dagli sviluppatori fossero già presenti nelle versioni precedenti del firmware Flipper Zero, potrebbero non funzionare in modo molto stabile e gli utenti potrebbero riscontrare problemi. La versione attuale dovrebbe fornire maggiore stabilità e prestazioni migliori.

In un post dedicato al rilascio del firmware 1.0, il team di Flipper Zero evidenzia le seguenti caratteristiche chiave.

Uno sguardo alle nuove funzionalità

• Caricamento dinamico delle app : gli utenti potranno installare app sviluppate dalla community da un catalogo, risparmiando memoria di sistema eseguendo app dai file FAP (Flipper Application Package) sulla scheda microSD.

• Aggiornamento del sottosistema NFC : NFC è stato riscritto poiché gli sviluppatori hanno completamente riprogettato la libreria RFAL, migliorando la velocità di lettura delle carte, aggiungendo il supporto per nuovi tipi di carte (ad esempio, ICODE® SLIX, FeliCa™ Lite-S) e anche attivando il plug-in nel sistema. E i dump delle carte MIFARE Classic® possono ora essere visualizzati e modificati direttamente nell’applicazione mobile Flipper.

• Supporto JavaScript : Flipper Zero ora supporta JavaScript, il che dovrebbe rendere lo sviluppo di app più accessibile. Come scrive Pavel Zhovner: “Per ora le funzioni API non raggiungono ciò che può essere fatto tramite C/C++, ma gradualmente diventerà più interessante.”

• Miglioramenti sub-GHz : aggiunto il supporto per 89 protocolli radio, la possibilità di ascoltare radio analogiche e un nuovo formato file BinRAW per un’archiviazione e uno scambio di segnali più efficienti.

• Miglioramenti IR : sono presenti nuovi telecomandi IR universali per vari dispositivi (TV, condizionatori, sistemi audio e proiettori) e supporto per apparecchiature IR esterne con LED più potenti.
• Miglioramenti generali del sistema: la durata della batteria ora raggiunge un mese in modalità standby. Le velocità di trasferimento Bluetooth con i dispositivi Android sono aumentate fino a due volte e gli aggiornamenti del firmware vengono ora scaricati il ​​40% più velocemente tramite Bluetooth (il programma di aggiornamento Flipper Zero supporta l’ algoritmo di compressione heatshrink ).

• Miglioramenti IR : sono presenti nuovi telecomandi IR universali per vari dispositivi (TV, condizionatori, sistemi audio e proiettori) e supporto per apparecchiature IR esterne con LED più potenti.
• Miglioramenti generali del sistema: la durata della batteria ora raggiunge un mese in modalità standby. Le velocità di trasferimento Bluetooth con i dispositivi Android sono aumentate fino a due volte e gli aggiornamenti del firmware vengono ora scaricati il ​​40% più velocemente tramite Bluetooth (il programma di aggiornamento Flipper Zero supporta l’ algoritmo di compressione heatshrink ).

Sul sito Flipper Zero è già disponibile la versione firmware 1.0 , e la sua installazione è possibile sia via Bluetooth da dispositivo mobile che da computer utilizzando l’applicazione qFlipper.

L'articolo Flipper Zero rilascia il Firmware 1.0! Tutto un altro Mondo per fare Hacking proviene da il blog della sicurezza informatica.

Il team di Malwarebytes ha scoperto che il gruppo ransomware RansomHub utilizza lo strumento legittimo TDSSKiller per disabilitare gli strumenti EDR su un dispositivo. Oltre a TDSSKiller, i criminali informatici utilizzano anche LaZagne per raccogliere dati. Questi programmi sono conosciuti da tempo tra i criminali informatici, ma questa è la prima volta che vengono utilizzati da RansomHub. LaZagne è un’utilità per estrarre password da varie applicazioni e sistemi, che può aiutare nei test di penetrazione.

TDSSKiller, originariamente sviluppato da Kaspersky Lab per rimuovere i rootkit, è stato utilizzato per disabilitare i sistemi EDR. Dopo aver condotto una ricognizione e identificato gli account con privilegi elevati, RansomHub ha tentato di disabilitare il servizio di sicurezza MBAMService.

Lo strumento è stato eseguito da una directory temporanea utilizzando un nome file generato dinamicamente per rendere difficile il rilevamento. Poiché TDSSKiller è un programma legittimo con un certificato valido, molti sistemi di sicurezza non riconoscono che gli hacker criminali stanno effettuando azioni malevole.

Dopo aver disabilitato i sistemi di sicurezza, RansomHub ha lanciato lo strumento LaZagne per raccogliere credenziali dai sistemi infetti. Il programma estrae le password da varie applicazioni come browser, client di posta elettronica e database, consentendo agli aggressori di aumentare i propri privilegi e spostarsi lateralmente attraverso la rete. In questo caso l’obiettivo dei criminali informatici era quello di ottenere l’accesso alla banca dati che permettesse di controllare i sistemi critici.

Durante l’attacco, LaZagne ha creato più di 60 file, la maggior parte dei quali conteneva login e password. Per nascondere le tracce del programma, gli hacker hanno anche cancellato alcuni file una volta completata l’operazione.

Rilevare LaZagne è abbastanza semplice, poiché la maggior parte dei programmi antivirus lo contrassegna come malware. Tuttavia, se TDSSKiller veniva utilizzato per disabilitare i sistemi di protezione, l’attività del programma diventa invisibile alla maggior parte degli strumenti.

ThreatDown incoraggia le organizzazioni a prendere ulteriori precauzioni per proteggersi da tali attacchi. In particolare, si consiglia di limitare l’uso di driver vulnerabili come TDSSKiller e monitorare i comandi sospetti utilizzati sui sistemi. È inoltre importante segmentare la rete e isolare i sistemi critici per ridurre al minimo il rischio che le credenziali vengano compromesse.

L'articolo Quando l’Antivirus diventa un’Arma! RansomHub utilizza TDSSKiller per infiltrarsi nelle reti proviene da il blog della sicurezza informatica.

After 47 years it’s little wonder that the hydrazine-powered thrusters of the Voyager 1, used to orient the spacecraft in such a way that its 3.7 meter (12 foot) diameter antenna always points back towards Earth, are getting somewhat clogged up. As a result, the team has now switched back to the thrusters which they originally retired back in 2018. The Voyager spacecraft each have three sets (branches) of thrusters. Two sets were originally intended for attitude propulsion, and one for trajectory correction maneuvers, but since leaving the Solar System many years ago, Voyager 1’s navigational needs have become more basic, allowing all three sets to be used effectively interchangeably.

The first set was used until 2002, when clogging of the fuel tubes was detected with silicon dioxide from an aging rubber diaphragm in the fuel tank. The second set of attitude propulsion thrusters was subsequently used until 2018, until clogging caused the team to switch to the third and final set. It is this last set that is now more clogged then the second set, with the fuel tube opening reduced from about 0.25 mm to 0.035 mm. Unlike a few decades ago, the spacecraft is much colder due energy-conserving methods, complicating the switching of thruster sets. Switching on a cold thruster set could damage it, so it had to be warmed up first with its thruster heaters.

The conundrum was where to temporarily borrow power from, as turning off one of the science instruments might be enough to not have it come back online. Ultimately a main heater was turned off for an hour, allowing the thruster swap to take place and allowing Voyager 1 to breathe a bit more freely for now.

Compared to the recent scare involving Voyager 1 where we thought that its computer systems might have died, this matter probably feels more routine to the team in charge, but with a spacecraft that’s the furthest removed man-made spacecraft in outer space, nothing is ever truly routine.

hackaday.com/2024/09/11/voyage…