1 | $Id: TODO 140 2009-02-09 19:53:39Z tim $ |
---|
2 | |
---|
3 | If you are interested in contributing to this project, here's a few |
---|
4 | things you could look into: |
---|
5 | |
---|
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 | |
---|
14 | - Testing, testing, and more testing. reglookup needs to be tested on |
---|
15 | NT/XP/2k3/Vista. A regression test suite would be nice too. Some |
---|
16 | thoughts on this include a script which randomly fuzzes an existing |
---|
17 | registry file, and tries to detect crashes of reglookup when parsing |
---|
18 | it. Another test script might randomly truncate an existing registry |
---|
19 | file, which will help improve reglookup's parsing on fragmentary |
---|
20 | files. |
---|
21 | |
---|
22 | - Build system. I do not wish to use automake/autoconf in this |
---|
23 | project. I have also now decided that make is painful to use for |
---|
24 | everything. I'd like to switch to a suite of shell scripts driven by |
---|
25 | minimal make rules. If you got any ideas on this, shoot them my way. |
---|
26 | |
---|
27 | - Unicode support still needs improvement. While parsing strings seems |
---|
28 | to be decent, UTF-8 output would be nice. |
---|
29 | |
---|
30 | - The interface between reglookup.c and regfi.c is much better than it |
---|
31 | used to be, but the parsing of data objects needs to be moved into the |
---|
32 | library. The quoting syntax should stay in reglookup/reglookup-recover |
---|
33 | but the basic parsing of data types into proper structures should |
---|
34 | happen in the library so that they are accessible to other users of the |
---|
35 | library. |
---|
36 | |
---|
37 | - NK/VK/SK record caching. Right now, HBIN metadata and SK records are |
---|
38 | cached, but it's pretty haphazard, and NK/VK records are repeatedly |
---|
39 | re-parsed. A generic caching library has been introduced but needs to |
---|
40 | be applied to NK records at a minimum. Eventually, VK records and |
---|
41 | data should also be cached separately and only be parsed when needed, |
---|
42 | rather than when a key is loaded up front. Caching also needs |
---|
43 | configurable object limits, preferrably configurable at build-time. |
---|
44 | |
---|
45 | - It might be nice to have a way to filter results by security |
---|
46 | descriptor information. Maybe by MTIME as well. |
---|
47 | |
---|
48 | - Documentation. The security descriptor output format needs to be |
---|
49 | documented. Also, function contracts should be added to the |
---|
50 | lower-level functions of regfi.c. |
---|
51 | |
---|
52 | - The smb_deps.h and smb_deps.c content is almost eliminated. Just need |
---|
53 | to integrate parts that are being kept into regfi or other modules. |
---|
54 | |
---|
55 | - Need to figure out a reasonably correct way to convert UTF-16LE charaters |
---|
56 | to ASCII under Windows/MingW or other platforms that don't have proper |
---|
57 | libiconv support yet. Then a build-time option or autodetection can |
---|
58 | dictate which version of conversion function is used. |
---|
59 | |
---|
60 | - It appears the registry may actually support UTF-16LE names on keys, |
---|
61 | if the key type field is set appropriately. Once data parsing is |
---|
62 | integrated into regfi, then the UTF-16LE handling routines (which |
---|
63 | would then be built-in) should be used to properly handle this case. |
---|
64 | |
---|
65 | - Grep through the source for 'XXX', and you'll find more. |
---|