Nel corso di un’analisi di sicurezza effettuata sul prodotto ZENIC ONE R58 di ZTE Corporations, il RED Team Research di TIM ha individuato un bug critico di tipo Formula Injection, una vulnerabilità che interessa le applicazioni che esportano file di fogli di calcolo costruiti dinamicamente da dati di input non adeguatamente convalidati.

La CVE-2024-22063 su ZENIC ONE R58 di ZTE Corporations

La Formula Injection (CSV o XLSX Injection) si verifica quando un file di calcolo (in formato CSV oppure XLSX) contiene valori che, una volta aperti in programmi come Microsoft Excel vengono interpretati come formule anziché come semplici dati, portando potenzialmente all’esecuzione di comandi o all’esfiltrazione di dati.

ZTE Corporations, multinazionale asiatica di telecomunicazioni, è uno dei principali fornitori di apparecchiature per le telecomunicazioni, dispositivi mobili e soluzioni di rete a livello mondiale. e attraverso il sistema ZENIC ONE R58 permette la gestione e il controllo della rete, fornendo diversi servizi, come la gestione della topologia, l’analisi delle risorse e il monitoraggio della rete.

La vulnerabilità identificata, classificata con il codice CVE-2024-22063, è stata rilevata sulla versione V16.22.40 del prodotto ZENIC ONE R58 e valutata 9 nella scala CVSSv3 (da 1 a 10).

L’assenza di un’adeguata neutralizzazione dei dati di input permette ad un utente malintenzionato, una volta autenticatosi, di iniettare formule arbitrarie all’interno di file XLSX al fine di esfiltrare dati sensibili, eseguire codice remotamente, o di condurre campagne di phishing.

Merita attenzione il fatto che nel bollettino di sicurezza emesso da ZTE Corportations, sia stato esplicitamente ringraziato il Red Team Research di TIM, dimostrando quanto sia ormai sempre più alta l’attenzione delle aziende nei confronti della sicurezza informatica, e quanto i lavori di ricerca e segnalazione di vulnerabilità siano fondamentali al suo raggiungimento.

Al fine di risolvere il problema, ZTE Corporations ha rilasciato un aggiornamento di sicurezza che recepisce le misure di mitigazione.

Uno sguardo al laboratorio Red Team Research di TIM

Si tratta di uno tra i pochi centri italiani di ricerca sui bug di sicurezza, dove da diverso tempo vengono effettuate attività che mirano all’identificazione di vulnerabilità non documentate (0day). Le attività condotte dal team, portano ad una successiva emissione di CVE sul National Vulnerability Database (NVD) degli Stati Uniti D’America, terminato il percorso di Coordinated Vulnerability Disclosure (CVD) con il vendor del prodotto.

Nel corso di 5 anni di attività, abbiamo visto il laboratorio, emettere moltissime CVE su prodotti best-in-class e big vendor di valenza internazionale, come ad esempio Oracle, IBM, Fortinet, F5, Ericsson, Red Hat, Nokia, Computer Associates, Siemens, F5, Fortinet, QNAP, Johnson & Control, Schneider Electric, oltre ad altri fornitori su tipologie differenti di architetture software/hardware.

Nel corso del tempo, il laboratorio ha emesso 170 CVE circa, dove 14 risultano con severità Critical (>= 9.0 di score CVSSv3).

Relativamente ad una vulnerabilità rilevata dal gruppo di ricerca sul prodotto Metasys Reporting Engine (MRE) Web Services, del fornitore Johnson & Control, la Cybersecurity and Infrastructure Security Agency (CISA) degli Stati Uniti D’America, ha emesso uno specifico bollettino di sicurezza riportandolo all’attenzione dei settori: “CRITICAL INFRASTRUCTURE SECTORS, COUNTRIES/AREAS DEPLOYED e COMPANY HEADQUARTERS LOCATION”.

Si tratta di un gruppo di ricerca tutto italiano che emette CVE con costanza, contribuendo in maniera fattiva alla ricerca delle vulnerabilità non documentate a livello internazionale. Il Red TIM Research si sta distinguendo a livello Italia sull’elevata caratura delle attività svolte, oltre a contribuire all’innalzamento dei livelli di sicurezza dei prodotti utilizzati da organizzazioni internazionali.

L'articolo Red Team Research di TIM pubblica una CVE critica (9.0) su ZENIC ONE R58 di ZTE Corporations proviene da il blog della sicurezza informatica.

