Need help with Windows reversing: ccdgen.exe from TI

Mychaela Falconia falcon at freecalypso.org
Sat May 6 19:46:24 UTC 2023


Hello FC community,

First of all, big thanks to Das Signal for posting the output from
both Ghidra and IDA decompilers, especially the latter, given that
it's a not-freely-available tool.  Seeing this output, I now have a
much clearer idea of the task I am looking at when it comes to
recovery and defenestration of our TI-inherited ccdgen tool.

Given other more pressing priorities across FreeCalypso and Themyscira
projects, I decided to move this ccdgen project to a back burner.  My
original motivating factors for bringing it up were:

1) There are many potential (and tentatively planned) functional
improvements in FC GSM MS firmware where the most proper implementation
would require making some additions or extensions to SAP interfaces
that are defined in ccdgen input files and then compiled by ccdgen
into cdginc C headers.  Turning ccdgen from a black box into a properly
understood glass box would enable us to act bolder with regard to
ccdgen/cdginc-controlled interfaces.

2) Proper firmware debugging requires sniffing (tracing, capturing)
the exchange of primitives between protocol stack entities.  GPF (a
foundational component of the firmware) provides a mechanism (that can
be enabled at run time in any standard production fw build) to forward
copies of all primitive exchanges of interest to the RVTMUX interface,
but then appropriate host tools are needed to make a meaningful
decoding of these binary PS primitive dumps on the host side.  TI once
had a Windows GUI tool for this job called PCO, we may have those
binaries somewhere, and I recall reading somewhere that Openmoko
apparently once managed to get it to work under Wine - but I haven't
tried it myself yet.  Obviously using a proprietary Windows GUI tool
under Wine can only be a very poor solution, and it might not work
with our TCS2/TCS3 hybrid fw because (a) our hybrid cdginc version
matches neither Openmoko nor LoCosto and (b) PCO seems to require a
DLL built with ccdgen output for the right cdginc files.  For a proper
solution we will need to develop our own replacement for TI's PCO, and
the first required step in that journey will be to acquire proper
ownership of the whole ccdgen/cdginc subsystem.

However, because this still-necessary (eventually) ccdgen
reconstruction task will be more difficult than I originally
speculated, I need to deprioritize it for the time being - there are
just too many other priorities that are more pressing.  When it comes
to actively needed tasks that touch the realm of cdginc, I will have
to limp along using current hacky methods (if I need to change
something, rerun ccdgen under Wine and diff the outputs), and use
similar crude methods for urgent protocol stack debug tasks.

Hasta la Victoria, Siempre,
Mychaela aka The Mother


More information about the Community mailing list