Nostalgia is a funny thing. If you experienced the early days of video games in the 1980s and 90s, there’s a good chance you remember those games looking a whole lot better than they actually did. But in reality, the difference between 2023’s Tears of the Kingdom and the original Legend of Zelda is so vast that it can be hard to reconcile the fact that they’re both in the same medium. Of course, that doesn’t mean change the way playing those old games actually makes you feel. If only there was some way to wave a magic wand and improve the graphics of those old titles…

Well, if you consider Ghidra and a hex editor to be magic wands in our community, making that wish come true might be more realistic than you think. As [Alberto Marnetto] explains in a recent blog post, decompiling Stunt Island and poking around at the code allows one to improve the graphical detail level in the flight simulator by approximately 800%. In fact, it’s possible to go even higher, though at some point the game simply becomes unplayable.

The same hack also allows ground details to be turned off.
Even if this is the first time you’ve ever heard of this particular 1992 flying game from Disney, the write-up is a fascinating read and contains some practical tips for reverse engineering and debugging older software from within the confines of DOSBox. By strategically setting break points, [Alberto] was able to follow the logic that reads the desired graphical detail level from the configuration file, all the way up to the point where it influences the actual rendering engine.

It turns out the detail level variable was capped off, but by studying the way the engine used that variable to modify other parameters, he was able to tweak the math from the other side of the equation and go beyond the game’s intended 100% detail level.

Looking at the side by side comparison with modern eyes…even the tweaked version of the game leaves a lot to be desired. But there’s only so far you can push the engine, especially given the limited resolution it’s able to run at. But there’s no question that the patch [Alberto] has developed greatly improves the density of objects (buildings, trees, etc) on the ground. The video below shows off the patched game running at full-tilt to give you an idea of what it looks like in motion.

This isn’t the first time we’ve seen an enthusiastic fan patching new capabilities into their favorite retro game. From the upgrades made to Mortal Kombat Arcade Edition to the incredible work [Sebastian Mihai] put into creating a custom expansion to Knights of the Round, you’d be wise not to underestimate what a dedicated gamer can pull off with a hex editor.

youtube.com/embed/AZMDm-2IIzc?…

Thanks to [adistuder] on the Hackaday Discord server for the tip.

hackaday.com/2024/12/05/cranki…

Nowadays, a lot of cybersecurity professionals use IDA Pro as their primary tool for reverse engineering. While IDA is a complex tool that implements a multitude of features useful for dissecting binaries, many reverse engineers use various plugins to add further functionality to this software. We in the Global Research and Analysis Team do the same – and over the years we have developed our own IDA plugin named hrtng that is specifically designed to aid us with malware reverse engineering.

We started working on hrtng back in 2016, when we forked the hexrays_tools plugin developed by Milan Bohacek. Since then, our highly experienced reverse engineer Sergey Belov has added lots of features to this tool, especially those that IDA lacked, from string decryption to decompiling obfuscated assemblies. Sometimes the capabilities we needed were implemented in existing and often abandoned plugins – in this case we integrated the obsolete code into hrtng and kept it updated to work with the latest versions of the ever-changing IDA SDK.

We recently decided to share hrtng with the community and published its source code on GitHub under the GPLv3 license – and in this article we want to demonstrate how our plugin makes it easier for a malware analyst to reverse engineer complex samples. To do that, we will analyze a component of the FinSpy malware, a sophisticated commercial spyware program for multiple platforms. While demonstrating the capabilities of our plugin, we will also provide some general tips for working with IDA.

If we open our sample in a HEX editor, we can see that its first two bytes are 4D 5A – the signature for Windows executables.

However, if we load it into IDA, we see that IDA fails to recognize the binary as an executable. So we have no choice but to load the sample as a binary file.

When we do that, IDA displays the bytes of the loaded file. If we disassemble them, we can see that the 4D 5A sequence is not the header of the EXE file; instead, these bytes are part of the following shellcode:

As can be seen from the screenshot above, the first few instructions (highlighted in yellow) are of little value, as they are placed primarily to disguise the shellcode as a PE file. If we further examine the orange part of the code, we can see two interesting constants are assigned there, namely 0x2C7B2 and 0xF6E4BB5E. Next, the blue part contains two instructions, fldz and fstenv. Notably, this combination of instructions is often used in malware to get the value of the EIP register and thus identify the shellcode address. After obtaining this address, the shellcode increases it by 0x1D, saving it in the EDX register using the LEA instruction.
How is it possible to obtain the value of EIP using the fldz and fstenv instructions?
If we search for the description of the fldz and fstenv instructions in the Intel processor documentation (paragraphs 8.3.4 and 8.1.10), we can see that the fldz instruction saves the zero constant to the floating point unit (FPU) stack. In turn, the fstenv instruction retrieves the current state of the FPU, which is stored in the following format:

To understand how the shellcode uses the FPU state, we can import the following state structure into IDA:
struct sFPUstate
{
int cw;
int sw;
int tw;
int fip;
int fis;
int fdp;
int fds;
};
We can further apply this structure to the variable containing the state and observe that the code uses the fip field of this structure:

From the documentation, we can infer that this field contains the instruction pointer value of the FPU – in the case of our shellcode, it stores the address of the fldz instruction.

After retrieving its own address, the shellcode enters a loop, highlighted in green. Its body contains two instructions, XOR and ROL. As you can see from the screenshot, the first operand of the XOR instruction contains the EDX register – and as we just discussed, it stores the address of the shellcode. As a result, the shellcode applies the XOR operation to its own bytes, thus decrypting itself. We can also observe that the decryption key is stored in the EBX register, with its value assigned in the orange part of the shellcode. As for the number of bytes to be decrypted, it is assigned the value 0x2C7B2 stored in the ECX register.

To continue our analysis, we need to decrypt the shellcode, and this can be done in multiple ways, for example, by writing an IDAPython script or with a standalone C program. It’s also convenient to perform decryption with the hrtng plugin; to do so, we can select the encrypted blob using the Alt + L hotkey and then open the Decrypt data window by pressing Shift + D. In this window we can specify the encryption key and algorithm to be used. Our plugin implements the most popular algorithms such as XOR, RC4 or AES out of the box, making it possible to perform decryption with just a few clicks.

To decrypt our shellcode, we need to select the FinSpy algorithm in the window of the above screenshot and set the key 0xF6E4BB5E. Once the decryption is complete, we can continue to analyze the malicious payload.

More details on how to decrypt data with our plugin are available in the following video:

media.kasperskycontenthub.com/…
How to add a custom decryption algorithm to the plugin
It is possible to add a custom encryption algorithm to the plugin by implementing it in the decr.cpp file. The decryption algorithm needs to be specified either in the decrypt_char (for stream ciphers) or decr_core (for block ciphers) function. The plugin code contains case eAlg_Custom and case eAlg_CustomBlk placeholders that can be used as a reference for implementing custom algorithms:

After recompiling the plugin’s source code, the algorithm will be available for use in the ‘Decrypt string’ window.

After the decryption loop finishes, the instructions highlighted in purple transfer execution to the decrypted code. If we look at what is located below the purple section, we can see null bytes followed by this data at offset 0x108:

The byte sequence in the screenshot above starts with bytes 50 45 (PE), which serve a signature of PE file headers. At the same time, our shellcode starts with bytes 4D 5A (MZ), the magic bytes of PE files. As we can see, our shellcode has decrypted itself into a PE file, and now we can dump the decrypted payload to disk using the Create DEC file feature of the hrtng plugin:

media.kasperskycontenthub.com/…

As it turned out, decrypting the shellcode alone didn’t pave the way for further successful analysis. When we open the decrypted payload into IDA, we immediately notice that it fails to load correctly because its import table contains junk values:

This makes it impossible to proceed with the analysis of the loaded file, as we are unable to understand how the shellcode interacts with the operating system. To further analyze why the import table processing went wrong, we need to continue analyzing the purple part of the shellcode.