In March 2023, researchers at ESET discovered malware implants embedded into various messaging app mods. Some of these scanned users’ image galleries in search of crypto wallet access recovery phrases. The search employed an OCR model which selected images on the victim’s device to exfiltrate and send to the C2 server. The campaign, which targeted Android and Windows users, saw the malware spread through unofficial sources. In late 2024, we discovered a new malware campaign we dubbed “SparkCat”, whose operators used similar tactics while attacking Android and iOS users through both official and unofficial app stores. Our conclusions in a nutshell:

• We found Android and iOS apps, some available in Google Play and the App Store, which were embedded with a malicious SDK/framework for stealing recovery phrases for crypto wallets. The infected apps in Google Play had been downloaded more than 242,000 times. This was the first time a stealer had been found in Apple’s App Store.
• The Android malware module would decrypt and launch an OCR plug-in built with Google’s ML Kit library, and use that to recognize text it found in images inside the gallery. Images that matched keywords received from the C2 were sent to the server. The iOS-specific malicious module had a similar design and also relied on Google’s ML Kit library for OCR.
• The malware, which we dubbed “SparkCat”, used an unidentified protocol implemented in Rust, a language untypical of mobile apps, to communicate with the C2.
• Judging by timestamps in malware files and creation dates of configuration files in GitLab repositories, SparkCat has been active since March 2024.

A malware SDK in Google Play apps

The first app to arouse our suspicion was a food delivery app in the UAE and Indonesia, named “ComeCome” (APK name: com.bintiger.mall.android), which was available in Google Play at the time of the research, with more than 10,000 downloads.

The onCreate method in the Application subclass, which is one of the app’s entry points, was overridden in version 2.0.0 (f99252b23f42b9b054b7233930532fcd). This method initializes an SDK component named “Spark”. It was originally obfuscated, so we statically deobfuscated it before analyzing.

Suspicious SDK being called

Spark is written in Java. When initialized, it downloads a JSON configuration file from a GitLab URL embedded in the malware body. The JSON is decoded with base64 and then decrypted with AES-128 in CBC mode.

The config from GitLab being decrypted

If the SDK fails to retrieve a configuration, the default settings are used.

We managed to download the following config from GitLab:
{
"http": ["https://api.aliyung.org"],
"rust": ["api.aliyung.com:18883"],
"tfm": 1
}
The “http” and “rust” fields contain SDK-specific C2 addresses, and the tfm flag is used to select a C2. With tfm equal to 1, “rust” will be used as the C2, and “http” if tfm has any other value.

Spark uses POST requests to communicate with the “http” server. It encrypts data with AES-256 in CBC mode before sending and decrypts server responses with AES-128 in CBC mode. In both cases, the keys are hard-coded constants.

The process of sending data to “rust” consists of three stages:

• Data is encrypted with AES-256 in CBC mode using the same key as in the case of the “http” server.
• The malware generates a JSON, where <PATH> is the data upload path and <DATA> is the encrypted data from the previous stage.
  {
  "path": "upload@<PATH>",
  "method": "POST",
  "contentType": "application/json",
  "data": "<DATA>"
  }
• The JSON is sent to the server with the help of the native libmodsvmp.so library via the unidentified protocol over TCP sockets. Written in Rust, the library disguises itself as a popular Android obfuscator.

Static analysis of the library wasn’t easy, as Rust uses a non-standard calling convention and the file had no function names in it. We managed to reconstruct the interaction pattern after running a dynamic analysis with Frida. Before sending data to the server, the library generates a 32-byte key for the AES-GCM-SIV cipher. With this key, it encrypts the data, pre-compressed with ZSTD. The algorithm’s nonce value is not generated and set to “unique nonce” (sic) in the code.

Extending the AES key using the hard-coded nonce value

The AES key is encrypted with RSA and is then also sent to the server. The public key for this RSA encryption is passed when calling a native method from the malicious SDK, in PEM format. The message is padded with 224 random bytes prior to AES key encryption. Upon receiving the request, the attackers’ server decrypts the AES key with a private RSA key, decodes the data it received, and then compresses the response with ZSTD and encrypts it with the AES-GCM-SIV algorithm. After being decrypted in the native library, the server response is passed to the SDK where it undergoes base64 decoding and decryption according to the same principle used for communication with the “http” server. See below for an example of communication between the malware module and the “rust” server.

An example of communication with the “rust” server

Once a configuration has been downloaded, Spark decrypts a payload from assets and executes it in a separate thread. It uses XOR with a 16-byte key for a cipher.

A payload being decrypted

