I have found several examples online where we can create a proc file, assign read and write methods that are called every time the proc file is opened for read or written to.
However, I can't seem to find any documentation on how to programatically write to a proc file. Ideally, I would like to add a timestamp with other user details every time the proc file is opened for read or for write. Again, I've found where I can add the read and write functions that are triggered when the proc file is opened, but I can't find documentation on how to actually write to a proc file programatically. This would be different from a regular IO read/write, correct?
Fixed the issue -- I didn't fully understand proc files but now understand how they work and that there isn't really any file to write to -- just variables. Got it working. Thanks!
Related
I tried to write a program that open itself, reads itself and looks for a certain address or bytes to substitute with an other value.
My objective is to make a program that understands if it's the first time that it's running or not by modifying some bytes the first time it runs (and I don't really like to create a file outside of my program)
The executable can read itself but when it tryes to self-overwrite it throws an error (file used by an other process... As expected)
Is there a way for the program to overwrite itself? If not maybe I can modify just a part of the program that contains just data?
Is there an other simple solution I am not aware of?
(I'm using both Linux and windows as OS.)
From what I understand, your objective is to find out if the program has been run previously or not. Instead of going with the idea you presented why not create a file, could be any file, check upon running if the file is there or not. If it's there then it has been run before else not.
A workaround can be (because it doesn't overwrite itself, it just creates an other file):
copy all content of the original executable
modify what I need
rename di original executable to a fixed name "old version"
write the modified bytes to "original name" (the modified executable)
launch the new executable just created
either have the original executable self delete or delete it from the modified executable just created
I think this gets the job done even if not on the cleanest way (the program has to start from beginning but i guess this is unavoidable)...
If someone still know a better way you are more the welcome to write your idea.
Dir-s seem awkward as compared to File-s. Many of the methods are similar to IO methods, but a Dir doesn't inherit from IO. For example, tell in the IO docs reads:
Returns the current offset (in bytes) of ios.
When read-ing and tell-ing through a normal Dir, I get large numbers like 346723732 and 422823816. I was originally expecting these integers to be more "array-like" and just be a simple range.
Are these the bytes of the files contained in the Dir?
If not, is there any meaning to the numbers returned like IO#tell?
Also why do Dir-s have an open and close function if they are not Streams?
Is it still just as important to close a Dir as a normal IO?
Any general explanation of how a Ruby Dir works would be appreciated.
update Another confusing part: if Dirs are not IOs, why does close raise an IOerror?
Closes the directory stream. Any further attempts to access dir will raise an IOError.
Also notice that in the documentation it considers it a "directory stream". So this brings up the question again of are they streams or not and if not, why the naming convention?
The docs for Dir#tell say:
Returns the current position in dir.
without specifying what the position means. What the returned value signifying is likely to vary based on the OS that you're using and possibly the type of the file system that contains the directory. That value should be treated as opaque, don't try to interpret it in any way. The only purpose it serves is for being able to send that value back to the OS such as by calling Dir#seek.
Directories are not just a giant file. More typically they just map from a file name to information about where the data for the file is contained.
You should not (and as far as I'm aware cannot) write to directories yourself.
So after some IRC chat here's the conclusion I've come to:
The Dir object is NOT an IO
Dir Does not inherit from the IO class and is only readable. Still not sure why an IOError is raised on #close.
An opened Dir IS a stream however
Objects of class Dir are directory streams representing directories in the underlying file system.
Also if you check the source for Dir#close You will see that it calls the C function dirclose. man dirclose prints:
The closedir() function closes the directory stream associated with
dirp. A successful call to closedir() also closes the underlying file
descriptor associated with dirp. The directory stream descriptor dirp
is not available after this call.
...with dirp being a param.
So yes, instantiated Dirs will open a stream and yes, Dirs will use a file descriptor and need to be closed if you do not want to rely on garbage collection.
Big thanks to injekt and others on #ruby-lang irc!
I am playing around with the demo of IDA and I am trying to do some reverse engineering of a program to figure out the structure of one of its files that it uses. My final goal is to be able to read that file directly from my own program.
Using Process Monitor I was able to find the subroutine that calls kernel32_ReadFile. What I would like to know is how do I find out what the hFile variable is pointing to before it makes the call to ReadFile
I have been exploring around the menus while in debug mode and I have not found anywhere inside IDA where I can look up information about what file is associated with a file handle.
How do I map a handle to a real file?
This MSDN page describes ways to get the file name from a file handle:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366789(v=vs.85).aspx
Is that the information you were looking for? I'm not sure why you can't see the the file name directly in Process Monitor.
I would set a breakpoint on CreateFileA and CreateFileW and see what files are being opened. You can then match the returned HANDLE value to the subsequent ReadFile call.
I am trying to write to a single file from multiple threads. The problem I'm running into is that I don't see anything being written to the file until the program exits.
You need to file.flush to write it out. You can also set file.sync = true to have it flush automatically.
What is the value of the sync method on your io object? It is possible that either ruby or the underlying o/s are buffering the file output.
Check out the refences on buffering and syncing within the documentation
I need to write a kernel module that simulate a "multicaster" Using the /proc file system.
Basically it need to support the following scenarios:
1) allow one write access to the /proc file and many read accesses to the /proc file.
2) The module should have a buffer of the contents last successful write.
Each write should be matched by a read from all reader.
Consider scenario 2, a writer wrote something and there are two readers (A and B), A read the content of the buffer, and then A tried to read again, in this case it should go into a wait_queue and wait for the next message, it should not get the same buffer again.
I need to keep a map of all the pid's that already read the current buffer, and in case they try to read again and the buffer was not changed, they should be blocked until there is a new buffer. I'm trying to figure it there is a way i can save that info without a map.
I heard there are some redundant fields inside the I/O system the I can use to flag a process if it already read the current buffer.
Can someone give me a tip where should i look for that field ? how can i save info on the current process without keeping a "map" of pid's and buffers ?
Thanks!
Don't try and keep it based on the PID - that's simply the wrong level of abstraction.
Each time the file is opened there will be a new struct file created that references that instance of the open file. Store the information (the most recent buffer that was read by a given struct file) within the struct file itself.
You can use the private_data pointer within struct file to store the information you need. That's what it's there for.