stat() does not work for .so files - c

I am facing an issue with stat() . stat() does not seem to be working with .so files. It gives the error
No such file or directory .
Why is this happening?
As requested I paste a portion of the code:
int main()
{
char str[300];
struct stat str_buf;
strcpy(str,"path/to/my/library/libfuncs.so");
if(stat(str,$str_buf)==-1)
perror("stat");
....
}
Thus the error comes as
stat No such file or directory
But the same code works fine for other files and directories. libfuncs.so is my generated shared library.

Many ".so" files are in fact symbolic links due to versioning issues. You might want to use lstat() in those cases, to stat the actual link.
The error you're getting ("No such file or directory") seems to imply that the symbolic link is pointing at something that doesn't exist. In these cases stat:ing the link itself helps, but of course that might not be what you want to do. Check the link's target. If the path in the link is relative, perhaps you're executing the code from a different directory?

Probable reason
I can only guess that "path/to/my/library/libfuncs.so" does not really exist. You could test that simply by typing ls "path/to/my/library/libfuncs.so".
I am pretty sure that
stat() does not work
I guess this once again solves for a "bug" in a very well established library.
Theoratically possible reason.
You use $ for a variable name. That is not permitted. The C99 Standard has this to say about this:
Both the basic source and basic execution character sets shall have the following
members: the 26 uppercase letters of the Latin alphabet
A B C D E F G H I J K L M
N O P Q R S T U V W X Y Z
the 26 lowercase letters of the Latin alphabet
a b c d e f g h i j k l m
n o p q r s t u v w x y z
the 10 decimal digits 0 1 2 3 4 5 6 7 8 9
the following 29 graphic characters
! " # % & ' ( ) * + , - . / :
; < = > ? [ \ ] ^ _ { | } ~
Further:
If ...
any
other characters are encountered in a source file (except in an identifier, a character
constant, a string literal, a header name, a comment, or a preprocessing token that is never converted to a token),
guess what? ** drumroll **
the behavior is undefined.
Yay party.but I think it is the first reason.

Related

mbedtls cannot parse valid x509 certificate

I have the following certificate:
-----BEGIN CERTIFICATE-----
MIIDWjCCAkKgAwIBAgIVAJ3wzBnLSnQvYi31rNVQRAXDUO/zMA0GCSqGSIb3DQEB
CwUAME0xSzBJBgNVBAsMQkFtYXpvbiBXZWIgU2VydmljZXMgTz1BbWF6b24uY29t
IEluYy4gTD1TZWF0dGxlIFNUPVdhc2hpbmd0b24gQz1VUzAeFw0yMDA3MjgxMTMz
MTJaFw00OTEyMzEyMzU5NTlaMB4xHDAaBgNVBAMME0FXUyBJb1QgQ2VydGlmaWNh
dGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHc2tmezGoekLjkQlb
+YOBKFyPswYR+GLq/JRVbFX2k4OrHF5js4GTfbHm1oQ733KbcnIugdejtQnRhtnr
1HRk3pqedVhRKGRo2DFDYyuX3K1UR6xna1poJF+6WNy6vXGxIQYKi7SNS5LtzkRT
1FCziOLBaxfcCRNgR1NBHjlcFsUWyL4evMok6h/wU7HA3/dfKEisyLdh3sMy7Yox
Im/ldvyX+9pH7Hj0TrGGTd5f8GtX8npNuSKdkntuag95r+vAaAPp6bQVyPWm8T/G
SUN8N7Nvc9DOcJ8ZhvB/Ubq+Fa/eoUnr3SgXInufLHhrfxJW7dyrBTlw/1kdXgYw
YiKnAgMBAAGjYDBeMB8GA1UdIwQYMBaAFP4UzdqnzQ4l89+D7UhXC5MKWnOJMB0G
A1UdDgQWBBSn95OHFqTn3DrE3anpNq5RoOsT+DAMBgNVHRMBAf8EAjAAMA4GA1Ud
DwEB/wQEAwIHgDANBgkqhkiG9w0BAQsFAAOCAQEA2Hvrxy2N0xt3I/w/7JIyoTH4
ixUKMaD1QXe+g6LrsQSCVVsaq0L468OpyydVzQLQONXvDDRv3rqIEel1hPAJNG0y
dp3g+WC1dPl7E44btM+59gBf1369lFwV6FbJMwCltVBUJ4hFAjt3QTkWRHq6DlFQ
wa896aSr5UUiVNAJjf/hLVjERlVG4wDjPN7YifQssRqlNcYDgok3UhVsBfKIGnct
WFbisX+0ONMyNnE1Qq6bX5g4sLN7VlwFhADiz1Xp2rUtLECR1NSPutYibWyvJJ8d
htYYV1a0FSkg7JKyvOIJ8IYKEPsKE+UYo1Z8DwkmHHcap+h0OMWAnKQgRXn6QQ==
-----END CERTIFICATE-----
I fed this into several certificate reading sites, and they were all able to parse and display its contents.
I tried using mbedtls to parse this certificate using the following code:
mbedtls_x509_crt certificate;
mbedtls_x509_crt_init(&certificate);
char certificate_string[] = "-----BEGIN CERTIFICATE--..."
int result_code = mbedtls_x509_crt_parse(&certificate, (unsigned char*)certificate_string, strlen(certificate_string));
if(result_code != 0) {
char err_str[256];
mbedtls_strerror(result_code, err_str, 256);
printf("Could not read the certificate. Error: %s\n", err_str);
return -1;
}
I then check the result_code for 0, and print the error message if it is not. I get the following error message every time I try to parse this certificate:
"Could not read the certificate. Error: X509 - The CRT/CRL/CSR format is invalid, e.g. different type expected"
I tried looking at the mbedtls_x509_crt_parse code to see what causes this message, and I then modified the code to use the following pieces of mbedtls_x509_crt_parse instead:
mbedtls_pem_context pem;
size_t use_len;
mbedtls_pem_init(&pem);
// If we get there, we know the string is null-terminated
int ret = mbedtls_pem_read_buffer(&pem,
"-----BEGIN CERTIFICATE-----",
"-----END CERTIFICATE-----",
(unsigned char *)certificate_string,
NULL,
0,
&use_len);
if(ret != 0) {
printf("we could not pem read the string\n");
return -1;
}
else {
printf("We pem read the certificate\n");
}
ret = mbedtls_x509_crt_parse_der(&certificate, pem.buf, pem.buflen);
if(ret != 0) {
printf("crt parse der has failed\n");
}
else {
printf("The issuer is: %s\n", certificate.issuer.val.p);
return 0;
}
When I run the program, I get the following output:
491231235959Z010�Uzon Web Services O=Amazon.com Inc. L=Seattle ST=Washington C=US0
*�H�� AWS IoT Certificate0�"0
I kept searching for answers as to what may be wrong, and I found a post saying that mbedtls is configured by default to use RSA 1024, so if your key is 2048 (and it is in mine) then mbedtls will have an error with parsing. I modified the configuration file to use 2048 and I rebuilt the library, but I still get errors.
Any ideas? I feel like I am really close, because mbedtls_x509_crt_parse executes almost the whole way through. I am pretty sure I am using the library correctly based on code samples I have seen.
Thanks!
Initially, the PEM format certificate string was parsed with the following code:
mbedtls_x509_crt certificate;
mbedtls_x509_crt_init(&certificate);
char certificate_string[] = "-----BEGIN CERTIFICATE--..."; // actually much longer
int result_code = mbedtls_x509_crt_parse(&certificate, (unsigned char*)certificate_string, strlen(certificate_string));
That resulted in a parsing error because for PEM format input, the final argument of the call to mbedtls_x509_crt certificate should be the length of the input including the null terminator. Changing the final argument to 1 + strlen(certificate_string) fixes the issue.
After successfully parsing, the issuer string was printed using:
printf("The issuer is: %s\n", certificate.issuer.val.p);
That produced some junk output that looked as if the initial part of the issuer string had been overwritten, but was actually due to the lack of a null terminator in the issuer string. The bytes of data after the issuer string included ASCII CR characters causing the terminal cursor position to move to the start of the line and print over the initial part of the output. (The CR characters can be seen by piping the output through | od -c for example, wherewith they are displayed as \r.)
Piping the output through | od -c produces:
0000000 T h e i s s u e r i s : A
0000020 m a z o n W e b S e r v i c
0000040 e s O = A m a z o n . c o m
0000060 I n c . L = S e a t t l e S
0000100 T = W a s h i n g t o n C = U
0000120 S 0 036 027 \r 2 0 0 7 2 8 1 1 3 3 1
0000140 2 Z 027 \r 4 9 1 2 3 1 2 3 5 9 5 9
0000160 Z 0 036 1 034 0 032 006 003 U 004 003 \f 023 A W
0000200 S I o T C e r t i f i c a t
0000220 e 0 202 001 " 0 \r 006 \t * 206 H 206 367 \r 001
0000240 001 001 005 \n
0000244
That shows unprintable bytes as 3-digit octal codes or as C backslash escape codes, depending on the byte value.
To print the issuer string without the junk, change the printf call to the following:
printf("The issuer is: %.*s\n", (int)certificate.issuer.val.len, certificate.issuer.val.p);

Log whether a global variable has been read or written

Requirement:
Given a C program I have to identify whether the functions accessing global variables are reading them or writing them.
Example code:
#include <stdio.h>
/* global variable declaration */
int g = 20;
int main()
{
/* writing the global variable */
g = 10;
/* reading the global variable */
printf ("value of g = %d\n", g);
return 0;
}
Executing the above code I want to generate a log file in the below format:
1- Global variable a written in function main() "TIME_STAMP"
2- Global variable a read in function main() "TIME_STAMP"
Research:
I am cetainly able to acheive this by doing a static analysis of source code as per below logic:
Go through the c code and identify the statements where the global
variable is read.
Then analysis the c code statement to identify if
it is a read or write statement.(Checking if ++ or -- operator is
used with global variable or any assignemnt has been made to the
global variable)
Add a log statement above the identified statement which will execute
along with this statement execution.
This is not a proper implementation.
Some studies:
I have gone through how debuggers are able to capture information.
Some links in the internet:
How to catch a memory write and call function with address of write
Not completely answering your question, but to just log access you could do:
#include <stdio.h>
int g = 0;
#define g (*(fprintf(stderr, "accessing g from %s. g = %d\n", __FUNCTION__, g), &g))
void foo(void)
{
g = 2;
printf("g=%d\n", g);
}
void bar(void)
{
g = 3;
printf("g=%d\n", g);
}
int main(void)
{
printf("g=%d\n", g);
g = 1;
foo();
bar();
printf("g=%d\n", g);
}
Which would print:
accessing g from main. g = 0
g=0
accessing g from main. g = 0
accessing g from foo. g = 1
accessing g from foo. g = 2
g=2
accessing g from bar. g = 2
accessing g from bar. g = 3
g=3
accessing g from main. g = 3
g=3
Below is the way i solved this problem:
I created a utility(In java) which works as below(C program source file is the input to my utility):
Parse the file line by line identifying the variables and functions.
It stores global variables in a separate container and look for lines using them.
For every line which access the global variable i am analyzing them identifying whether it is a read operation or write operation(ex: ==, +=, -+
etc are write operation).
For every such operation i am instrumenting the code as suggested by #alk(https://stackoverflow.com/a/41158928/6160431) and that in turn will generate the log file when i execute the modified source file.
I am certainly able to achieve what i want but still looking for better implementation if anyone have.
For further discussion if anybody want we can have have a chat.
I refer the source code and algos from the below tools:
http://www.dyninst.org/
https://software.intel.com/en-us/articles/pin-a-dynamic-binary-instrumentation-tool

Comparing paths with special characters on Mac UTF-8

