Last time, I gave you an overview of what you get from I2C, basics like addressing, interface speeds, and a breakdown of pullups. Today, let’s continue looking into I2C capabilities and requirements – level shifting, transfer types, and quirks like combined transfers or clock stretching.

Level Shifting

Today, the overwhelming majority of I2C devices are 3.3 V logic. but this wasn’t always the case. If you work with old tech or with I2C on VGA/DVI/HDMI ports, you will see 5 V I2C networks, and if you work with very new tech, you will see 1.8 V I2C networks; rarely, you might even see 2.5 V networks!

Interfacing 5 V devices with a 3. 3V controller, it might not be necessary to level shift. You need to a) wire pullups to 3.3 V, and b) win the device input tolerance lottery. Same goes interfacing 3.3 V devices with 1.8 V hosts – wire up pullups to 1.8 V and pray to the stars. It can work in production – here’s Adafruit taking the 3.3 V-pulled-up Raspberry Pi I2C bus, and connecting it to a 5 V-powered MCP23017 chip that drives a 5 V-connected HD44780 display.

If your arrangement is different, or you’re experiencing a problem, you will want a level shifter circuit. At their simplest, two N-FETs like 2N7002 will do wonders. If you want smaller PCB footprint, better parameters, or more channels, there are level shifter chips, with many of them wonderfully suited for I2C (read the datasheet!). As we’ve featured before, some shifter ICs are too smart for their own good, while others will do just fine – if in doubt, remember to use your logic analyzer judiciously.

Two Ways To Talk

There are two kinds of I2C transfers you could expect to perform – I’d call them “simple transfers” and “register transfers”. With simple transfers, you send an address, and after the device ACKs, you either send or receive a single byte – it’s just like working with a shift register. With register transfers, you send an address, then a register number, and the device sends you the “contents” of that register – it’s more like working with an SPI display.

The PCF8574 is an I2C GPIO expander that does simple transfers. It has eight GPIO pins, and it only does simple transfers. How does that work, given it does both input and output? Well, the PCF8574 has only three possible states for all pin, with two of them combined together. The “Low” state (writing 0) is a hard pull down to GND. The “High” state (writing 1) is a weak pull to VCC – which also makes the pin work as an input with a pullup enabled. To check the input state, just read the expander state, and see if any of the pins you’ve set to 1 are now reading as 0. You can’t do a lot of high-side driving, sure, but you can still drive LEDs and check buttons, plus, this scheme is dead simple and covers a ton of use cases.

A good few I2C devices use simple transfers – the LM75 temperature sensor, for instance, only has to return temperature. You can read out multiple bytes at once, of course – simple transfers aren’t inherently limited to a single byte! PCF8575, the 16-bit sister of the PCF8574, has 16 GPIOs, I’ve used simple transfers with an ATMega328P keypard controller I created at some point – it would return keycodes, taken from a ring buffer. However, at some point, I decided to add more features to it, like ADC reading to help out a Pi Zero it was connected to, and had to upgrade it to register transfers.

The MCP23017 is a GPIO expander that uses register transfers. It has 16 GPIO pins, and a ton of features, each with their own register. Since one register contains 8 bits and we have 16 GPIOs, there are two registers per feature, and as such, there are two registers for pin directions, two for enabling integrated pullups, two for reading out input states, two for setting pins as outputs, and so on. They can even be arranged in two different ways, one backwards compatible with a different chip, by changing a bit in the status register! It’s a fair bit more complex chip than the PCF8574, but the complexity pays off where you need it.

I2C EEPROMs work with register transfers, too – some use 8-bit addresses, which allows for up to 256 bytes of storage. Higher-capacity EEPROMs use 16-bit (two-byte) addresses, where you’re expected to send in two bytes before you can read data out; if you try to read from such an EEPROM using two-byte addresses, you will just read back zeroes, so beware!

Quirks

But what if the device can’t keep up with the multi-byte transactions that your microcontroller is asking for? Maybe you have an EEPROM that needs time before it can read out a value from its internal memory so that it your MCU can receive it, maybe it’s a sensor that needs to average some values quickly and it just can’t catch up with even the lax timing requirements of 100 kHz I2C.

