Vault7: CIA Hacking Tools Revealed
Navigation: » Latest version
Owner: User #524297
2014-01-09 Retrospective for SparrowHawk 2.0
| Date | Jan 09, 2014 |
|---|---|
| Project |
Sparrowhawk , ('jira' missing) |
| Participants | User #524297 , User #11628962, User #71380 |
Retrospective
What did we do well?
- common userspace client components, eased porting to new platform
- use of automated build tool (GNU Autotools)
- accessibility of project lead resources for consultation
- Solaris platform solution: STREAMS modules
- very portable across Solaris versions and architectures
What should we have done better?
Requirements HIGH
- initial requirement drawn for too many different platforms at once
- 8 in all: solaris 8,9,10,11 on sparc; solaris 10,11 on x86 (32/64bit)
- solaris 11 on 32-bit x86 not supported by Oracle
- would this have been better as incremental delivery?
- lacked incorporation of regular customer demos
- prevent drift from customer expectation
- assumptions made about requirements
- that local console is always handled virtually
- /dev/console does not always use the pseudoterminal driver (pts)
- additional time spent adding code to manually attach module to local console
Resources MED
-
Autotools only partially implemented across the product
- Autotools creates additional complexity, build requirements
- A partially automated build process cannot be automated across build servers
- lack of automated testing capability
- difficult to test across multiple platforms
- lack of available Sparc hardware for development
- either undocumented, outdated, or "claimed" for other projects
- OpenOffice for documentation is not cooperative
- documentation should be clear & concise, meant to be read
- Plaintext documentation standards - can be held in source control
- README, INSTALL, GOTCHAS : plain text (markdown?)
- Confluence export to PDF
Coding Style LOW
- use of forward declarations of exposed component functions
- why not expose through C header files?
- component single responsibility
- wholesale copying of code from publicly available proof-of-concept
- building does not equal working
- no break from POC, strings and other signatures need to be removed
- debug/error handling capability needed
- cumbersome syntax for debug macros
- compiler specific instructions
- GCC-specific structure packing produced problems across different platforms
- Solaris dev tools (cc) did not honor structure packing
- different compilers used for different components
- Solaris dev tools (cc) used for kernel component -- is this necessary?
- GCC did not seem to compile a working kernel module -- more research?
- keeping code DRY (don't repeat yourself)
- swabbing endianness of bytes back and forth as needed instead of only once
- opening/closing file descriptors for devices multiple times
- common structures used in both userspace & kernel defined by separate files
- use of plain integer (int) type for data values
- sufficient only if size, sign, or endianness of value are never used
- clearer intent with types that include sign & bit length: int32_t, uint32_t, etc.
Actions
| ID | Status | Task |
|---|---|---|
| 1 | incomplete | @mention a person to assign them an action item |