I have a valid encoded ASN1 binary blob, which I want to modify.
Moreover, I don't have the encoded ASN1's definitions file, but I know it's structure (e.g. let's say it's a sequence that contains few integers and an octet string).
Therefore I'd prefer to modify the encoded binary by iterating over the sequence and it's fields, modify them by setting new values and encoding the new modified binary blob.
How can i do that? i.e. How can I parse the encoded ASN1 binary, modify it and re-encode it in C language? Is there any library that is able to do that?
I'm developing a software module in C for Windows. This is important to note because (in general) many library are Linux oriented and had trouble with building them for Windows.
Thanks.
I used asn1c for this in a past project. You do need the specification: asn1c generates a decoder and encoders based on it. Sounds like in your case it wouldn't be hard to write it.
It will work on Windows. The FAQ claims the compiler now requires GCC and cannot be compiled with MSVC though. You can get GCC for Windows from www.mingw.org or Cygwin.
Related
I need to use .desc files to enable the reading of serialized protocol-buffer messages and their conversion to JSON (using jansson).
This is because the protocol-buffer message formats will change much more frequently than the C code. The .desc files will be a runtime input to the executable.
I've found https://github.com/Sannis/protobuf2json-c but my reading of this is that it needs C code to be generated. In particular the ProtobufCMessage needs to exist for the message being decoded, and I cannot see a way of making a ProtobufCMessage (from /usr/include/google/protobuf-c/protobuf-c.h) without generating C code.
Have I missed something here, or will I need to write new code?
I'm not familiar with the .desc extension but I'm guessing from the context that it is a file containing a protobuf FileDescriptorProto, defined in google/protobuf/descriptor.proto.
To do what you want, you will most likely need to use the Protobuf C++ or Java library, each of which defines a class DynamicMessage which has the ability to emulate arbitrary message types based on descriptors. You can then combine this with any Protobuf-JSON library that is based on the standard Protobuf reflection interfaces. (You can also write your own JSON converter pretty easily; use the TextFormat class (found in both the C++ and Java Protobuf libs) as a template.)
My understanding is that protobuf-c does not currently contain an equivalent to DynamicMessage.
I have an FTP application sending binary files over the TCP sockets.
I have opened the file using open and reading the binary files as if they were string files (Program works fine with text files) and then sending them over TCP.
But I'm struggling with the output at the other end. I wanted to know if fopen is better suited for binary files or binary files can be treated as text files.
On Linux, there is no notion of binary or text file (contrarily to Windows, where it is relevant), which appears only in the C99 standard fopen(3) function which says:
The mode string can also include the letter 'b' either as a last
character or as a character between the characters in any of the two-
character strings described above. This is strictly for
compatibility with C89 and has no effect; the 'b' is ignored on all
POSIX conforming systems, including Linux. (Other systems may treat
text files and binary files differently, and adding the 'b' may be a
good idea if you do I/O to a binary file and expect that your program
may be ported to non-UNIX environments.)
Of course you can use the open(2) syscall directly (BTW, fopen uses it).
However, binary files are much less portable (e.g. because of endianness issues) than textual ones. Read about serialization, so perhaps prefer textual formats and protocols e.g. JSON to binary ones.
Regarding FTP on the client side, consider perhaps using existing libraries like libcurl
I am very much new to Device driver programming.
I was going through below website.
http://www.codeproject.com/KB/system/driverdev.aspx
I was just confused with the word "binary".
The particular statement says "The linker builds the final binary, and based on what the options are in the PE header....".
So my question is what does binary means in Device Driver programming?
Firstly See Binary File on Wikipedia
Generally a binary file is any file that stores data in a non-human readable format.
Therefore, word processor documents, spread sheets, databases and executable files (runnable program files) are all binary files (if you open them in a simple text editor, or echo them to the console, they don't make a lick of sense, they need another program or the OS to make sense of them).
In this instance "final binary file" would be the executable (or library file) that your source code is compiled to.
None of this is linux specific, but is general across all computer artectures (and probably some pedant will point out a computer/OS where this doesn't apply, so nearly all or all common could replace the all above)
Hope this helps
Binary means the compiled and linked object code, as opposed to the source code.
I am working at a OS independent file manager, using SDL_ttf to draw my text.
On Windows, everything works well, but on Linux I have to use the UTF8 functions of SDL_ttf, because the filenames can be UTF8 encoded.
This works well, but if I have my own C string (not a file name) such as "Ää", it will be displayed wrong. Is there any way to tell gcc to encode my strings as UTF8?
You don't need anything special from your C compiler for UTF-8 string literals. Proper support for it in the APIs you use is another matter, but that seems to be covered.
What you do need to do is to make sure your source files are actually saved in UTF-8, so that non-ASCII characters don't get converted to some other encoding when you edit or save the file.
The compiler doesn't need specific UTF-8 support, as long as it assumes 8-bit characters and the usual ASCII values for any syntactically significant characters; in other words, it's almost certainly not the problem.
gcc should interpret your source code and string literals as UTF-8 by default. Try -fexec-charset
See also: http://gcc.gnu.org/onlinedocs/gcc-4.0.1/cpp/Implementation_002ddefined-behavior.html#Implementation_002ddefined-behavior
C should have some sort of Unicode string literal syntax. Googling for "Unicode programming C" should get you started, two tutorials that seemed good are the one on developerworks and the one on cprogramming.com.
The general approach for your specific case would be using a wide string literal L"Ää", then converting that into UTF-8 with wcstrtombs().
I need a function to encode base64 and a function to decode base64 string in c. I found http://base64.sourceforge.net/b64.c but the functions work on files, not strings, and add line breaks. I need one that simply encodes/decodes strings. Where can I find such a sourcecode?
Get the functions from libb64.
If you have openssl available to you (which most *nix distros seem to have out-of-the-box these days), it provides robust, well-tested base64 encoding/decoding out of the box. This site has a decent code sample: Howto base64 decode with C/C++ and OpenSSL
When I needed to use Base64 encoding to build an encrypted email server, I decided to build my own implementation.
Currently, it's placed within a C++ class; but I wrote the encoding functions without using any c++ specific code, so you can copy and paste as you please.
This implementation is not approved by any organizations; but it should help you with learning how the algorithm works, while also giving you access to just base64 encoding. IE: no extra libraries get included.
https://github.com/AlexBestoso/Base64
Use as you please. The functions take chars, maps them to an integer via bit-wise operations, and then produces your result.
Currently, there's no newline or carriage return, which specified in the MIME implementation.
If you decide to use the code and find any bugs, let me know through github.