There’s a solution – it’s called clock stretching, and it’s basically an I2C device holding SCL low after receiving a byte, extending ACK state for a long time, until it can actually return meaningful data. As long as SCL is low, the controller should wait for the device. It’s essentially a way for a device to say “wait, not yet, I need some time before I can give you what you’re looking for”.

Raspberry Pi didn’t support clock stretching for the longest time due to a silicon bug. Every single Pi version before Pi 4 couldn’t handle clock stretching, including all of the Pi Zero versions released at the time of writing this article. The workaround, if you need one – use software I2C. It consumes more CPU since you have to use a kernel driver that bitbangs the bus, but it does have functional clock stretching. And of course the Raspberry Pi isn’t alone: if you are likely to need clock stretching, make sure that the microcontroller hardware peripheral supports it properly.

Next time, we dive into the physical layer, look at logic analyzer traces, understand how communication happens, and the ways it can break despite our best intentions.

hackaday.com/2024/09/05/i2c-fo…

L’Organizzazione Mondiale della Sanità (OMS) ha pubblicato i risultati di un esperimento su larga scala che probabilmente metterà fine al dibattito di lunga data sugli effetti dei telefoni cellulari sullo sviluppo del cancro al cervello. Gli scienziati hanno analizzato più di 5.000 articoli scientifici e selezionato 63 studi condotti dal 1994 al 2022 per uno studio dettagliato.

I risultati del lavoro sono stati pubblicati sulla rivista scientifica Environmental International .

Il dibattito sui potenziali pericoli dei telefoni cellulari risale al 1993, quando David Reynard, residente in Florida, fece causa alla NEC America. Ha affermato che le radiazioni di un telefono cellulare hanno contribuito allo sviluppo di un tumore al cervello in sua moglie. Sebbene la causa sia stata archiviata nel 1995, il caso ha suscitato timore nella mente di molte persone.

Nel 2011 l’OMS e l’Agenzia internazionale per la ricerca sul cancro (IARC) hanno deciso di classificare le radiazioni dei telefoni cellulari come possibili cancerogeni per l’uomo. E nel 2016, un altro studio ha dimostrato che le radiazioni dei gadget possono effettivamente causare cancro al cervello e alle ghiandole surrenali nei topi e nei ratti.

Tuttavia, un nuovo esperimento condotto da esperti dell’Agenzia australiana per la protezione dalle radiazioni e la sicurezza nucleare (ARPANSA) smentisce queste paure. Gli scienziati hanno scoperto che, nonostante la rapida crescita dell’uso dei telefoni cellulari negli ultimi vent’anni, non si è verificato un aumento corrispondente dei casi di cancro alla testa o al collo.

Il team ha analizzato gli effetti delle onde radio provenienti dalle torri cellulari e ha anche studiato le occupazioni associate a una maggiore esposizione alle radiazioni in radiofrequenza. In entrambi i casi non è stata trovata alcuna connessione con lo sviluppo del cancro.

Mark Ellwood, professore di epidemiologia all’Università di Auckland e coautore dello studio, ha osservato che il lavoro copre un’ampia gamma di fonti di radiazioni a radiofrequenza. Hanno preso in considerazione non solo i telefoni cellulari, ma anche altri dispositivi: radio, televisori, baby monitor, router Wi-Fi, radar, nonché numerosi dispositivi industriali e medici.

Le conclusioni degli scienziati sono logiche, data l’enorme prevalenza degli smartphone nel mondo moderno. Secondo alcune stime ne fanno uso tre quarti della popolazione mondiale. Gli americani, ad esempio, trascorrono in media 4 ore e 37 minuti al giorno sui loro telefoni e questi numeri non fanno che aumentare con l’avanzare della tecnologia. Nonostante ciò, il tasso di incidenza del cancro al cervello è rimasto praticamente invariato dal 1982.

Ken Karipidis dell’ARPANSA afferma che il nuovo studio si basa su molti più dati rispetto al campione IARC del 2011. Gli scienziati hanno anche sottolineato di aver osservato persone che utilizzano i telefoni cellulari più frequentemente e per lunghi periodi – più di 10 anni.

