As a part of assignment I have to write a YARA rule that identifies binaries compiled in the last 24 hours. For this, I need to write a condition in YARA rule where it compares the compile time of binary with the current system time to check whether it's compiled in last 24 hours or not.
How can I get the current system time within YARA ?
Related
BTRFS files/directories contains the timestamps:
Creation (otime)
Modification (mtime)
Attribute modification (ctime)
Access (atime)
Is there some API where I could set these all these timestamps for a file? I googled a bit but haven't found anything yet.
Programming languages doesn't matter, I would expect there to be some C API, but python is fine too and would be nicer.
From C, the mtime and atime can be set using utime(2) and its relatives. utime(2) itself gives you seconds precision, utimes(2) has microseconds, and utimensat(2) gives you nanoseconds. There are variants like futime if you have a file handle instead of a file name.
Python can provide the same via the os.utime function.
Traditionally it is not possible to arbitrarily modify the otime or ctime, other than by manually editing the raw filesystem. I am not aware that Linux has provided any kernel API to modify them. Of course, you can update the ctime to the current time by changing its status in some way, and you can update the otime to the current time by deleting and recreating the file. In principle you can set them to a different time by changing the system clock first (if you are root), but this is likely to mess up lots of other stuff on the system and is probably a bad idea.
I am working with detecting Daylight saving time (summer time) transitions.
I have come across something that I don't understand, and was hoping for some explanation.
I have stripped down my code to a nearly bare minimum to show the problem.
int main(void)
{
struct tm tm1,tm2;
time_t time1, time2;
int order=0;//change this betwee 0 and 1
tm1.tm_hour=2;
if (order)
{
tm1.tm_hour=1;
}
tm1.tm_min=0;
tm1.tm_sec=0;
tm1.tm_mday=1;
tm1.tm_mon=10;
tm1.tm_year=115;
tm1.tm_isdst=-1;
time1=mktime(&tm1);
//insert here
tm2.tm_hour=1;
if (order)
{
tm2.tm_hour=2;
}
tm2.tm_min=0;
tm2.tm_sec=0;
tm2.tm_mday=1;
tm2.tm_mon=10;
tm2.tm_year=115;
tm2.tm_isdst=-1;
time2=mktime(&tm2);
printf("\n\n time stamp 1=%zu time stamp 2=%zu difference=%zi\n\n",time1 ,time2, time2-time1);
exit(0);
}
The output when order = 0 is:
time stamp 1=1446368400 time stamp 2=1446364800 difference=-3600
The output when order = 1 is:
time stamp 1=1446361200 time stamp 2=1446368400 difference=7200
(note that this is intentionally the time of the end of daylight saving time, one second after 01:59:59 on November 1st of 2015, it will be 01:00:00.)
To put it simply, the conversion of the structure when hour = 2 depends on the conversion that occurred immediately before it. One o'clock can (correctly) be either 1446364800 (standard time) or 1446361200 (DST). if the conversion before is found to DST, the second choice is used and vice versa. The obvious solution is that mktime sets some variable, that it uses the next time. However I can't find any record of it. mktime does set three (four?) external variables, tzname[0],tzname[1], timezone and daylight, but these don't seem to be causing the effect. (I did a more complicated version of my test program to test for that.)
My time zone is America/Edmonton ( MST(UTC-7)/MDT(UTC -6) )
$ gcc --version<br>
gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
Kubuntu 14.04 LTS
Any insight or pointers would be much appreciated.
Edit:
replys to comments:
1) Jonathan -- glibc version 2.19
2) chux -- printing the values of tmX.tm_isdst, tmX.tm_hour after the mktime() doesn't provide me any insight. (is that because I'm blind?) The one O'clock conversion shows an hour of one and a is_dst of either 0 or 1, exactly as infered by the timestamp. The two O'clock conversion, of course, shows an hour of 2 and an is_dst of 0.
reply to chux's(?) answer: I wonder If I have not fully explained myself.
I realize what is going on: There is an ambiguity, and it has to "guess". What I am wondering is why (and how) can it's guess depend on the previous conversion?
second edit:
to confirm Wumpus Q. Wumbley's answer inserted the following code in the place indicated in the code above:
tm0.tm_hour=0;
tm0.tm_min=0;
tm0.tm_sec=0;
tm0.tm_mday=1;
tm0.tm_mon=10;
tm0.tm_year=115;
tm0.tm_isdst=-1;
time0=mktime(&tm0);
(Basically a throw away conversion) I now get two hours difference regardless of order, so I get the DST version either way.
Thanks for the explanation.
In the current glibc source code, at time/mktime.c line 410 there is a relevant comment:
/* Invert CONVERT by probing. First assume the same offset as last
time. */
It intentionally uses the same offset in consecutive calls when possible. There is no global variable you can set to change this, or inspect to detect it. It's kept in the static time_t localtime_offset; at line 578.
The issue comes down to the value of tmX.tm_isdst before/after the mktime() call.
"A negative value causes it to attempt to determine whether Daylight Saving Time is in effect for the specified time." C11dr ยง7.27.2.3 2 footnote
I added printf("H:%d DST:%d\n", tm1 (or 2).tm_hour, tm1.tm_isdst); after each:
// order 0
H:2 DST:0
H:1 DST:1
time stamp 1=1446364800 time stamp 2=1446357600 difference=-7200
// order 1
H:1 DST:1
H:2 DST:0
time stamp 1=1446357600 time stamp 2=1446364800 difference=7200
The values are correct for the assumption made by the system concerning the underspecified "Y-M-D H:M:S dst=unknown" time-stamp which could go either way.
Since C does not specified what should be used during this transition hour, either assuming dst is true/false is reasonable and not necessarily consistent across various platforms. A given system, for example, could use the previous isdst setting, always 0 or flip a coin. It simply is not specified.
Note: This is an example of why some laws say "bars must close 2 hours after midnight rather than 2:00 A.M. in areas where DST transitions occurs in the 2:00/3:00 A.M. hour. 2 hours after midnight occurs only once - everyday. 2:00 A.M. occurs twice on that special transition night once a year.
I need to create a list of files which are located on my hard disk in order of when they arrived on the hard disk. To do so, I have used the following:
ls -lat
which lists all the files in date/time order, however, it only orders them to the nearest second. The problem here is that there are thousands of files and every so often, a few of them come clumped together in the same second. I need the exact correct ordering. I'm guessing the easiest way to do this is to get the creation time to the milli (or perhaps nano) second. To do this, I have tried using the following:
stat $myfile
to look at the modification time, but it always shows hour:minute:second.00000000000.
Is there a way to do this?
Thanks,
Rik
The accuracy depends on the file system you are using, but even with a high accuracy file system such as ext4, the standard implementation of stat uses time_t which has a 1 second resolution.
If you have access to the source of the program spitting out all those files, try setting a timestamp as part of the filename instead and then sort on the filename rather than the modification time.
you'll probably have to write your own stat command, using the stat(2) function
I'm not sure this is possible. My reasoning:
If you look at the stat() function call, you see that it returns a struct containing information about a file. One of its members is this:
time_t st_mtime; /* time of last modification */
And if you look at the time_t structure, well, wikipedia says this:
Unix and POSIX-compliant systems
implement time_t as an integer or
real-floating type (typically a
32- or 64-bit integer) which
represents the number of seconds since
the start of the Unix epoch...
Which means that stat()'s time is in terms of seconds, not milliseconds. I haven't looked at how each inode stores file information, but it might not store info up to the millisecond.
An alternative might be to append the mill/microsecond value to the filename itself when they are being created and order them that way?
I want to make a procedure that does one way syncrhonization of a folder between a server and a client. I was thinking to use ModifiedDate as a criterio, provided that only the date of the server files will be used. Procedure will not use Modified dates of files on the client at all. It will read dates from the server and compare them with dates read from the server last time the procedure run.
Do you think this is safe?
Is there any possibility that Modified Date will not be changed when a file is edited or it will be changed without touching the contents of the file (eg. from some strange antivirus programs)?
Don't count on the modification date of a file.
Strange programs (antiviruses and such) are not the problem more than the fact that you simply can't count on the client and server clocks to be synchronized.
Why not do a straightforward diff or hash calculation? You can't get a better comparison than that.
Taking performance considerations into effect, you can use the following heuristic:
If date hasn't changed then file is obviously the same
If date has changed, file contents might have changed, and might have not (for example: it has been touched). In this case in order to get a definitive answer you must examine the file somehow.
Bottom line: modification date can always give you a true negative (file not changed), but might sometimes yield a false positive - and this case you must verify.
You didn't mention what OS you're on, but on UNIX platforms the modification time can be set by client code to any value it wants (see the utimes() API or touch command). Therefore you shouldn't rely on modification times to tell you whether a file has changed or not. I imagine Windows is somewhat similar.
How to protect c++ output file(pe file) from editing using crc(Cyclic Redundancy Check)?
**Best Regards**
You can use CRC's to effectively check to see if a file was accidentally altered, but they are not effective for copy protection, or preventing cheats on a game.
Usually, when I program has some sort of CRC check, I find the code which does the check, and change the assembly instruction from a conditional branch to an unconditional branch. This is usually quite easy to find, because normally after a CRC fail, the program displays a message and exits. I place a break point when the message occurs, and examine all the frames in the stack. I then put break points on each point in the stack, run the program again, and see which one does the CRC check.
This isn't particularly difficult, and people often bundle little programs which will apply the same changes to the software of your choice.
You need a static variable in your code. The variable needs to be initialized to a value that can easily found with an hex editor (e.g. DEADBEEF)
you need a crc-algorithm (try searching google)
The tricky part. You need to get pointer in memory to the start and to the end of your exe. You can parse the pe file header for the code location and run the crc-algorithm from start of code to end of code. Then you have the value.
Of course you have to check the calculated value with the one in the static variable.
Inserting the value - depending on how often you build, you might want to programm a tool. You can always run your program and set a breakpoint on the comparison. Then you note down the value and hex-edit it into the executable. Or you create a standalone program that parses the pe-header as well, uses the same function (this time on the file) and patches it in. This could be complicated though, because I don't know what is changed by the OS during loading.