Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/a0zhar/babukv3

A custom version of the previously leaked source code of the Babuk ransomware which will be maintained by me. The purpose of this repo is to create a more easy to understand/maintain version of the original source code
https://github.com/a0zhar/babukv3

babuk babuk-ransomware babuk-source babuk-src leaked-ransomware leaked-source-code ransomware ransomware-source-code ransomware-src

Last synced: 10 months ago
JSON representation

A custom version of the previously leaked source code of the Babuk ransomware which will be maintained by me. The purpose of this repo is to create a more easy to understand/maintain version of the original source code

Awesome Lists containing this project

README 

          
# babukV3

 Improved, refactored, and new version of the previously leaked source code of the Babuk ransomware by VXUG. 



# Analysis of Source Code (with help of ChatGPT), in finding issues: 

## entry.cpp

1. In the `find_files_network` function:

   - The `netRes` parameter is expected to be a valid pointer to `NETRESOURCEW`, but there is no validation for a null pointer.

   - The condition `if (netRes = (LPNETRESOURCEW)_halloc(cbBuffer))` contains an assignment (`=`) instead of a comparison (`==`), which may lead to unintended behavior.

   - There is a potential buffer overflow issue when allocating memory for `netRes` using `_halloc`. The size of `cbBuffer` (16KB) is used, but there is no guarantee that the allocated memory can hold that amount of data.



2. In the `enum_shares` function:

   - The `addr` parameter is expected to be a valid pointer to a null-terminated wide string, but there is no validation for a null pointer.

   - The `NetShareEnum` function is called with a cast to `(LPWSTR)`, which assumes that the `addr` parameter is modifiable, but this may not always be the case.

   - The `lstrlenW` function is used to determine the length of the `p->shi1_netname` string, but there is no validation for a null pointer or uninitialized `p` pointer.



3. In the `_processDrive` function:

   - The `driveLetter` parameter is assumed to be a valid drive letter, but there is no validation for incorrect or unsupported values.

   - There is a potential buffer overflow issue when allocating memory for `driveBuffer` using `_halloc`. The buffer size should be 6 characters (`"\\\\?\\X:"`), but it is allocated with 7 characters, which may lead to unintended behavior.

   - The condition `if (driveType != DRIVE_REMOTE)` suggests that only local drives are processed, but there is no check for other drive types like network drives or removable drives.



4. In both `find_files_recursive` and `find_paths_recursive`, a fixed-size buffer `localDir` of 32768 `WCHAR` elements is used for constructing file and directory paths. If the path length exceeds the buffer size, it can lead to a buffer overflow. Proper bounds checking should be implemented to ensure the buffer is not overflowed.



5. Unchecked Heap Allocation: The functions `_halloc` and `_hfree` are used for memory allocation and deallocation. However, there is no explicit check for successful memory allocation. If the allocation fails and returns NULL, the code does not handle this situation. This can lead to undefined behavior if subsequent operations assume the memory is valid. It's important to check the return value of `_halloc` and handle allocation failures appropriately.



6. Incorrect String Length Calculation: In `find_files_recursive`, the `WriteFile` function is called with the length of the `ransom_note` string calculated using `lstrlenA`. However, `lstrlenA` returns the length in bytes, not the number of characters for wide strings. This can lead to incorrect file writing if the string contains non-ASCII characters. The appropriate function to use for wide strings is `lstrlenW` or `wcslen`.



7. Misuse of `lstrcmpiW`: In several places, the function `lstrcmpiW` is used for case-insensitive string comparison. However, it is used incorrectly. The comparison is made between `fd.cFileName + i` and the extension strings, but it should be comparing the extension string with the result of `lstrcmpiW`. The correct usage would be `lstrcmpiW(fd.cFileName + i, L".exe") == 0`, `lstrcmpiW(fd.cFileName + i, L".dll") == 0`, etc.



8. Potential Infinite Loop: In the `lilBabuk` function, when popping items from the `que_p` queue, the loop condition `while (TRUE)` is used without an explicit termination condition. This can result in an infinite loop if there is an error or if the queue does not reach a state where no more items are available.



9. Unclear Error Handling: Some error conditions are handled by outputting debug information, but the impact on program flow is not clear. For example, in `find_files_recursive` and `find_paths_recursive`, when `FindFirstFileW` fails, debug information is printed, but the behavior afterward is not specified. It is important to handle errors consistently and provide appropriate feedback or terminate execution if necessary.



10. Lack of Error Checking: Several API calls, such as `CreateFileW`, `WriteFile`, `FindFirstFileW`, etc., are not checked for errors. It is crucial to verify the return values of these functions and handle any potential errors that may occur.