L'articolo OMS Pubblica Uno Studio Decisivo: Nessun Legame tra Cellulari e Cancro al Cervello proviene da il blog della sicurezza informatica.

What can you do with a cheap Linux machine with limited flash and only a single free GPIO line? Probably not much, but sometimes, just getting root to prove you can is the main goal of a project. If that happens to lead somewhere useful, well, that’s just icing on the cake.

Like many interesting stories, this one starts on AliExpress, where [Easton] spied some low-cost WiFi repeaters, the ones that plug directly into the wall and extend your wireless network another few meters or so. Unable to resist the siren song, a few of these dongles showed up in the mailbox, ripe for the hacking. Spoiler alert: although the attempt on the first device had some success by getting a console session through the UART port and resetting the root password, [Easton] ended up bricking the repeater while trying to install an OpenWRT image.

The second attempt, this time on a different but similar device, proved more fruitful. The rudimentary web UI provided no easy path in, although it did a pretty good job enumerating the hardware [Easton] was working with. With the UART route only likely to provide temptation to brick this one too, [Easton] turned to a security advisory about a vulnerability that allows remote code execution through a specially crafted SSID. That means getting root on these dongles is as simple as a curl command — no hardware hacks needed!

As for what to do with a bunch of little plug-in Linux boxes with WiFi, we’ll leave that up to your imagination. We like [Easton]’s idea of running something like Pi-Hole on them; maybe Home Assistant would be possible, but these are pretty resource-constrained machines. Still, the lessons learned here are valuable, and at this price point, let the games begin.

hackaday.com/2024/09/05/gettin…

Executive summary

Tropic Trooper (also known as KeyBoy and Pirate Panda) is an APT group active since 2011. This group has traditionally targeted sectors such as government, healthcare, transportation and high-tech industries in Taiwan, the Philippines and Hong Kong. Our recent investigation has revealed that in 2024 they conducted persistent campaigns targeting a government entity in the Middle East, starting in June 2023.

Sighting this group’s TTPs in critical governmental entities in the Middle East, particularly those related to human rights studies, marks a new strategic move for them. This can help the threat intelligence community better understand the motives of this threat actor.

The infection came to our attention in June 2024, when our telemetry gave recurring alerts for a new China Chopper web shell variant (used by many Chinese-speaking actors), which was found on a public web server. The server was hosting an open-source content management system (CMS) called Umbraco, written in C#. The observed web shell component was compiled as a .NET module of Umbraco CMS.

In our subsequent investigation, we looked for more suspicious detections on this public server and identified multiple malware sets. These include post-exploitation tools, which, we assess with medium confidence, are related to and leveraged in this intrusion.

Furthermore, we identified new DLL search-order hijacking implants that are loaded from a legitimate vulnerable executable as it lacks the full path specification to the DLL it needs. This attack chain was attempting to load the Crowdoor loader, which is half-named after the SparrowDoor backdoor, detailed by ESET. During the attack, the security agent blocked the first Crowdoor loader, prompting the attackers to switch to a new, previously unreported variant, with almost the same impact.

We attribute this activity to the Chinese-speaking threat actor known as Tropic Trooper with high confidence. Our findings reveal an overlap in the techniques reported in recent Tropic Trooper campaigns. The samples we found also show a high overlap with samples previously attributed to Tropic Trooper.

Background

In June 2024, we detected a new version of the well-known China Chopper web shell. Further investigation followed as it represents a module within Umbraco CMS, receiving commands via the Umbraco controller.

On the same public server hosting Umbraco, we found other suspicious implants and malware clusters, which appeared to be part of the same attack. The installed security agent kept detecting these malware implants, and the attackers tried to drop additional post-exploitation tools to achieve their main objectives: in this intrusion we assess with high confidence that the motive is cyber espionage.

The table below shows the discovered malware families related to this intrusion. The subsequent sections of this report provide a technical analysis of these malware clusters.

Technical details

Webshells — Umbraco modules

The module exhibits characteristics commonly associated with malicious activity, including obfuscation and dynamic execution of commands. The commands are received and dispatched by the
umbraco_bind_aspx module, as can be seen below.

