| [12] | 1 | $Id: TODO 153 2009-06-02 22:28:07Z tim $
|
|---|
| 2 |
|
|---|
| 3 | If you are interested in contributing to this project, here's a few
|
|---|
| 4 | things you could look into:
|
|---|
| 5 |
|
|---|
| [122] | 6 | - Currently there is no way on the command line to search for exotic
|
|---|
| 7 | paths/types. For instance, if reglookup encounters an unknown VK
|
|---|
| 8 | type, it just prints it out in Hex. However, if you wanted to search
|
|---|
| 9 | specifically for that type, there is no way to do it. Similarly, it
|
|---|
| 10 | isn't possible to specify certain binary or weird characters in
|
|---|
| 11 | paths. Reglookup should take the user path and unquote each path
|
|---|
| 12 | component using the \xQQ syntax prior to searching.
|
|---|
| 13 |
|
|---|
| [153] | 14 | - It might be nice to have a way to filter results by security
|
|---|
| 15 | descriptor information. Maybe by MTIME as well.
|
|---|
| 16 |
|
|---|
| [12] | 17 | - Testing, testing, and more testing. reglookup needs to be tested on
|
|---|
| [86] | 18 | NT/XP/2k3/Vista. A regression test suite would be nice too. Some
|
|---|
| 19 | thoughts on this include a script which randomly fuzzes an existing
|
|---|
| 20 | registry file, and tries to detect crashes of reglookup when parsing
|
|---|
| 21 | it. Another test script might randomly truncate an existing registry
|
|---|
| 22 | file, which will help improve reglookup's parsing on fragmentary
|
|---|
| 23 | files.
|
|---|
| [12] | 24 |
|
|---|
| 25 | - Build system. I do not wish to use automake/autoconf in this
|
|---|
| [49] | 26 | project. I have also now decided that make is painful to use for
|
|---|
| 27 | everything. I'd like to switch to a suite of shell scripts driven by
|
|---|
| 28 | minimal make rules. If you got any ideas on this, shoot them my way.
|
|---|
| [12] | 29 |
|
|---|
| [86] | 30 | - Unicode support still needs improvement. While parsing strings seems
|
|---|
| [153] | 31 | to be decent, UTF-8 output would be nice. Need support for
|
|---|
| 32 | UTF-16LE key and value names. To do this, the UTF conversion
|
|---|
| 33 | functions need to be moved to regfi.
|
|---|
| [12] | 34 |
|
|---|
| [86] | 35 | - The interface between reglookup.c and regfi.c is much better than it
|
|---|
| [140] | 36 | used to be, but the parsing of data objects needs to be moved into the
|
|---|
| 37 | library. The quoting syntax should stay in reglookup/reglookup-recover
|
|---|
| 38 | but the basic parsing of data types into proper structures should
|
|---|
| 39 | happen in the library so that they are accessible to other users of the
|
|---|
| 40 | library.
|
|---|
| [49] | 41 |
|
|---|
| [153] | 42 | - Develop and solidify regfi API. Regfi should be better documented and
|
|---|
| 43 | eventually needs a set of Python wrappers.
|
|---|
| [86] | 44 |
|
|---|
| 45 | - Documentation. The security descriptor output format needs to be
|
|---|
| 46 | documented. Also, function contracts should be added to the
|
|---|
| 47 | lower-level functions of regfi.c.
|
|---|
| 48 |
|
|---|
| [140] | 49 | - The smb_deps.h and smb_deps.c content is almost eliminated. Just need
|
|---|
| 50 | to integrate parts that are being kept into regfi or other modules.
|
|---|
| [49] | 51 |
|
|---|
| [140] | 52 | - Need to figure out a reasonably correct way to convert UTF-16LE charaters
|
|---|
| 53 | to ASCII under Windows/MingW or other platforms that don't have proper
|
|---|
| 54 | libiconv support yet. Then a build-time option or autodetection can
|
|---|
| 55 | dictate which version of conversion function is used.
|
|---|
| [86] | 56 |
|
|---|
| [12] | 57 | - Grep through the source for 'XXX', and you'll find more.
|
|---|