The payload (c84784a5a0ee6fedc2abe1545f933655) is a wrapper for the TextRecognizer interface in Google’s ML Kit library. It loads different OCR models depending on the system language to recognize Latin, Korean, Chinese or Japanese characters in images. The SDK then uploads device information to /api/e/d/u on the C2 server. The server responds with an object that controls further malware activities. The object is a JSON file, its structure shown below. The uploadSwitch flag allows the malware to keep running (value 1).
{
"code": 0,
"message": "success",
"data": {
"uploadSwitch": 1,
"pw": 0,
"rs": ""
}
}
The SDK then registers an application activity lifecycle callback. Whenever the user initiates a chat with the support team, implemented with the legitimate third-party Easemob HelpDesk SDK, the handler requests access to the device’s image gallery. If the pw flag in the aforementioned object is equal to 1, the module will keep requesting access if denied. The reasoning behind the SDK’s request seems sound at first: users may attach images when contacting support.

The reason given when requesting read access to the gallery

If access is granted, the SDK runs its main functionality. This starts with sending a request to /api/e/config/rekognition on the C2 and getting parameters for processing OCR results in a response.
{
"code": 0,
"message": "success",
"data": {
"letterMax": 34,
"letterMin": 2,
"enable": 1,
"wordlistMatchMin": 9,
"interval": 100,
"lang": 1,
"wordMin": 12,
"wordMax": 34
}
}
These parameters are used by processor classes that filter images by OCR-recognized words. The malware also requests a list of keywords at /api/e/config/keyword for KeywordsProcessor, which uses these to select images to upload to the C2 server.

Searching for keywords among OCR image processing results

Besides KeywordsProcessor, the malware contains two further processors: DictProcessor and WordNumProcessor. The former filters images using localized dictionaries stored decrypted inside rapp.binary in the assets, and the latter filters words by length. The letterMin and letterMax parameters for each process define the permitted range of word length. For DictProcessor, wordlistMatchMin sets a minimum threshold for dictionary word matches in an image. For WordNumProcessor, wordMin and wordMax define the acceptable range for the total number of recognized words. The rs field in the response to the request for registering an infected device controls which processor will be used.

Images that match the search criteria are downloaded from the device in three steps. First, a request containing the image’s MD5 hash is sent to /api/e/img/uploadedCheck on the C2. Next, the image is uploaded to either Amazon’s cloud storage or to file@/api/res/send on the “rust” server. After that, a link to the image is uploaded to /api/e/img/rekognition on the C2. So, the SDK, designed for analytics as suggested by the package name com.spark.stat, is actually malware that selectively steals gallery content.

Uploading an image link

We asked ourselves what kind of images the attackers were looking for. To find out, we requested from the C2 servers a list of keywords for OCR-based search. In each case, we received words in Chinese, Japanese, Korean, English, Czech, French, Italian, Polish and Portuguese. The terms all indicated that the attackers were financially motivated, specifically targeting recovery phrases also known as “mnemonics” that can be used to regain access to cryptocurrency wallets.
{
"code": 0,
"message": "success",
"data": {
"keywords": ["助记词", "助記詞", "ニーモニック", "기억코드", "Mnemonic",
"Mnemotecnia", "Mnémonique", "Mnemonico", "Mnemotechnika", "Mnemônico",
"클립보드로복사", "복구", "단어", "문구", "계정", "Phrase"]
}
}
Unfortunately, ComeCome was not the only app we found embedded with malicious content. We discovered a number of additional, unrelated apps covering a variety of subjects. Combined, these apps had been installed over 242,000 times at the time of writing this, and some of them remained accessible on Google Play. A full inventory can be found under the Indicators of Compromise section. We alerted Google to the presence of infected apps in its store.

Popular apps containing the malicious payload

Furthermore, our telemetry showed that malicious apps were also being spread through unofficial channels.

SDK features could vary slightly from app to app. Whereas the malware in ComeCome only requested permissions when the user opened the support chat, in some other cases, launching the core functionality acted as the trigger.

One small detail…

As we analyzed the trojanized Android apps, we noticed how the SDK set deviceType to “android” in device information it was sending to the C2, which suggested that a similar Trojan existed for other platforms.

Collecting information about an infected Android device

A subsequent investigation uncovered malicious apps in App Store infected with a framework that contained the same Trojan. For instance, ComeCome for iOS was infected in the same way as its Android version. This is the first known case of an app infected with OCR spyware being found in Apple’s official app marketplace.

The ComeCome page in the App Store

Negative user feedback about ComeCome

Malicious frameworks in App Store apps

We detected a series of apps embedded with a malicious framework in the App Store. We cannot confirm with certainty whether the infection was a result of a supply chain attack or deliberate action by the developers. Some of the apps, such as food delivery services, appeared to be legitimate, whereas others apparently had been built to lure victims. For example, we saw several similar AI-featured “messaging apps” by the same developer:

Messaging apps in the App Store designed to lure victims

Besides the malicious framework itself, some of the infected apps contained a modify_gzip.rb script in the root folder. It was apparently used by the developers to embed the framework in the app:

The contents of modify_gzip.rb

The framework itself is written in Objective-C and obfuscated with HikariLLVM. In the apps we detected, it had one of three names:

1. GZIP;
2. googleappsdk;
3. stat.

As with the Android-specific version, the iOS malware utilized the ML Kit interface, which provided access to a Google OCR model trained to recognize text and a Rust library that implemented a custom C2 communication protocol. However, in this case, it was embedded directly into the malicious executable. Unlike the Android version, the iOS framework retained debugging symbols, which allowed us to identify several unique details:

• The lines reveal the paths on the framework creators’ device where the project was stored, including the user names:
  
  • /Users/qiongwu/: the project author’s home directory
  • /Users/quiwengjing/: the Rust library creator’s home directory

  
  

• The C2-rust communication module was named im_net_sys. Besides the client, it contains code that the attackers’ server presumably uses to communicate with victims.
• The project’s original name is GZIP.

Project details from code lines in the malicious framework

The framework contains several malicious classes. The following are of particular interest:

• MMMaker: downloads a configuration and gathers information about the device.
• ApiMgr: sends device data.
• PhotoMgr: searches for photos containing keywords on the device and uploads them to the server.
• MMCore: stores information about the C2 session.
• MMLocationMgr: collects the current location of the device. It sent no data during our testing, so the exact purpose of this class remained unclear.

Certain classes, such as MMMaker, could be missing or bear a different name in earlier versions of the framework, but this didn’t change the malware’s core functionality.

Obfuscation significantly complicates the static analysis of samples, as strings are encrypted and the program’s control flow is obscured. To quickly decrypt the strings of interest, we opted for dynamic analysis. We ran the application under Frida and captured a dump of the _data section where these strings were stored. What caught our attention was the fact that the app bundleID was among the decrypted data:

com.lc.btdj: the ComeCome bundleID as used in the +[MMCore config] selector

As it turned out, the framework also stored other app bundle identifiers used in the +[MMCore config] selector. Our takeaways are as follows:

1. The Trojan can behave differently depending on the app it is running in.
2. There are more potentially infected apps than we originally thought.

For the full list of bundle IDs we collected from decrypted strings in various framework samples, see the IoC section. Some of the apps associated with these IDs had been removed from the App Store at the time of the investigation, whereas others were still there and contained malicious code. Some of the IDs on the list referred to apps that did not contain the malicious framework at the time of this investigation.

As with the Android-specific version, the Trojan implements three modes of filtering OCR output: keywords, word length, and localized dictionaries stored in encrypted form right inside the framework, in a “wordlists” folder. Unfortunately, we were unable to ascertain that the malware indeed made use of the last method. None of the samples we analyzed contained links to the dictionaries or accessed them while running.

Sending selected photos containing keywords is a key step in the malicious framework’s operation. Similar to the Android app, the Trojan requests permission to access the gallery only when launching the View Controller responsible for displaying the support chat. At the initialization stage, the Trojan, depending on the application it is running in, replaces the viewDidLoad or viewWillAppear method in the relevant controller with its own wrapper that calls the method +[PhotoMgr startTask:]. The latter then checks if the application has access to the gallery and requests it if needed. Next, if access is granted, PhotoMgr searches for photos that match sending criteria among those that are available and have not been processed before.

The code snippet of the malicious wrapper around the viewDidLoad method that determines which application the Trojan is running in

Although it took several attempts, we managed to make the app upload a picture to Amazon’s cloud and then send information about it to the attackers’ server. The app was using HTTPS to communicate with the server, not the custom “rust” protocol:

The communication with the C2 and upload to AWS

The data being sent looks as follows:
POST /api/e/img/uploadedCheck
{
"imgSign": <imgMD5>,
"orgId": <implantId>,
"deviceId": <deviceUUID>
}

POST api/e/img/rekognition
{
"imgUrl": "https://dmbucket102.s3.ap-northeast-
1.amazonaws.com/"<app_name>_<device_uuid>"/photo_"<timestamp>".jpg",
"deviceName": "ios",
"appName": <appName>,
"deviceUUID": <deviceUUID>,
"imgSign": <imgMD5>,
"imgSize": <imgSize>,
"orgId":<implantId>,
"deviceChannel": <iphoneModel>,
"keyword":<keywordsFoundOnPicture>,
"reksign":<processor type>
}
The oldest version of the malicious framework we were investigating was built on March 15, 2024. While it doesn’t differ significantly from newer versions, this one contains more unencrypted strings, including API endpoints and a single, hardcoded C2 address. Server responses are received in plaintext.

