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.
|
---|