The code above transfers execution to a function coded in C, and we can decompile it for further analysis. Note that the hrtng plugin includes a component that makes reading the decompilation more convenient by highlighting curly brackets used in ‘if’ statements and loops. It is also possible to jump from one bracket to another by pressing the [ and ] hotkeys:

media.kasperskycontenthub.com/…

Upon examining the decompiled function, we can see that it first calls the sub_A9D8 function multiple times. We can also see that its second argument always contains a large number, such as 0x5C2D1A97 or 0xE0762FEB. In turn, the sub_A9D8 function calls another function named sub_A924. Its code contains the 0xEDB88320 constant, known to be used in the CRC32 hashing algorithm:

Speaking of hash functions such as CRC32, they are often used in malware to implement the Dynamic API Resolution defense evasion technique, which is used to obtain pointers to Windows API functions. This technique uses hashes to prevent strings with suspicious API function names from being included in malicious binaries, making them stealthier.

Our shellcode uses the CRC32 hash for the exact purpose of implementing the Dynamic API Resolution technique, to conceal the names of called API functions. Therefore, in order to continue analyzing our shellcode, we need to match these names with their corresponding CRC32 hash values (e.g., match the NtAllocateVirtualMemory function name with its hash 0xE0762FEB). Again, the hrtng plugin makes this process very simple with its Turn on APIHashes scan feature, which automatically searches disassembled and decompiled code for API function name hashes. When it finds such a hash, it adds a comment with its corresponding function name, renames the function pointer variable, and assigns it the correct data type:

To use this feature, it is first necessary to import Windows type libraries (such as mssdk_win10 and ntapi_win10) into IDA using the Type Libraries window, which can be accessed via the Shift + F11 hotkey. After that, searching for API hashes can be activated using the instructions in the video below:

media.kasperskycontenthub.com/…

Now that we have recovered the names of API functions concealed with API hashing, we can continue analyzing the analyzed function, namely the following code snippet:

The code above executes a loop to search for two signatures, 4D 5A (MZ) and 50 45 (PE). As we mentioned earlier, these are signatures used in PE file headers. Specifically, the byte sequence 50 45 is used in PE files to mark the beginning of the IMAGE_NT_HEADERS structure. So we can apply this structure to the bytes we have:

media.kasperskycontenthub.com/…

From the video we can see that the structure has been applied correctly, as its field values match those specified in the PE file documentation. For example, the FileHeader.Machine field contains the number 0x14C (IMAGE_FILE_MACHINE_I386), and the OptionalHeader.Magic field has the value 0x10B (PE32).
After retrieving the contents of the IMAGE_NT_HEADERS structure, the shellcode parses it. It is noteworthy that such parsing is often observed in code used to load PE files in memory. What is also important about the IMAGE_NT_HEADERS structure is that it contains the import directory offset, which is stored in the OptionalHeader.DataDirectory[1].VirtualAddress field and equal to 0x1240C.

As for the import directory, it is defined as an array of IMAGE_IMPORT_DESCRIPTOR structures. To assign these structures to the import directory in IDA, we can first import the definition of the IMAGE_IMPORT_DESCRIPTOR structure type and then apply it to the contents of the directory:

media.kasperskycontenthub.com/…

Regarding the contents of the defined structures, their first value, named OriginalFirstThunk, should point to an array of imported function names. However, if we look at the structures we just defined, we can see that this field is set to zero. This means that something must be wrong with our defined structures:

If our malware was an ordinary PE file, encountering zero values in this field would be impossible. However, remember that we are not analyzing a PE file, but rather shellcode that resembles a PE file. Because of that, it is possible that the malware developers tampered with the import directory, presenting an obstacle for researchers. Therefore, to further understand what is wrong with the defined structures and how they store names of imported functions, we need to further examine other fields of these structures.

The fourth field in this structure is called Name, and it includes the name of the library that contains the imported functions. It appears to be set correctly – for example, the shellcode contains the msvcrt.dll string at offset 0x12768. However, this is not the case with the last field, named FirstThunk, because the offsets specified in it point to odd-looking addresses. However, if we start defining members of this array as 4-byte integers, the hrtng plugin will recognize them as CRC32 API hashes, making it easy to understand which functions are being used by the malicious code. It is also worth noting that for each imported function, the plugin automatically restores their argument names and data types:

media.kasperskycontenthub.com/…

As it turns out, our shellcode processes imports by extracting function names from arrays of FirstThunk fields. Specifically, it iterates over functions exported by Windows system libraries and calculates the CRC32 hash of each function name, until the hash value matches the one from the array. After finding the matching function, the shellcode stores its address in the FirstThunk array, overwriting the CRC32 hash value.
Now that we have dealt with the imports, we can start analyzing the entry point function. To do this, we can rebase the shellcode to the address specified in the OptionalHeader.ImageBase value and then disassemble the entry point function code at address 0x407FB8 (specified in the OptionalHeader.AddressOfEntryPoint field).

We can see that this function has the following code:

This code first pushes the values of the ESI and ECX registers on the stack. It then performs various calculations involving the ESI register, such as addition, subtraction or XOR. After all the calculation instructions have been executed, the shellcode restores the values of the ESI and ECX registers using the POP instruction. As the shellcode overwrites the value in the ESI register computed by the calculation instructions, these instructions are meaningless and have been inserted to confuse the disassembler. The hrtng plugin contains a useful feature to quickly remove them – this can be done by selecting the junk code and applying the Fill with nops operation to it:

media.kasperskycontenthub.com/…

As you can see from the screenshot below, the entry point function then transfers execution to the instruction at address 0x402E40:

This address contains code that is obfuscated with yet another technique. In the screenshot below, we can see two opposite conditional jumps, ja (jump if above) and jbe (jump if below or equal), that transfer execution to the same address. Therefore, these two conditional jumps are equivalent to a single unconditional jump, and inserting these jumps prevents IDA from correctly analyzing the function.

To efficiently combat such obfuscations involving conditional and unconditional jumps, the hrtng plugin contains a unique feature called ‘Decompile obfuscated code’. It can be activated with the Alt+F5 hotkey, and as the video below shows, it can process our obfuscated code and decompile it in just a few keystrokes:

media.kasperskycontenthub.com/…

If we perform an open source search on the decompiled code from the video, we will be able to identify it as the engine of the FinSpy VM virtualization-based obfuscator. As deobfuscating virtual machines is an extremely tedious reverse engineering challenge, we will not cover it in this article, instead advising interested readers to read the following research papers.
To devirtualize the code in our sample that is protected by FinSpy VM, we will use a ready-made script available here. However, to work correctly, this script must place the functions of the FinSpy VM engines in the correct order to determine the correct virtual instruction opcode values.

Because the order of the virtual machine engine functions is different in each FinSpy sample, we need to name these functions in IDA to retrieve this order. In general, when dealing with function name identification, it is very common to use tools that perform code signature recognition. A popular example of such a tool is FLIRT, which is built into IDA and uses disassembly to compute code signatures. Unfortunately, FLIRT does not work correctly with the engine functions in our sample because their disassembly is heavily obfuscated. Nevertheless, the hrtng plugin implements a more robust alternative of FLIRT called MSIG, which is based on decompiled rather than disassembled code, and we can leverage it to successfully recognize functions in our binary. This can be done using the ‘File -> Load file -> [hrt] MSIG file’ menu.

media.kasperskycontenthub.com/…

Once all the functions are recognized, the deobfuscation plugin will be able to function correctly and produce the decompiled code of the malware. Note that thanks to the hrtng plugin, it looks as if it was never obfuscated:
media.kasperskycontenthub.com/…

The sample we reverse engineered in this article is quite complex, and we had to go through numerous steps to analyze it. First, we learned how the shellcode placed at the beginning of the sample works, and then we examined the modified PE file contained in the shellcode. While analyzing it, we studied multiple PE format structures, and tackled various obfuscation techniques such as API hashing, junk code insertion and code virtualization. We certainly wouldn’t have been able to do all that so efficiently without hrtng – this plugin can automate complex reverse engineering tasks in just a few clicks.
Actually, this plugin contains many more features than we have described in this article. You can find the full list of features as well as the plugin source code and binaries on our GitHub. We hope you find our plugin useful for automating your malware analysis workflow!