Malicious module found inside Umbraco CMS on the compromised server

The
umbraco_bind_aspx is a class generated by the ASP.NET framework for an ASPX page within Umbraco CMS. The framework automatically calls the __BuildControlTree() function. This function, implemented by the attackers, is responsible for calling malicious code as the argument to the RenderMethod() function. Also, event validation, which is a security feature in ASP.NET that prevents unauthorized events from being logged on the server, is disabled by setting EnableEventValidation to false as can be seen in the screenshot below.

Malicious function implementing China Chopper registered as a callback function

__Render__control1() is the main malicious function. As can be seen in the screenshot below, a Base64 string is decoded and then executed via dynamic evaluation using JavaScript.

Obfuscated dynamic JS code execution

The script employs multiple Base64 decodings before the final JavaScript payload is generated and executed. The resulting code resembles the known functionality associated with the China Chopper web shell, a popular web shell used by attackers for remote access and control over compromised web servers.

China Chopper web shell functionality

The attackers then started dropping various samples on this server, notably a dropper that was pushing more compiled variants carrying the same functionality, but using different module names. These module names all match the pattern
App_Web_{8}[a-z0-9].dll. In our telemetry, we noticed exploitation attempts of several CVEs (CVE-2021-34473, CVE-2021-34523 and CVE-2021-31207 in Microsoft Exchange, CVE-2023-26360 in Adobe ColdFusion). Therefore, we believe with moderate confidence that these web shells were dropped by exploiting an existing unpatched vulnerability.
According to the timeline of the detection logs, the attackers were able to leverage some of these web shells to execute commands on the affected server and drop more post-exploitation tools utilized for lateral movement. The majority of observed software are open-source tools maintained by Chinese-speaking developers. These implants are dropped into the Umbraco CMS root directory.

We found the following tools:

• Fscan: A tool for vulnerability scanning including host status detection, port scanning, service enumeration, exploitation, etc. The tool documentation is in simplified Chinese and maintained by Chinese-speaking accounts. The attackers created a script, named i.bat, to identify available machines on the network using simple ICMP ping requests. The output is directed to a text file, which is used later for lateral movement.
• Swor: A simple penetration testing tool whose author tried to make it immune to removal by security solutions. Based on its documentation, it can deploy mimikatz, FRP and ElevationStation. The tool is open-source and maintained by Chinese-speaking developers. This tool was previously sighted being leveraged in attacks on government entities in Malaysia, which is a similar industry vertical to the Middle East intrusion victimology. We found the same compiled sample in the wild at [domain]/wampthemes/simple/123/In-Swor-v2/1.exe.
• Neo-reGeorg: An open-source SOCKS5 proxy, the attackers used it to pivot to other machines and evade network-level security controls. Some detections suggest that this tool may be used to proxy traffic, but we have not been able to verify the actual purpose of proxying traffic through this server.
• ByPassGodzilla: A Chinese web shell encryptor used to obfuscate other deployed web shells to bypass detections. We were able to source different implementations of encrypted web shells in .NET and ASPX scripts from the same server. According to our telemetry, the newly discovered web shell was also associated with a campaign leveraging CVE-2023-26360 early this year targeting vulnerable servers in the Middle East.

Backdoor implants using DLL search-order hijacking

The attackers tried to load a malicious DLL,
datast.dll, from c:\Users\Public\Music\data three times. After these attempts failed, the attackers relied on another malicious loader, VERSION.dll, which was dropped into C:\Windows\branding\data. We discuss this below in the “New samples” section. We believe, based on our telemetry, that the Umbraco web shells were used to drop these files on the infected server.
Since the timeframe for loading the two malicious DLLs,
VERSION.dll and datast.dll, were very close, it allowed us to link the two files. Additionally, the same approach was used for both: leveraging a legitimate executable file vulnerable to DLL search-order hijacking, which would load a malicious DLL dropped into the same path as the legitimate executable.

The datast.dll library

