Roadmap / Feature request list?

[SomeCrazyGuy]

Now that the source code has been released it might be wise to have a roadmap or planned list of features available to help focus new development. I'm open for any direction the project may take, but don't want it to stagnate and become obsolete as newer libraries and kernel versions may interfere with building and running the software. I've made a short list of potential roadmap goals that I think would be a good first milestone.

• Remove pro/free build: only have a single build with all features available
• Simplify codebase by removing activation checks and code specifically for the non-pro version
• Build with more compiler warnings enabled (and fix the warnings!)
• Add the option to build against the clang analyzers (UndefinedBehaviorSanitizer, AddressSanitizer, MemorySanitizer) and Valgrind
• Add a libfuse based virtual disk (in case we don't want to continue maintaining the kernel level virtual disk driver [which freezes up a lot])
• UI improvements? this could be a whole separate list with how many annoyances there are in the UI, but to name a few:

1. Why do I have to choose the language every time the program launches?
2. "You must disconnect first!" - why isn't the option greyed out like others when its not supposed to be clicked!
3. Why does hddscviewer allow rereading the progress log every 5 seconds but hddsuperclone only syncs the file every 30 seconds
4. when you make a new project or domain file the file isnt created immediately so cannot be opened in hddscviewer
5. ideally creating a new project would also automatically create a new empty domain file to make adding a DMDE bytes file easier

[thesourcerer8]

1. I have completed most of pro/free build cleanup already, so that any version you build has all features available. Next step is to remove any leftovers from the licensing, license management, ...
2. I think I have also removed the activation checks already.
3. Good point, I'll do that.
4. Do you know how to add clang analyzer support? Any pull-requests would be welcome there.
5. libfuse support sounds like a good idea to me, yes. But we should also add fixing the kernel driver if it misbehaves.
6. I haven't used the UI myself much yet, so thanks a lot for your input. I will take a look at those issues.

[SomeCrazyGuy]

I'll set up a separate dev box from my main data recovery machine this weekend and see what I can do as far as patching the build system to support clang as well as various static and runtime analyzers. Are there any source code changes you were planning to make in the near future other than cleaning up the licensing and code leftovers?

[thesourcerer8]

I don't have any changes in the pipeline at the moment and I have other projects to work on too, so I can postpone my work until next week, so that you can cleanly work on it this weekend.

[rop12770]

One thing that could be a benefit, at least I would use it: Doing multi-drive full erase (no need for certification), but write a pattern that we might want. What do you think?

[SomeCrazyGuy]

One thing that could be a benefit, at least I would use it: Doing multi-drive full erase (no need for certification), but write a pattern that we might want. What do you think?

The nwipe package offers multi-pass erase for any connected drive with lots of configurable options for number of passes and pattern overwrite.

HDparm also allows users to send the secure erase, secure erase enhanced, discard, and sanitize commands to any connected drive.

Both of the above are freely available on most linux distributions and are well maintained, I personally don't see where we could improve on them. The erase destination option of hddsuperclone is intended to clean a drive of any previous personal info before the next time its used for a recovery.

[thesourcerer8]

From my point of view, pattern writing isn't reliable for SSD and HDD's anymore for security reasons. Wear-Leveling of SSDs, Over-Provisioning of SSDs, and similar Page Table Mechanisms for SMR HDD's But I developed a pattern generation tool a while ago which is very helpful for research, and I can contribute that one. The only way I see would be to develop Firmware-Loaders that issue ERASE commands for all data blocks on SSDs, and similar wiping tools that work on firmware level on HDD's, but that's a huge amount of effort to develop that. If you want to securely "wipe" disks, I recommend to use an operating-system level disk encryption like LUKS and to wipe the key and other meta-data when needed. No, wait, there is no way to securely wipe the key anymore. Bummer. The only thing you can do is to have the HDD/SSD vendor implement a secure wipe and have an external auditor to certificate that this actually really wipes all data, meta-data and wear-leveled old versions of all data and meta-data and meta-meta-data.

[rop12770]

Hey Guys

I don't need to securely wipe a drive, like some tools who provide certification or whatever. What I need in this case, is to erase my working drives that I use as destination, between cases. And why the pattern? Well, after I finish a case, I have a tool that searches for that specific pattern I wrote before and can tell me if the file/files are present and if so, it reports as a bad/corrupt file.

[rop12770]

Another thing: the headmap function to enable/disable heads, could that be ever implemented?

[thesourcerer8]

Ok, if you dont need secure wipe, but recognizable patterns, then I think my patterns will be helpful for you. Regarding headmap enable/disable, this depends on whether the disks provide this functionality over SATA/... or whether they allow Loaders to be injected which can provide the functionality. Unfortunately most drives/models do not allow this, so I cannot promise much, whether this will be available. Perhaps we should start by drafting an ATA standard to provide headmap information, headmap enable/disabling and sector-head mapping information, so that all HDD vendors can implement it in a sane way?

[thesourcerer8]

Hmm, so should we add a GUI for nwipe into hddsuperclone GUI, or add our own pattern writing functionality?

[rop12770]

Nwipe doesn't allow to enter the pattern we want or does it?

[SomeCrazyGuy]

If we want a simple pattern fill for the destination drive ahead of a clone we could write a simple "BAD DATA AT LBA 0x00000000000000" and have each sector show its lba number. The pattern is 32 bytes so it fits perfectly in 512/2048/4096 sector drives. its also easy to grep for in recovered files.

[thesourcerer8]

This is the original pattern I was using for several applications: https://www2.futureware.at/~philipp/ssd/initpattern.pl One enhancement I would like to do is to add a Megabyte/MiB and Gigabyte/GiB display to it, and now that you say it, a 2048/4096 sector number (+hex) would be good as well). Hmm, percentage of disk-size could be helpful too...

[thesourcerer8]

I took a look at nwipe, and I have feeling that it doesn't quite fit into nwipe.