securelist.com/hrtng-ida-pro-p…

What do cats get up to in the 30 minutes or so a day that they’re awake? Being jerks, at least in our experience. But like many hackers, [Brent] wanted to quantify the activity of his cat, and this instrumented cat exercise wheel was the result.

To pull this off, [Brent] used what he had on hand, which was an M5Stack ESP32 module, a magnetic reed switch, and of course, the cat exercise wheel [Luna] seemed to be in the habit of using at about 4:00 AM daily. The wheel was adorned with a couple of neodymium magnets to trip the reed switch twice per revolution, with the pulse stream measured on one of the GPIOs. The code does a little debouncing of the switch and calculates the cat’s time and distance stats, uploading the data to OpenSearch for analysis and visualization. [Brent] kindly includes the code and the OpenSearch setup in case you want to duplicate this project.

As for results, they’re pretty consistent with what we’ve seen with similar cat-tracking efforts. A histogram of [Luna]’s activity shows that she does indeed hop on the wheel at oh-dark-thirty every day, no doubt in an effort to assassinate [Brent] via sleep deprivation. There’s also another burst of “zoomies” around 6:00 PM. But the rest of the day? Pretty much sleeping.

hackaday.com/2024/12/05/exerci…

Nell’ultimo anno i casi di abuso dei domini Cloudflare sono aumentati notevolmente (dal 100 al 250%). Cloudflare Pages e Cloudflare Workers, generalmente utilizzati per distribuire pagine Web e facilitare l’elaborazione serverless, vengono sempre più utilizzati per phishing e altre attività dannose.

Gli analisti di Fortra affermano che l’uso di questi domini ha lo scopo di aumentare la legittimità e l’efficacia percepite delle campagne dannose. Cioè, gli hacker sfruttano il marchio Cloudflare e apprezzano anche l’affidabilità dei servizi, il basso costo e le funzionalità di reverse proxy, che li aiutano a eludere il rilevamento.

Cloudflare Pages sfruttato dagli attaccanti

Cloudflare Pages è una piattaforma progettata per gli sviluppatori front-end per creare, distribuire e ospitare siti Web veloci e scalabili direttamente sulla CDN Cloudflare.

Secondo Fortra, gli aggressori utilizzano attivamente Cloudflare Pages per ospitare pagine di phishing intermedie che reindirizzano le vittime verso vari siti dannosi.

Gli utenti vengono solitamente portati a pagine Cloudflare fraudolente tramite collegamenti da PDF dannosi o e-mail di phishing, che non attirano l’attenzione delle soluzioni di sicurezza a causa della reputazione di Cloudflare.

Si noti inoltre che gli aggressori utilizzano tattiche di bccfolding per nascondere i destinatari delle e-mail e la portata delle loro campagne di spam dannose.

“Il team Fortra rileva un aumento del 198% degli attacchi di phishing utilizzando Cloudflare Pages, da 460 incidenti nel 2023 a 1.370 incidenti nell’ottobre 2024”, riferiscono i ricercatori. “Si prevede che il numero totale di attacchi supererà i 1.600 entro la fine dell’anno, con un aumento del 257% rispetto allo scorso anno (con una media di 137 incidenti al mese)”.

Anche Cloudflare Workers viene abusato dagli attaccanti

Cloudflare Workers, d’altra parte, è una piattaforma informatica serverless che consente agli sviluppatori di creare e distribuire applicazioni e script leggeri direttamente sulla rete edge di Cloudflare. In circostanze normali, i Cloudflare Worker vengono utilizzati per distribuire API, ottimizzare i contenuti, implementare firewall e CAPTCHA personalizzati, automatizzare le attività e creare microservizi.

Gli aggressori utilizzano Cloudflare Workers per eseguire attacchi DDoS, implementare siti di phishing, inserire script dannosi nei browser delle vittime e forzare le password dagli account di altre persone.