URLs hard-coded into the oldest version of the malicious framework

File creation date in the app

Campaign features

While analyzing the Android apps, we found that the word processor code contained comments in Chinese. Error descriptions returned by the C2 server in response to malformed requests were also in Chinese. These, along with the name of the framework developer’s home directory which we obtained while analyzing the iOS-specific version suggest that the creator of the malicious module speaks fluent Chinese. That being said, we have insufficient data to attribute the campaign to a known cybercrime gang.

Our investigation revealed that the attackers were targeting crypto wallet recovery phrases, which were sufficient for gaining full control over a victim’s crypto wallet to steal the funds. It must be noted that the malware is flexible enough to steal not just these phrases but also other sensitive data from the gallery, such as messages or passwords that might have been captured in screenshots. Multiple OCR results processing modes mitigate the effects of model errors that could affect the recognition of access recovery phrase images if only keyword processing were used.

Our analysis of the malicious Rust code inside the iOS frameworks revealed client code for communicating with the “rust” server and server-side encryption components. This suggests that the attackers’ servers likely also use Rust for protocol handling.

Server-side private RSA key import

We believe that this campaign is targeting, at a minimum, Android and iOS users in Europe and Asia, as indicated by the following:

• The keywords used were in various languages native to those who live in European and Asian countries.
• The dictionaries inside assets were localized in the same way as the keywords.
• Some of the apps apparently operate in several countries. Some food delivery apps support signing up with a phone number from the UAE, Kazakhstan, China, Indonesia, Zimbabwe and other countries.

We suspect that mobile users in other regions besides Europe and Asia may have been targeted by this malicious campaign as well.

One of the first malicious modules that we started our investigation with was named “Spark”. The bundle ID of the malicious framework itself, “bigCat.GZIPApp”, caught our attention when we analyzed the iOS-specific Trojan. Hence the name, “SparkCat”. The following are some of the characteristics of this malware:

• Cross-platform compatibility;
• The use of the Rust programming language, which is rarely found in mobile apps;
• Official app marketplaces as a propagation vector;
• Stealth, with C2 domains often mimicking legitimate services and malicious frameworks disguised as system packages;
• Obfuscation, which hinders analysis and detection.

Conclusion

Unfortunately, despite rigorous screening by the official marketplaces and general awareness of OCR-based crypto wallet theft scams, the infected apps still found their way into Google Play and the App Store. What makes this Trojan particularly dangerous is that there’s no indication of a malicious implant hidden within the app. The permissions that it requests may look like they are needed for its core functionality or appear harmless at first glance. The malware also runs quite stealthily. This case once again shatters the myth that iOS is somehow impervious to threats posed by malicious apps targeting Android. Here are some tips that can help you avoid becoming a victim of this malware:

• If you have one of the infected apps installed on your device, remove it and avoid reinstalling until a fix is released.
• Avoid storing screenshots with sensitive information, such as crypto wallets recovery phrases, in the gallery. You can store passwords, confidential documents and other sensitive information in special apps.
• Use a robust security product on all your devices.

Our security products return the following verdicts when detecting malware associated with this campaign:

• HEUR:Trojan.IphoneOS.SparkCat.*
• HEUR:Trojan.AndroidOS.SparkCat.*

Indicators of compromise

Infected Android apps
0ff6a5a204c60ae5e2c919ac39898d4f
21bf5e05e53c0904b577b9d00588e0e7
a4a6d233c677deb862d284e1453eeafb
66b819e02776cb0b0f668d8f4f9a71fd
f28f4fd4a72f7aab8430f8bc91e8acba
51cb671292eeea2cb2a9cc35f2913aa3
00ed27c35b2c53d853fafe71e63339ed
7ac98ca66ed2f131049a41f4447702cd
6a49749e64eb735be32544eab5a6452d
10c9dcabf0a7ed8b8404cd6b56012ae4
24db4778e905f12f011d13c7fb6cebde
4ee16c54b6c4299a5dfbc8cf91913ea3
a8cd933b1cb4a6cae3f486303b8ab20a
ee714946a8af117338b08550febcd0a9
0b4ae281936676451407959ec1745d93
f99252b23f42b9b054b7233930532fcd
21bf5e05e53c0904b577b9d00588e0e7
eea5800f12dd841b73e92d15e48b2b71

