The person paid very close attention to the details. There were a lot of them, and we both got a bit confused, but together we figured out the differences between the controllers of the same family.
11
0
Budget: 4500 UAH Deadline: 10 days
Hello!
The task is clear and interesting: static reverse *_flash_id (PE x86/x64) → restore the controller polling interface via Windows API. I work as follows:
1. Static analysis in a decompiler (Ghidra/IDA): I find all CreateFile (access flags, device names \.
PhysicalDriveX, \.
ScsiX:) and DeviceIoControl.
2. I fix the exact dwIoControlCode (SMART_RCV_DRIVE_DATA, IOCTL_SCSI_PASS_THROUGH_DIRECT, IOCTL_ATA_PASS_THROUGH and vendor-specific) + fully restore the layout of lpInBuffer / lpOutBuffer for each critical call.
3. I reconstruct the logic of VSC: how the driver filters are bypassed to output Flash ID.
4. I write clean C/C++ (without .NET/Python/PowerShell), transparently; compilation MSVC/MinGW without warnings; + a module for parsing raw buffer: controller model, vendor/type of flash (Micron 96L TLC, Samsung MLC, YMTC…), full Flash ID in hex.
5. I verify the output with the original utility — this is the acceptance criterion.
I suggest starting with one controller/family, then replicating. For blind reverse engineering (Scenario B), I accept your distribution of 60% upon compilation + 40% after confirmation on the hardware — this is fair: without the physical storage device, vendor teams cannot prove it 100%.
From you to start: a set of exe, examples of the original text report, a list of priority controllers, and whether there is a test SSD/NVMe.
The price for the first stage (one controller/family): 27,000 UAH, term ~10 working days.
0
0
Budget: 8000 UAH Deadline: 10 days
The task perfectly aligns with my technical stack and interests. I am a professional in reverse engineering (IDA Pro, Ghidra), low-level development (C, C++, Assembly), and security research. I have top placements in hardcore international competitions such as DiceCTF and UMDCTF, where deep static analysis of binaries (PE x86/x64), "blind reverse" engineering, and recovering unknown data structures are fundamental skills for victory.
In addition, I have practical experience working with the OS kernel — I am currently developing my own kernel-mode driver (DeFexDriver). Therefore, I have a clear understanding of how the Windows driver stack works, how IRP requests are formed, and how CreateFile and DeviceIoControl operate at a low level. Tracking parameters, reconstructing dwIoControlCode (including SMART_RCV_DRIVE_DATA, IOCTL_SCSI_PASS_THROUGH_DIRECT, etc.), and restoring the exact layout of lpInBuffer and lpOutBuffer for Vadim Ochkina's utilities is a transparent and understandable task for me.
53
0
Budget: 10000 UAH Deadline: 7 days
Good day.
I have over 10 years of experience with C/C++, and I have also worked a lot with reverse engineering, WinAPI, system utilities, and program performance analysis.
The project is interesting, but it would be better to approach the scope in stages. I would suggest starting with one utility/one controller, analyzing the logic, restoring the data structures, and producing a working result. Then we can proceed similarly with the next ones.
0
0
Budget: 27000 UAH Deadline: 10 days
I already have a practically ready similar solution for low-level polling via the Windows API, which can be quickly adapted to your *_flash_id and we can proceed step by step here on the platform.))
I would estimate around 10 working days and 28,000 UAH for the first controlled phase - one controller or one family of utilities, with C/C++ code, description of CreateFile, DeviceIoControl, IOCTL, and buffer structures.
I can work not from beautiful theory, but from verifiable results - static analysis of PE x86/x64, reconstruction of structures, a separate module for parsing raw buffers, and comparing the output with the original utility.
From the client's side, we need the original exe files, examples of the text report from the original utility, a list of priority controllers, and information on whether there is a test SSD/NVMe for the first phase.
An important nuance - for blind reverse engineering, I would split the payment as in your scenario B, because without the physical storage device, it is impossible to prove the correctness of vendor commands 100 percent.
Question - which controller do you want to take first for the pilot, Phison, Silicon Motion, Realtek, or another?
Question - do you have the log of the original *_flash_id for this same storage device to compare the controller model, type of flash memory, and Flash ID?
Similar cases with a level of complex engineering logic are Ingello:
- https://business.ingello.com/platforma - complex system architecture and modular logic
- https://business.ingello.com/fractal - automation of research and decision-making, which may be useful for semi-automatic log analysis
- https://systems-fl.ingello.com/ua
The list does not show proposals concealed by the client or freelancer with a Plus profile, as well as proposals violating rules