In this incident, our telemetry points to the malware export being called using the rundll32 command from the
a.bat file (MD5: fca94b8b718357143c53620c6b360470), which we were unable to obtain. A second assumption is that it was loaded through a legitimate executable using DLL search-order hijacking, as datast.dll has been observed before, associated with Tropic Trooper and loaded by the same method. We believe with low to medium confidence that the batch script was merely used for testing purposes as the whole malware-loading chain was designed to be loaded from a legitimate executable.
Once loaded,
datast.dll exports a single function named InitCore. This function usually gets imported by another DLL called datastate.dll. The function implements the main functionality for this loader, decrypting the shellcode for the next stage from a memory buffer inside the datastate.dll file using a variant of the RC4 stream cipher. The first code block is the Key Scheduling Algorithm (KSA), while the second block (the “for” loop in the image below) is the core of the KSA, where it scrambles the initial permutation using the hardcoded RC4 key fYTUdr643$3u.

Code stub responsible for decrypting the next stage

Code stub responsible for decrypting the next stage

After decryption, the shellcode is executed, then the next stage is loaded into the address space of the process that loaded
datast.dll.

Hunting for new loaders

As mentioned, the infection chain was not fully executed, forcing the attackers to shift to new undetected variants. By pivoting on the hardcoded RC4 key, we found a new set of files sharing similar code, which turned out to be new updated variants of this family with minor differences in functionality. Below is the chronological view of the evolution of this specific loader as observed from our telemetry and scanning third-party malware repositories.

Recent variants

Updated loader variant in February 2024

In February 2024, a user uploaded three Crowdoor-related files to a multiscanner platform:

These files are also involved in a DLL search-order hijacking sequence:

1. A legitimate executable loads a vulnerable DLL (datastate.dll);
2. This DLL then loads a malicious Crowdoor DLL (datast.dll);
3. The loader DLL uses this malicious DLL to decrypt and load the Crowdoor payload.

This method is hard to detect since the malicious functions are split across two DLLs, which mostly perform seemingly benign tasks, such as reading files or decrypting RC4 data. Both DLLs have build timestamps future-dating them to 26 May 2027.

The
datastate.dll loader imports two functions from datast.dll — one called rcd (likely “run code”) to execute the shellcode and another called ldf (likely “load file”) to read content from a file that is named after a legitimate executable but without the file extension. In this case, the payload file uploaded is named WinStore, meaning the legitimate executable is WinStore.exe. The loader uses the RC4 key fYTUdr643$3u, the same key as found in the initial sample discussed in the previous section, to decrypt the payload file containing the same Crowdoor shellcode.
The Crowdoor payload from this chain stays active by creating a Windows service named WinStore, which is used as the service name, display name and description. If creation of the service fails, the payload uses the registry auto-start extensibility point (ASEP) at
HKCU\Software\Microsoft\Windows\CurrentVersion\Run with the value WinStore to persist.
When executed, it injects itself into the
colorcpl.exe process with the command-line argument “2” and tries to contact a C2 server that is hardcoded in the payload using its configuration (blog.techmersion[.]com on port 443).
We compared the collected samples with the reference sample (MD5: a213873eb55dc092ddf3adbeb242bd44) and revealed a degree of code similarity in them. For example, the core functions responsible for loading the next stage are almost identical. Based on this, we believe with medium confidence that the newly found samples are related to Tropic Trooper, the same actor behind the Middle East intrusion.

The actor has likely been using this search-order hijacking technique since at least June 2022, which marks the first known instance of a malicious DLL being loaded through a vulnerable executable using this method, according to our telemetry. Tropic Trooper employs this technique to split the malicious code across several stages. In the first stage, only the extraction of the next stage, which was encrypted with the same RC4 key, occurs. Subsequently, the actual loader for the final implant is deployed.

New samples

We investigated the second attempt made by the threat actor after failing to load the previously covered loader. The actor uploaded new samples detailed in the table below:

As usual, the same DLL search-order hijacking was used. Note that
inst.exe, which is a legitimate executable, imports three functions from VERSION.dll:

• VerQueryValueW;
• GetFileVersionInfoW;
• GetFileVersionInfoSizeW.