iOS framework MD5s:
35fce37ae2b84a69ceb7bbd51163ca8a
cd6b80de848893722fa11133cbacd052
6a9c0474cc5e0b8a9b1e3baed5a26893
bbcbf5f3119648466c1300c3c51a1c77
fe175909ac6f3c1cce3bc8161808d8b7
31ebf99e55617a6ca5ab8e77dfd75456
02646d3192e3826dd3a71be43d8d2a9e
1e14de6de709e4bf0e954100f8b4796b
54ac7ae8ace37904dcd61f74a7ff0d42
caf92da1d0ff6f8251991d38a840fb4a

Trojan configuration in GitLab
hxxps://gitlab[.]com/group6815923/ai/-/raw/main/rel.json
hxxps://gitlab[.]com/group6815923/kz/-/raw/main/rel.json

C2
api.firebaseo[.]com
api.aliyung[.]com
api.aliyung[.]org
uploads.99ai[.]world
socket.99ai[.]world
api.googleapps[.]top

Photo storage
hxxps://dmbucket102.s3.ap-northeast-1.amazonaws[.]com

Names of Infected Android APKs from Google Play
com.crownplay.vanity.address
com.atvnewsonline.app
com.bintiger.mall.android
com.websea.exchange
org.safew.messenger
org.safew.messenger.store
com.tonghui.paybank
com.bs.feifubao
com.sapp.chatai
com.sapp.starcoin

BundleIDs encrypted inside the iOS frameworks
im.pop.app.iOS.Messenger
com.hkatv.ios
com.atvnewsonline.app
io.zorixchange
com.yykc.vpnjsq
com.llyy.au
com.star.har91vnlive
com.jhgj.jinhulalaab
com.qingwa.qingwa888lalaaa
com.blockchain.uttool
com.wukongwaimai.client
com.unicornsoft.unicornhttpsforios
staffs.mil.CoinPark
com.lc.btdj
com.baijia.waimai
com.ctc.jirepaidui
com.ai.gbet
app.nicegram
com.blockchain.ogiut
com.blockchain.98ut
com.dream.towncn
com.mjb.Hardwood.Test
com.galaxy666888.ios
njiujiu.vpntest
com.qqt.jykj
com.ai.sport
com.feidu.pay
app.ikun277.test
com.usdtone.usdtoneApp2
com.cgapp2.wallet0
com.bbydqb
com.yz.Byteswap.native
jiujiu.vpntest
com.wetink.chat
com.websea.exchange
com.customize.authenticator
im.token.app
com.mjb.WorldMiner.new
com.kh-super.ios.superapp
com.thedgptai.event
com.yz.Eternal.new
xyz.starohm.chat
com.crownplay.luckyaddress1

securelist.com/sparkcat-steale…

Surface mount devices have gotten really small, so small that a poorly timed sneeze can send your 0603 and 0402 parts off to live with the dust motes lurking at the edge of your bench. While soldering such parts is a challenge, it’s not always size that matters. Some parts with larger footprints can be a challenge because of the pin pitch, and getting them to land just right on the PCB pads can be a real pain.

To fight this problem, [rahmanshaber] came up with this clever custom PCB fixture. The trick is to create a jig to hold the fine-pitch parts securely while still leaving room to work. In his case, the parts are a couple of SMD ribbon cable connectors and some chips in what appear to be TQFP packages. [rahmanshaber] used FreeCAD to get the outline of each part from the 3D model of his PCB, and KiCad to design the cutouts; skip to 7:30 or so in the video below if you don’t need the design lesson. The important bit is to leave enough room around the traces so that the part’s leads can rest of the PCB while still having room to access them.

Using the fixture is pretty intuitive. The fixture is aligned over the footprint of the part and fixed in place with some tape. Solder paste is applied to the pads, the part is registered into the hole, and you’re ready for soldering. [rahmanshaber] chose to use a hot plate to do the soldering, but it looks like there’s enough room for a soldering iron, if that’s your thing.

It’s a simple idea, but sometimes the simplest tools are the best. We’ve seen lots of other simple SMD tools, from assembly jigs to solder paste stencil fixtures.

youtube.com/embed/2zebD-ByTC8?…

hackaday.com/2025/02/04/custom…

Google ha rilasciato il set di patch di febbraio per Android. In totale, gli aggiornamenti risolvono 48 vulnerabilità, tra cui una vulnerabilità 0-day del kernel che è già stata sfruttata attivamente dagli hacker.

Alla vulnerabilità zero-day è stato assegnato l’identificatore CVE-2024-53104 ed è correlata all’escalation dei privilegi nel driver USB Video Class del kernel Android. Lo sfruttamento di questo problema ha consentito ad aggressori locali autenticati di aumentare i propri privilegi.

