I've got this ancient C code that I didn't write, but I need to re-compile against newer OpenSSL with opaque structures. I've updated most of the direct struct access to use the getter functions. This is my first time working directly with the OpenSSL library in C.
I am struggling to complete the final portion of this work, which is to get the following struct members in ASN.1 format as another function needs ASN1_OBJECT passed to it:
cert->cert_info->signature->algorithm
cert->cert_info->key->algor->algorithm
I used X509_get0_tbs_sigalg(cert) to get the signature algorithm from cert, but I couldn't figure out from the i2d_* function manpage what the best practice for getting this to ASN.1 format is. I tried a couple things and felt I was just digging myself into a further hole by potentially doing it wrong.
And I couldn't find a direct way to get the key algorithm at all, I'm guessing I need to get something intermediate first?
I could potentially ditch the other function that requires an ASN1_OBJECT, although I'd like to leave that part of the code alone. Even if I did get rid of the other function that requires ASN1_OBJECT, I would still need the algorithms in string format.
Any suggestions? Thanks!
X509_get0_tbs_sigalg() returns an X509_ALGOR structure. From that you can get an ASN1_OBJECT from it using X509_ALGOR_get0.
https://www.openssl.org/docs/man1.1.1/man3/X509_ALGOR_get0.html
To get the key algorithm first get the key as an X509_PUBKEY object using X509_get_X509_PUBKEY():
https://www.openssl.org/docs/man1.1.1/man3/X509_get_X509_PUBKEY.html
From there you can use X509_PUBKEY_get0_param to get the key algorithm:
https://www.openssl.org/docs/man1.1.1/man3/X509_PUBKEY_get0_param.html
Related
I've finally managed to get code working to validate a CMS signature in Swift using OpenSSL's CMS_Verify method. Now I would like to use the STACK_OF(X509) *CMS_get0_signers(CMS_ContentInfo *cms) method to get the certificates used to sign the message. In Swift, the data type for that call would be UnsafeMutablePointer<stack_st_X509>. I'm able to get a value back for that call, so I know it's succeeding. What I don't know, is how to extract the contents of it?
I was reading the STACK API docs and it appears that access to the contents of an OpenSSL stack value is accomplished using a bunch of macros in the OpenSSL code. These macros are not carried over in Swift, however.
Does anyone know how I can go about accessing the stack_st_x509 data in Swift? I'm not terribly familiar with the OpenSSL APIs so I'm somewhat stuck.
If macros are the only way to access the data you cannot do so from swift. You must write C or Objective-C code that gets the data out that you are interested in.
You can then call these wrapper functions from swift to get your data.
Can I somehow generate documentation for 2 different languages with same code? Problem is that I have a C API that is also exposed trough a proprietary language that resembles VB.
So the exposed function in C is something like:
int Function (*PointerToObject)
While in VB it would be something like:
int Function (ByVal long PointerToObject)
I already opened another thread before about this same problem, but by that time I did not know anything about Doxygen. The last couple of days I have been reading the documentation and apparently it can create documentation for VB, but I have to have actual VB code for it to work and I don't. The only thing I have is the original C and the swig output also in C.
What I have in mind is some tool (doxygen, sphinx,...) that would enable me to create some kind of multi-language documentation from a single source (not valid doxygen, but explains the idea):
/*! \fn int Function(*PointerToObject)
* \brief A simple function.
* \Cparam[in] PointerToObject A pointer to the object being used.
* \VBparam[in] ByVal long PointerToObject A pointer to the object being used.
* \return An integer.
*/
It would be great if I could somehow integrate it to swig since it is swig that identifies the correct VB type, but I guess I maybe be asking too much.
It is a bit complicated, if I am not clear enough please leave a comment I will try to explain it further.
I'm not positive how useful this will be as I haven't done precisely what you're looking for (and it is a bit of a kludge), but under similar circumstances I came to the conclusion that our best bet was to generate a fluff object just for doxygen to document.
In our case we have an LDMud which has a few hundred driver-published external functions which don't exist in the LPC language the rest of the MUD is written in. We could parse it in its native C code as a separate documentation run and include the docs with our primary documentation. In our case we have fairly thorough plain-text documentation including what we should consider the definition of these functions to be, so we use this documentation instead to generate an object with dummy function definitions and parse the plaintext documentation into function-head comments in doxygen style. This obviously doesn't provide us the advantages of including code or in-code comments with the documentation, but it does allow us to generate the documentation in multiple forms, push it around in guides, make references to these functions from other documentation, etc.
I'm not directly familiar with C so I'm not sure if there's any introspective support for performing a programmatic inventory of the functions you need and generating dummy declarations from that information or not. If you don't and have a small number of functions I suspect it would be the best investment of your time to simply write the dummy declarations by hand. If you have a really large number of these functions it may be worth your time to use doxygen to parse the original code into XML documentation, and generate the dummy object(s) from the XML. Doxygen's XML can be a pain to deal with, but if all you really need is the declaration and arguments it is (relatively) simple.
As a final aside, if your documentation can really be thought of as internal and external, you might also want to use two or more configuration files to generate different sets of documentation saved to different locations and publish them separately to your internal/external audiences. It will make the task of providing the right amount of detail to each less frustrating. Along those lines you may also find the INTERNAL_DOCS option and the #internal / #endinternal commands useful.
This question stay in my head for a long time.
As we know, we can easily print data structure in GDB when we debugging, like gdb ptype command, it can output all field value of structure. I know GDB use bfd library to read symbolic information in object file.
My question is: if I want to do this in my C source code, how to do? because I don't want to printf each field of structure one by one. Is there have any exist library to solve this issue?
I think that library will not only meets my requirement, it will be very useful for many others programmers when writing C/C++ code.
As far as C is concerned, such a library cannot exist.
What you can do is write a compiler kind of tool that takes a struct description in some language and generates a header file with struct declarations in C, and a source file with printing code. Such tools do exist (e.g. protobuf-c), but they are mostly geared towards efficient binary serialization, not human-readable representation of C data.
I dont think there are such tools built for C which are widely used. However, you can try to write a function to take the burden and call it when needed. I know a function cannot print all sorts of structure and you've got to build each for each type of struct but it still is a better idea than to just stick to the old rule, write each time.
I have a "a pain in the a$$" task to extract/parse all standard C functions that were called in the main() function. Ex: printf, fseek, etc...
Currently, my only plan is to read each line inside the main() and search if a standard C functions exists by checking the list of standard C functions that I will also be defining (#define CFUNCTIONS "printf...")
As you know there are so many standard C functions, so defining all of them will be so annoying.
Any idea on how can I check if a string is a standard C functions?
If you have heard of cscope, try looking into the database it generates. There are instructions available at the cscope front end to list out all the functions that a given function has called.
If you look at the list of the calls from main(), you should be able to narrow down your work considerably.
If you have to parse by hand, I suggest starting with the included standard headers. They should give you a decent idea about which functions could you expect to see in main().
Either way, the work sounds non-trivial and interesting.
Parsing C source code seems simple at first blush, but as others have pointed out, the possibility of a programmer getting far off the leash by using #defines and #includes is rather common. Unless it is known that the specific program to be parsed is mild-mannered with respect to text substitution, the complexity of parsing arbitrary C source code is considerable.
Consider the less used, but far more effective tactic of parsing the object module. Compile the source module, but do not link it. To further simplify, reprocess the file containing main to remove all other functions, but leave declarations in their places.
Depending on the requirements, there are two ways to complete the task:
Write a program which opens the object module and iterates through the external reference symbol table. If the symbol matches one of the interesting function names, list it. Many platforms have library functions for parsing an object module.
Write a command file or script which uses the developer tools to examine object modules. For example, on Linux, the command nm lists external references with a U.
The task may look simple at first but in order to be really 100% sure you would need to parse the C-file. It is not sufficient to just look for the name, you need to know the context as well i.e. when to check the id, first when you have determined that the id is a function you can check if it is a standard c-runtime function.
(plus I guess it makes the task more interesting :-)
I don't think there's any way around having to define a list of standard C functions to accomplish your task. But it's even more annoying than that -- consider macros,
for example:
#define OUTPUT(foo) printf("%s\n",foo)
main()
{
OUTPUT("Ha ha!\n");
}
So you'll probably want to run your code through the preprocessor before checking
which functions are called from main(). Then you might have cases like this:
some_func("This might look like a call to fclose(fp), but surprise!\n");
So you'll probably need a full-blown parser to do this rigorously, since string literals
may span multiple lines.
I won't bring up trigraphs...that would just be pointless sadism. :-) Anyway, good luck, and happy coding!
I have in some documentation for a plugin for Dreamweaver I am making that says the following:
void **connectionData
• The connectionData argument is a
handle to the data that the agent
wants Dreamweaver to pass to it when
calling other API functions.
I have no other information than this from the manual in regard to connectionData. Thinking literally, I figured handle refered to a generic handle,however I am not able to find documentation on working with generic handles in regard to C.
HANDLE h = connectionData;
Does compile in my code. How exactly do I get the "secrets" inside this data structure/can someone explain how generic handles for C work?
Well, usually you are not supposed to get the secrets of handles; they are usually just a pointer to some internal structure inside the lib/API you are using and only the lib will know how to use it.
There is no generic rules or anything about handles, you'll have to use them as indicated by your lib's docs.
The way that this is defined, connectionData is a pointer to a pointer to something. Without knowing what is assigned to connectionData, you can't know anything else. The reason why your other statement worked is that HANDLE is probably a macro that expands to void*
To know the "Secrets," you would need to find out what struct (this is a guess - it could actually be any data type) connectionData points to, then look at the definition of that struct. I don't know how familiar you are with programming in general but a debugger allows you to easily look at the struct's fields while paused at a breakpoint.
However, as other people have said, you probably don't want to muck with the internals of whatever this points to, and only use API calls.
C developers use a "handle" data type when they specifically want to hide the internal data and keep API users from monkeying around with the implementation. A handle is sometimes just a pointer, but can also be an index into an internal lookup table.
In general, you should only use provided API functions with a handle, and learn the proper way to get the handle, understand its life cycle and how to properly dispose of it when you're done.