We have a kext that checks if a path is a subdir of another path and does some magic if it is.
This all works fine as long we don't have special characters in our path (characters like ë)
We feed some working paths into the system by a helper application that can communicate with the kext.
I've isolated the problem to this code:
#include <stdio.h>
#include <string.h>
int main ()
{
char* path = "/Users/user/test/tëst/test"; //Sent by the system
char* wp = "/Users/user/test/tëst"; //Some path we claim to be ours
size_t wp_len = strlen(wp);
if (strncmp (wp,path,wp_len) == 0) //Check is path is a subpath
{
printf ("matched %s\n", path);
}else {
printf ("could not match\n");
}
return 0;
}
I've created a Gist, so the encoding does not go lost with the browser: https://gist.github.com/fvandepitte/ec28f4321a48061808d0095853af7bd7
Someone knows how i can check if path is a subpath of wp without losing too much performance (this code runs in the kernel)?
I've copy/pasted the source straight from the browser into a file (test.c). It prints could not match for me.
If I dump the file using od this is what I see:
bash-3.2$ od -c test.c
0000000 # i n c l u d e < s t d i o .
0000020 h > \n # i n c l u d e < s t r
0000040 i n g . h > \n \n i n t m a i n
0000060 ( ) \n { \n c h a r * p a
0000100 t h = " / U s e r s / u s e
0000120 r / t e s t / t ë ** s t / t e s
0000140 t " ; / / S e n t b y t h
0000160 e s y s t e m \n c h a r *
0000200 w p = " / U s e r s /
0000220 u s e r / t e s t / t e ̈ ** s t
0000240 " ; / / S o m e p a t h w
Notice that the tëst of path comes out as t ë ** s t,
but the tëst of wp comes out as t e ̈ ** s t, which is different: so strncmp will fail when comparing ë and e.
If I copy the tëst from path paste that into wp's assignment then I get matched /Users/user/test/tëst/test, so strncmp seems to work fine.
I don't know these two strings differ like this, I can only assume that the two strings are using different encodings somehow. The strncmp function compares strings per byte, so ë and e ̈ are considered different. If you want to use strncmp, then unfortunately there's no easy solution to this other than insuring that both strings use the same encoding.
FWIW - I'm running on macOS 10.12.1, with clang version Apple LLVM version 8.0.0 (clang-800.0.42.1)
EDIT: I've downloaded pathtest.cpp from your github link just to double-check things. I've run od -c pathtest.cpp and I see the same problem.

31 bit limit on bit operations in R

I am trying to get around the 31-bit limit for bit operations in R. I can do this in pure R, but my issue is about implementing this in C for use in R.
Example
For example I have the data
> x = c(2147028898, 2147515013)
where each element is at most 32 bits, unsigned, and on which I'd like to do bit operations such as (but not limited to) (x >> 20) & 0xFFF. The end goal would be using many of these kinds of operations in a single function.
The two numbers are of different bit lengths.
> log2(x)
[1] 30.99969446331090239255 31.00002107107989246515
Normal bitwise operations in R yield the following result, ie NAs are introduced for the larger of the two.
> bitwShiftR(x,20)
[1] 2047 NA
Warning message:
In bitwShiftR(x, 20) : NAs introduced by coercion
> bitwAnd(x,20)
[1] 0 NA
Warning message:
In bitwAnd(x, 20) : NAs introduced by coercion
Workaround with R package 'bitops'
The bitopspackage does what I want, but my end goal is something more advanced, and I want to be able to use C, see below.
> library(bitops)
> bitShiftR(x,20)
[1] 2047 2048
I have looked at the C code for this package, but I don't really understand it. Does it have to be that complicated, or is that just for optimization for vectorized inputs and outputs?
Workaround in C (the issue)
My code is as follows, only a simple expression so far. I have tried different types in C, but to no avail.
#include <R.h>
void myBitOp(int *x, int *result) {
*result = (*x >> 20) & 0xFFF;
}
which I then compile with R CMD SHLIB myBitOp.c on a 64 bit machine.
$uname -a
Linux xxxxxxxxx 3.0.74-0.6.8-xen #1 SMP Wed May 15 07:26:33 UTC 2013 (5e244d7) x86_64 x86_64 x86_64 GNU/Linux
In R I load this with
> dyn.load("myBitOp.so")
> myBitOp <- function(x) .C("myBitOp", as.integer(x), as.integer(0))[[2]]
When I run the function I get back
> myBitOp(x[1])
[1] 2047
> myBitOp(x[2])
Error in myBitOp(x[2]) : NAs in foreign function call (arg 1)
In addition: Warning message:
In myBitOp(x[2]) : NAs introduced by coercion
So the question is, why do I get these NAs with this C code, and how do I fix it? The return value will always be much less than 31 bits btw.
Thank you!
Update
After studying the bitops code a bit more, and going through this presentation among other links I came up with this code (bonus vectorization here)
#include <R.h>
#include <Rdefines.h>
SEXP myBitOp(SEXP x) {
PROTECT (x = AS_NUMERIC(x) ) ;
double *xx = NUMERIC_POINTER(x);
SEXP result = PROTECT(NEW_NUMERIC(length(x)));
double *xresult = NUMERIC_POINTER(result);
for( int i=0; i < length(x); i++) {
xresult[i] = (double) ((((unsigned int) xx[i]) >> 20) & 0xFFF);
}
UNPROTECT(2);
return(result);
}
Compile with R CMD SHLIB myBitOp.c
And in R:
> dyn.load("myBitOp.so")
> myBitOp <- function(x) .Call("myBitOp", x)
> myBitOp(x)
[1] 2047 2048
I don't fully understand why or how yet, but it works, well seems to work for this example at least.
The second element of as.integer(x) will be NA because it's larger than .Machine$integer.max. NAOK = FALSE in your call to .C, so that NA in your input results in an error. Your call to .C will "succeed" if you set NAOK = TRUE (because, in this case, NA is technically NA_integer_, which is a special int value in C).
You'll have to be creative to get around this. You could try splitting values > 2^31-1 into two values, pass both of them to C, convert them to unsigned integers, sum them, convert the result to a signed integer, then pass back to R.

Overwriting lines in file in C

I'm doing a project on filesystems on a university operating systems course, my C program should simulate a simple filesystem in a human-readable file, so the file should be based on lines, a line will be a "sector". I've learned, that lines must be of the same length to be overwritten, so I'll pad them with ascii zeroes till the end of the line and leave a certain amount of lines of ascii zeroes that can be filled later.
Now I'm making a test program to see if it works like I want it to, but it doesnt. The critical part of my code:
file = fopen("irasproba_tesztfajl.txt", "r+"); //it is previously loaded with 10 copies of the line I'll print later in reverse order
/* this finds the 3rd line */
int count = 0; //how much have we gone yet?
char c;
while(count != 2) {
if((c = fgetc(file)) == '\n') count++;
}
fflush(file);
fprintf(file, "- . , M N B V C X Y Í Ű Á É L K J H G F D S A Ú Ő P O I U Z T R E W Q Ó Ü Ö 9 8 7 6 5 4 3 2 1 0\n");
fflush(file);
fclose(file);
Now it does nothing, the file stays the same. What could be the problem?
Thank you.
From here,
When a file is opened with a "+"
option, you may both read and write on
it. However, you may not perform an
output operation immediately after an
input operation; you must perform an
intervening "rewind" or "fseek".
Similarly, you may not perform an
input operation immediately after an
output operation; you must perform an
intervening "rewind" or "fseek".
So you've achieved that with fflush, but in order to write to the desired location you need to fseek back. This is how I implemented it - could be better I guess:
/* this finds the 3rd line */
int count = 0; //how much have we gone yet?
char c;
int position_in_file;
while(count != 2) {
if((c = fgetc(file)) == '\n') count++;
}
// Store the position
position_in_file = ftell(file);
// Reposition it
fseek(file,position_in_file,SEEK_SET); // Or fseek(file,ftell(file),SEEK_SET);
fprintf(file, "- . , M N B V C X Y Í Ű Á É L K J H G F D S A Ú Ő P O I U Z T R E W Q Ó Ü Ö 9 8 7 6 5 4 3 2 1 0\n");
fclose(file);
Also, as has been commented, you should check if your file has been opened successfully, i.e. before reading/writing to file, check:
file = fopen("irasproba_tesztfajl.txt", "r+");
if(file == NULL)
{
printf("Unable to open file!");
exit(1);
}

Resources