L’errore era correlato al fatto che il driver analizzava in modo errato i frame di tipo UVC_VS_UNDEFINED nella funzione uvc_parse_format. Di conseguenza, la dimensione del framebuffer è stata calcolata in modo errato, causando scritture fuori dai limiti e potrebbe essere utilizzata per eseguire codice arbitrario o attacchi di negazione del servizio (DoS).

Oltre alla vulnerabilità zero-day sfruttata, le patch Android di febbraio hanno corretto una vulnerabilità critica nel componente WLAN di Qualcomm. Qualcomm descrive questo bug critico (CVE-2024-45569) come un problema di danneggiamento della memoria del firmware causato da una convalida errata dell’indice array nella comunicazione host WLAN a causa di un contenuto di frame non valido.

Il CVE-2024-45569 può essere utilizzato dagli aggressori remoti per eseguire codice o comandi arbitrari, leggere o modificare la memoria o causare arresti anomali. Tuttavia, gli attacchi non richiedono privilegi o interazione da parte dell’utente.

A febbraio 2025, Google ha rilasciato due pacchetti di patch: 2025-02-01 e 2025-02-05. Quest’ultima include tutte le correzioni del primo lotto, oltre a correzioni aggiuntive per moduli closed-source di terze parti ed elementi del kernel che non si applicano a tutti i dispositivi Android.

L'articolo Allarme sicurezza su Android: hacker sfruttano un grave bug 0-day nel driver USB! proviene da il blog della sicurezza informatica.

l senatore, vice capo del Consiglio per lo sviluppo dell’economia digitale presso il Consiglio della Federazione Russa Artem Sheikin ha inviato una richiesta al Ministero dello sviluppo digitale sulla possibilità di identificare i white hacker.

In precedenza, Sheikin aveva detto all’agenzia che il Consiglio della Federazione aveva elaborato un disegno di legge che avrebbe introdotto nella legislazione russa le attività inerenti la ricerca di vulnerabilità nell’infrastruttura informatica della Federazione Russa. Secondo il documento, le loro attività saranno autorizzate dal Servizio federale per il controllo tecnico e delle esportazioni (FSTEC).

La decisione della sezione del Consiglio per lo sviluppo dell’economia digitale del Consiglio della Federazione, firmata da Sheikin, parla di una raccomandazione al Ministero dello sviluppo digitale, delle comunicazioni e dei mass media di valutare la fattibilità dell’utilizzo del Sistema unificato di identificazione e autenticazione (UIAS) – il portale dei servizi statali – per registrare i ricercatori che identificano vulnerabilità nei prodotti software e nei sistemi hardware e software.

Secondo il senatore, il disegno di legge è attualmente in fase di discussione con i dipartimenti interessati e gli operatori del mercato. Il documento è stato inviato al Ministero dello sviluppo digitale, delle comunicazioni e dei mass media della Federazione Russa, al Servizio federale per il controllo tecnico e delle esportazioni della Russia, alla Procura generale della Federazione Russa e al Ministero degli affari interni della Russia per l’esame e la fornitura di posizioni ufficiali.

Sheikin ha chiarito che, dopo aver ricevuto le risposte dai dipartimenti competenti e una replica dal governo russo, il disegno di legge verrà sottoposto alla Duma di Stato per l’esame.

L'articolo White Hacker sotto controllo: la Russia vuole identificare i ricercatori di bug nella Federazione proviene da il blog della sicurezza informatica.

Mi è capitato nel tempo di scrivere anche cose di tipo "divulgativo" — per usare una parola alla quale non riesco a trovare un'alternativa migliore ma ci siamo capiti — sul mio mestiere.
Prima o poi mi piacerebbe raccoglierle.

...in quel regno della biodiversità che è la psicoterapia, quei diversi strumenti corrispondono in qualche modo a diverse concezioni del mondo. E questo riguarda la prima assunzione di responsabilità di un terapeuta, quella che sta a monte di tutte le altre...

massimogiuliani.it/blog/2018/0…

Ma un terapeuta risolve problemi? Corregge malfunzionamenti? Cambia le persone?

La psicoterapia spiegata a chi fa un altro mestiere / 1 Giusto per mettere le mani avanti, qualunque cosa scriverò sull’argomento sarà necessariamente imprecisa e semplificata. Già il titolo è una …

^{Corpi che parlano}

OGGETTISTICA, raccolta di prose non orientabili e talvolta nemmeno euclidee, si presenta in una delle più belle librerie d'Italia, MODO INFOSHOP, a Bologna, venerdì 14 febbraio, giorno di San Valentino. Le coppie di innamorati che verranno ad assistere riceveranno in omaggio una ventata di buonumore: slowforward.net/2025/02/04/14-…