Each variant of the dropped
VERSION.dll implements the three exported functions, with minimal differences between both samples. Upon analyzing the three malicious exports from the samples, it is very likely that the attackers built them incrementally. The first sample (MD5: e845563ba35e8d227152165b0c3e769f) was dropped on April 28, immediately after the failed attempt to execute the old loader. This variant had fewer capabilities than the one dropped on May 15, which had a complete implementation for all the malicious capabilities needed to load the same shellcode that would load Crowdoor into memory.
Both variants have compilation timestamps set in the future. Looking at the
GetFileVersionInfoSizeW implementation between the two samples, we see that the most recently dropped sample has the full implementation, while the earlier sample has an empty implementation, implying gradual testing and development of this loader.
The main loading functionality was designed to execute a legitimate
msiexec.exe process, then inject the next stage by writing into its remote address space and creating a remote thread to execute it.

The victim

We sighted this targeted intrusion in a government entity in the Middle East. At the same time, we saw a subset of these samples being used to target a government entity in Malaysia. This matches the type of targets and their location as described in recent Tropic Trooper reports.

Attribution

Based on the samples found, we are reassessing the relationship between Tropic Trooper and the FamousSparrow group, reported by ESET in 2021. Some industry reports link the two groups together.

The following reasons led us to attribute the campaign described in this report and all the observed implants to Tropic Trooper and its associated group, FamousSparrow:

• Hardcoded RC4 key: the attackers tried to launch a loader previously attributed to Tropic Trooper (MD5: a213873eb55dc092ddf3adbeb242bd44), after they failed to load it from the a.bat file. They relied on a new method maintaining the same approach by using DLL search-order hijacking and used a new loader. Both samples share the same RC4 key.
• Post-exploitation tools: some of the post-exploitation tools the attackers used were seen before in other attacks within the same timeframe of this campaign, in which the victims aligned with the targeted regions and industry verticals targeted by this threat group.
• The code similarity between the Middle East intrusion sample and the sample found in the third-party malware repository from February 2024 (MD5: c10643b3fb304972c650e593b69faaa1): both were loading Crowdoor into memory. Also, the command-line argument “2” found in a variant related to Tropic Trooper samples is very similar to SparrowDoor “-k” switch functionality.

Conclusion

The event that made us investigate Tropic Trooper was the recurring detection of the China Chopper web shell. Following our investigation into this incident, we found more samples written by Tropic Trooper as well as third-party tools used in the post-exploitation phase. This improved insights into this threat actor’s TTPs. Notable is the discrepancy in skill set used in various stages of the attack, as well as the choices made after failure. When the actor became aware that their backdoors were detected, they tried to upload newer samples to evade detection, thereby increasing the risk of their new set of samples being detected in the near future. In the same light, the loader sequence goes to great lengths to avoid detection. However, the usage of publicly available tools such as Fscan for further exploitation of the victim’s network again highlights the discrepancy between some relatively advanced parts of their operation and the “noisier” parts.

Investigating the motives of this threat actor led us to conclude that the significance of this intrusion lies in the sighting of a Chinese-speaking actor targeting a content management platform that published studies on human rights in the Middle East, specifically focusing on the situation around Israel-Hamas conflict. Our analysis of this intrusion revealed that this entire system was the sole target during the attack, indicating a deliberate focus on this specific content.

A more detailed analysis of this campaign is available to users of our private Threat Intelligence Portal, with another upcoming report on this activity. To learn more about this report, please contact intelreports@kaspersky.com.

Indicators of Compromise

Umbraco Webshells
3F15C4431AD4573344AD56E8384EBD62
78B47DDA664545542ED3ABE17400C354
3B7721715B2842CDFF0AB72BD605A0CE
868B8A5012E0EB9A48D2DAF7CB7A5D87

Post-Exploitation Tools
149A9E24DBE347C4AF2DE8D135AA4B76
103E4C2E4EE558D130C8B59BFD66B4FB
E0D9215F64805E0BFF03F4DC796FE52E
27C558BD42744CDDC9EDB3FA597D0510
4F950683F333F5ED779D70EB38CDADCF