“Stiamo assistendo a un aumento del 104% degli attacchi di phishing legati alla piattaforma Cloudflare Workers. Quest’anno, questa cifra è salita a 4.999 incidenti, rispetto ai 2.447 incidenti del 2023″, afferma il rapporto Fortra. “Con una media attuale di 499 incidenti al mese, si prevede che il volume totale degli attacchi raggiungerà quasi 6.000 entro la fine dell’anno, con un aumento del 145% rispetto all’anno precedente”.

Gli esperti ricordano che per proteggersi dal phishing, compresi quelli che abusano di servizi legittimi, è necessario assicurarsi sempre che gli URL siano autentici, soprattutto se il sito richiede informazioni riservate.

Inoltre, l’attivazione di misure di sicurezza aggiuntive, come l’autenticazione a due fattori, può aiutare a prevenire il furto degli account (anche se le credenziali sono compromesse).

L'articolo Cloudflare utilizzato per Attacchi informatici: Phishing e Abusi in Crescita Esponenziale proviene da il blog della sicurezza informatica.

Veeam ha annunciato il rilascio di aggiornamenti di sicurezza per correggere una vulnerabilità critica nella Service Provider Console (VSPC), identificata come CVE-2024-42448. Questo bug potrebbe consentire l’esecuzione remota di codice (RCE) su istanze vulnerabili, rappresentando un rischio significativo per le infrastrutture interessate.

Dettagli sulla Vulnerabilità

La vulnerabilità, che presenta un punteggio CVSS di 9.9 su 10, è stata scoperta durante test interni. Secondo l’avviso rilasciato da Veeam, il problema si manifesta quando un agente di gestione autorizzato sulla macchina del server VSPC può essere sfruttato per eseguire codice da remoto sul sistema.

Un’ulteriore vulnerabilità, CVE-2024-42449 (CVSS 7.1), potrebbe consentire il furto di un hash NTLM dell’account di servizio del server VSPC e l’eliminazione di file presenti sul sistema.

Entrambe le vulnerabilità riguardano VSPC 8.1.0.21377 e tutte le versioni precedenti delle serie 7 e 8. Per mitigare il rischio, Veeam ha rilasciato la versione 8.1.0.21999, l’unica soluzione disponibile al momento. Non sono stati forniti workaround o mitigazioni alternative.

La comunicazione via mail da parte di Veeam

Le vulnerabilità nei prodotti Veeam sono frequentemente prese di mira da attori malevoli per attività come il dispiegamento di ransomware. Di conseguenza, è fondamentale aggiornare immediatamente le istanze VSPC per prevenire potenziali attacchi che potrebbero compromettere la sicurezza dei dati e l’integrità operativa.

Per contenere i rischi associati, Veeam raccomanda le seguenti azioni:

1. Aggiornare immediatamente: Applicare la versione 8.1.0.21999 disponibile sul sito ufficiale di Veeam.
2. Verificare gli accessi: Controllare e limitare gli agenti autorizzati sul server VSPC.
3. Monitorare l’infrastruttura: Implementare strumenti di monitoraggio per individuare eventuali comportamenti anomali.

Conclusione

In un panorama digitale sempre più complesso e minacciato, vulnerabilità come quelle identificate nei prodotti Veeam sottolineano l’importanza di un approccio proattivo alla sicurezza informatica. La tempestiva applicazione degli aggiornamenti e una rigorosa gestione degli accessi sono strumenti essenziali per proteggere i propri sistemi da potenziali attacchi.

Rimanere al passo con le patch di sicurezza non è solo una buona pratica, è un obbligo ineludibile. Ogni aggiornamento è una linea di difesa vitale per salvaguardare l’integrità delle infrastrutture e per evitare interruzioni devastanti che potrebbero mandare in tilt l’intera organizzazione. Non applicare le patch in tempo significa esporsi a rischi altissimi, mettendo a repentaglio l’intera operatività aziendale.

L'articolo Allarme Cybersecurity: Scoperta Vulnerabilità Critica RCE in Veeam Service Provider Console proviene da il blog della sicurezza informatica.