slowforward

2025-02-04 10:03:00

14 febbraio, bologna: “oggettistica” a modo infoshop

Venerdì 14 febbraio, a Bologna, presso
MODO INFOSHOP (via Mascarella 24/b)
alle ore 18:15

presentazione di

OGGETTISTICA
di Marco Giovenale

intervengono

Stefano Colangelo e Sergio Rotino

letture dell’autore

evento fb:
facebook.com/events/1170357224…

il libro:
ticedizioni.com/products/ogget…

informazioni e link:
slowforward.net/2024/04/15/lin…

modoinfoshop.com/
instagram.com/modoinfoshop/
t. 051 5871012
info [at] modoinfoshop.com

N.b.: il libro è fin da ora disponibile in libreria,
quindi chi lo desidera può acquistarlo già adesso

#Bologna #LibreriaModoInfoshop #Modo #ModoInfoshop #presentazione #prosa #prosaBreve #prose #proseBrevi #proseNonEuclidee #proseNonOrientabili #reading #scritturaDiRicerca #scrittureDiRicerca #Tic #TicEdizioni #ventataDiBuonumore #viaMascarella

Marco Giovenale on Instagram: "venerdì 14 febbraio, Bologna, @modoinfoshop : OGGETTISTICA (@ticedizioni 2024) con il legale rappresentante @marco.giovenale & le annotazioni critiche di Stefano Colangelo e Sergio Rotino h. 18:15, via Mascarella 24/b h

14 likes, 2 comments - marco.giovenale on February 4, 2025: "venerdì 14 febbraio, Bologna, @modoinfoshop : OGGETTISTICA (@ticedizioni 2024) con il legale rappresentante @marco.

^Instagram

peertube.uno/c/fiorelisag/vide…

Il progetto nasce dalla volontà di offrire un punto di partenza per l’approfondimento di questioni legate all’attualità ed alla storia recente, dai conflitti aperti sullo scenario globale ai fenomeni sociali, politici e culturali che operano nel mondo.
I filmati divulgativi intendono fornire le coordinate minime per orientarsi nel percorso di ricerca e promuovere un approccio multidisciplinare.

Trovate Fiorella anche su YouTube a questo indirizzo youtube.com/@fiore.ytchannel

La prima volta che ho sentito questa canzone vivevo a Parigi e la mia collega spagnola sosteneva che questa pare una struggente ballata sulla sofferenza d'amore ma in realtà la persona onnipresente che fa soffrire Silvio è Fidel Castro.
Silvio poi questa cosa (che si è estesa a Pinochet) l'ha smentita - era davvero una donna che aveva amato.
Tuttavia, mi affascinò l'idea che sotto una canzone d'amore potesse esserci altro. Quindi, in quesa nostra interpretazione, vedeteci chi volete.
(il mio pigliama dello Psicopato era in continuità linguistica).
VIDEO NEL LINK QUA SOTTO

peertube.uno/w/kcf7b2Nwtr4We42…

Grazie al film A Complete Unknown di James Mangold tornano d'attualità i fatti di Newport 1965, quando sul palco del Folk Festival Bob Dylan fu contestato (al grido di "suonate musica folk!") perché suonò un set elettrico con la Paul Butterfield Blues Band.
Per dire quanto fosse accecante l'ideologia della purezza acustica, “Mr. Tambourine Man” e “It's All Over Now, Baby Blue”, dai testi densi di immagini oscuramente visionarie, in quel clima venivano accolte come dolci ballate. La chitarra acustica era in qualche modo garante delle convenzioni della musica folk.
Nel libro Guitar Cultures curato da Andy Bennett e Kevin Dawe (2001), un saggio di Peter Narváez (“Unplugged: Blues Guitarists and the Myth of Acousticity”) racconta il "mito dell'acusticità", l'ideologia della "purezza acustica".

Thanks to James Mangold's film A Complete Unknown, the events of Newport 1965 are back in the news. On stage at the Folk Festival Bob Dylan was challenged (to the cry of “play folk music!”) because he played an electric set with the Paul Butterfield Blues Band.
To say how blindingly acoustic purity ideology was, “Mr. Tambourine Man” and “It's All Over Now, Baby Blue,” with lyrics dense with darkly visionary imagery, were received as sweet ballads in that climate. The acoustic guitar was somehow a guarantor of folk music conventions.
In the book Guitar Cultures, edited by Andy Bennett and Kevin Dawe (2001), an essay by Peter Narváez (“Unplugged: Blues Guitarists and the Myth of Acousticity”) explains the “myth of acousticity,” the ideology of “acoustic purity.”