File Paths:
c:\sql\tools\attunitycdcoracle\x64\1033
c:\microsoft.net\framework64\v4.0.30319\temporary asp.net files\root\fc88e889\b64f0276
c:\microsoft.net\framework64\v4.0.30319\temporary asp.net files\root\5b841946\ca5a9bf5

Tropic Trooper Loaders
FD8382EFB0A16225896D584DA56C182C
1DD03936BAF0FE95B7E5B54A9DD4A577
8A900F742D0E3CD3898F37DBC3D6E054
A213873EB55DC092DDF3ADBEB242BD44
DD7593E9BA80502505C958B9BBBF2838
2C7EBD103514018BAD223F25026D4DB3
0B9AE998423A207F021F8E61B93BC849
E845563BA35E8D227152165B0C3E769F
A213873EB55DC092DDF3ADBEB242BD44

Domains and IPs
51.195.37[.]155
162.19.135[.]182
techmersion[.]com

Yara Rules

rule tropictrooper_umbraco_compiled_webshells {
meta:
description = "Rule to detect Tropic Trooper Umbraco webshells .NET sample"
author = "Kaspersky"
copyright = "Kaspersky"
distribution = "DISTRIBUTION IS FORBIDDEN. DO NOT UPLOAD TO ANY MULTISCANNER OR SHARE ON ANY THREAT INTEL PLATFORM"
sample = "3f15c4431ad4573344ad56e8384ebd62"

strings:
$s1 = { 72 ?? ?? ?? ?? 28 ?? ?? ?? ?? 6F ?? ?? ?? ?? A2 25 1F 0A 72 ?? ?? ?? ?? A2 25 1F 0B 72 ?? ?? ?? ?? A2 25 1F 0C 72 ?? ?? ?? ?? A2 25 1F 0D 72 ?? ?? ?? ?? A2 25 1F 0E 72 ?? ?? ?? ?? A2 25 1F 0F 72 ?? ?? ?? ?? A2 25 1F 10 72 ?? ?? ?? ?? A2 25 1F 11 72 ?? ?? ?? ?? A2 25 1F 12 72 ?? ?? ?? ?? A2 25 1F 13 72 ?? ?? ?? ?? A2 25 1F 14 72 ?? ?? ?? ?? A2 25 1F 15 72 ?? ?? ?? ?? A2 25 1F 16 72 ?? ?? ?? ?? A2 25 1F 17 72 ?? ?? ?? ?? A2 25 1F 18 72 ?? ?? ?? ?? A2 }

condition:
$s1 and
filesize < 1MB
}

securelist.com/new-tropic-troo…

Sometimes, simple things can make a world of difference. Take for example a non-verbal person who can’t necessarily control a touch screen in order to tell someone else what they need or want or think.

This is where Augmentative and Alternative Communication (AAC) devices come in. Recently tasked with building such a device, [Thornhill!] came up with a great design that houses 160 different phrases in a fairly small package and runs on CircuitPython.

Basically, the client presses the appropriate snap-dome button button and the corresponding phrase is spoken through the speaker. The 10×16 grid of buttons is covered with a membrane that both feels nice and gives a bit of protection from spills.

The buttons can achieve high actuation forces and have a crisp tactile response, which means they’re probably gonna go a long way to keep the user from getting frustrated.

This handy AAC board is built on the Adafruit RP2040 Prop-Maker Feather and two keypad matrices. If this weren’t useful enough as it is, [Thornhill!] also built an even smaller version with 16 buttons for the client to wear around their neck.

Did you know? AAC boards aren’t just for humans.

hackaday.com/2024/09/05/tactil…

!Programmer Humor
Hi, this is a question that popped into my mind when i saw an article about some AWS engineer talking about ai assistants taking over the job of programmers, this reminded me that it's not the first time that something like this was said.

My software engineering teacher once told me that a few years ago people believed graphical tools like enterprise architect would make it so that a single engineer could just draw a pretty UML diagram and generate 90% of the project without touching any code,
And further back COBOL was supposed to replace programmers by letting accountants write their own programs.

Now i'm curious, were there many other technologies that were supposedly going to replace programmers that you remember?

i hope someone that's been around much more than me knows something more or has some funny stories to share