Vault7: CIA Hacking Tools Revealed

2014-01-09 Retrospective for SparrowHawk 2.0 orig

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

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?
- unsuccessful delivery to Solaris 8 sparc
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

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/Solaris resources hardware for development
- either undocumented, outdated, or "claimed" for other projects
- Solaris 8 04/04 (last release) not purchased by AED, obtained from IV&V
- Mirror of Sun Freeware packages outdated
OpenOffice for documentation is not cooperative
- documentation should be clear & concise, meant to be read
- Option: Plaintext documentation standards
  - can be held/tracked in source control
  - README, INSTALL, GOTCHAS : plain text (markdown?)
- Option: Confluence export to PDF

use of forward declarations of exposed component functions
- why not expose through C header files?
- components should have single responsibility, encapsulate functionality
wholesale copying of code from publicly available proof-of-concept (POCPoint of Contact, 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~~ preferred if size, sign, or endianness of value are never used
- clearer intent with types that include sign & bit length: int32_t, uint32_t, etc.
- User #11628962: Also dependent on APIApplication Programming Interface requirements

ID	Status	Task
1	incomplete	Due diligence on incoming requirements to scope platform support to logical constraints.
8	incomplete	Scope requirements to do incremental delivery of platforms.
2	incomplete	Incorporate regular customer demonstrations during development to prevent drift from customer expectation.
3	incomplete	Recapitalize all Sun/Sparc hardware for Solaris into reusable shared infrastructure for building and testing of Solaris applications.
4	incomplete	Obtain reliable mirror of Solaris packages (OpenCSW?) that can be updated.
5	incomplete	Decide (as a division) if AEDApplied Engineering Devision will support Solaris as a development target for future requirements.
9	incomplete	Consider communication method to keep Project Management/Leadership informed of progress (or lack thereof), schedule, hurdles. Are Jira metrics the solution for this?

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |