I'm looking around /proc and I'm wondering why /proc/[PID]/exe can be broken.
I mean , /proc is a pseudo-filesystem and the principle behind it is
/proc provides infos about running processes and kernel data structures
and many other file in that folder has a similar one (principle).
So , the principle behind /proc/[PID]/exe should be
/proc/[PID]/exe provides executable's absolute path
but broken links break this rule; so , what's the true principle behind this "symlink" ? What's the practical usage "behind the scenes" , that is in kernel internals ?
Or maybe this is a nigthmare of mine , and /proc is just "for users" , meaning that kernel doesn't really use these infos (and so they can be imperfect) ?
Related
Context:
I'm on Linux. I am writing a disk usage extension for Sensu. Extensions must be non-blocking, because they are included in the agent's main code loop. They also must be very lightweight, because they may be triggered as often as once every 10 seconds, or even down to once per second.
So I cannot spawn a new executable to gather disk usage information. From within Ruby, I can only do stuff like File.open() on /proc and /sys and so on, read the content, parse it, file.close(), then print the result. Repeat.
I've found the sys-filesystem gem, which appears to have everything I need. But I'd rather not force extensions to depend on gems, if it can be avoided. I'll use the gem if it turns out to be the best way, but is there a good alternative? Something that doesn't require a ton of coding?
The information can be accessed via the system call statfs
http://man7.org/linux/man-pages/man2/statfs.2.html
I can see there is a ruby interface to this here:
http://ruby-doc.org/core-trunk/File/Statfs.html
I am a beginner to kernel module programming. And using resources online (especially this tutorial) I have managed to write most of my driver.
The driver basically is a character device which maps different areas of SRAM into separate files. You can see the actual code here.
Right now I am able to successfully create 4 files under /dev and reading/writing the first file works too but the other 3 files do not work. I am using minor number to distinguish between the files and assign the starting address accordingly.
Questions:
Why are the other files not working?
Is there a better way to implement the module?
Thanks.
Line 141,
"if (cdev_add(&c_dev, first, 1) == -1)",
only applies the file_operations struct to the first device.
You should use MAXDEVICES instead of 1 here
On another note, the init code is messy (better use goto and not duplicate the cleanup for every function that can fail) and in some cases plain wrong (device_destroy() before any devices were created, resource leak in case you fail the create a device that isn't the first).
The entire file does not stand up to kernel coding conventions.
For linux and windows, in the same process, how to make two page entries reference to the same physical page?
For windows, by reading at the MSDN, looks like I can call CreateFileMapping by passing INVALID_HANDLE_VALUE to create a file mapping without backed by a file. Then I can call MapViewOfFileEx twice with different lpBaseAddress, which essentially makes two different addresses reference to the same physical address.
My question is, how to do it under linux? I read manual for mmap, and didn't see a way to do it, unless the region is backed by a file (with flag MAP_SHARED) but modifications to this region will be written to the file, which is not what I want. Does anyone aware of someway to do this? I am not against backing by a file, as long as the writing to the region doesn't actually goes to the disk. Using tmpfs is not an option because I can't guarantee user has a tmpfs mounted.
By the way, the code should be user mode code, not kernel mode.
Use shm_open() to create a file for mmap().
"I want to write some emulator" is the same purpose as mine when I used this trick.
I did use ipc/shm, but I forgot the detail. It was very very very very probably: shmget()+shmat()
I have to find a button's name in a running process memory in Mac OSX and change it.
Supposing there is a "Test" application where it has a "Hello" button, is there any way to attach to "Test" application and change the "Hello!" button to "Bye!"?
I assume this could be done either using GDB or Xcode. If not, how can I do this?
Edit
Assuming you are really looking for dynamic data (as opposed to what your sample seemed to suggest :)) you could always just work with the debugger commands. This will require you to have a sense of the possible memory range to scan (or you'll simply get useless memory violations):
Use gdb commands, loop constructs and libc functions
# assume 0x1234 is a likely base address, say for the heap
(gdb) set $x=0x1234
(gdb) set $y = strdup("lookforthistext")
(gdb) while(0!=memcmp($x++, $y, 15) && $x<0x4321)
>end
(gdb) p $x
(gdb) x $x
This example scans the region 0x1234...0x4321 for the first match and prints/examines the output address.
You can use similar tricks (strncpy...?) to overwrite the memory if you had access to it.
Of course the program may fail dramatically if you do things like changing the length of a substring.. YMMV).
Consider saving your concocted commands as a script (turn on logging, use .gdbinit or even create gdb functions; sadly I know little about the latter)
Original answer:
You "need to"? I doubt it. Your best bet is to work with the windowing/UI API's of your operating system to retrieve the actual window that display the text and make it display another text (usually by sending it appropriate control messages). You'll need plenty of COW powers (think: root) to pull that off.
To answer the direct question:
Usually, messages like this are constants (static data) and as such are either
present in the data segment
read (memory mapped pages) from resources
Both of which are usually (these days at least) in read-only memory segments (think of sharing of memory mapped pages; this gives the kernel opportunity to share mapped regions of shared binary objects between processes - also it serves the obvious security purposes).
On the upside,
strings myprogram | grep 'Hello"
will tell you whether you can use sed, a hex editor or any other suitable editor to manipulate the binary even before it starts. There are two drawbacks I can think of here:
it is not dynamic (you can't have the text change on the fly)
it may break code signing (meaning the executable might get rejected by the OS because it has been modified).
I'm using the GoAsm assembler on a Windows 7 - 64 bit OS and I'll be asking you a few (not so dumb) questions.
First question :
How can I find the physical address of a file ?
Let's suppose file "Text.txt" is at the root of my C:\ partition.
Is there a way to get the exact memory address where this file is ?
Second question :
Is it possible to call a routine which will just do like if I invoked a C function ?
(i.e. : Consider a C function "WriteToScreen", is it possible to have the same function, but in assembler format, that means without having the need to use high-level invokes to do that work ?
Third question :
Are there somewhere on the net some include files for GoAsm containing useful routines like (move, copy, edit, erase) commands ? I've first thought of ms-dos interrupts but I can't manage to get them to work without crashing the program. I guess it just not compatible with Windows OS even though the command prompt acts like ms-dos... ?
Fourth question :
I've heard from different sources and myself that NASM works pretty bad on Win7 x64, is it just true, or am I doing it the wrong way ?
1
An hard drive, from a logical point of view, can be seen as a sequence of "blocks" (the more common name is sectors). How these blocks are organized physically on the disks can be disregarded, but the driver must know someway how to get data of course, though you send to modern hd driver "high level" commands that, as far as you know, are not strongly related to where data physically are (you can say "read the block 123", but there's no extern evidence of where that block lives).
However this way you can "name" a block with a number, and say e.g. that block 0 is the MBR. Each block contains several bytes (512, 1024...). Not all used blocks contain actual data of a file, in fact there are metainformations of any sort, depending on the filesystem but even related to the "structure" of the hd (I mean, partitions).
A file located on an hd is not automatically loaded into memory, so it has no memory address. Once you read it, piece of it if not all are of course copied into the memory you give, which is not an intrinsic property of the file. (Filesystems retrieve the blocks belonging to the file and "show" them as we are used to see them, as a single "unit", the file)
Summarizing: files have no memory address. The physical address could be the set of blocks holding data (and metadata, like inodes ) of the file, or just the first block (but if a block of data is N, N+1 could not belong to the same file - the blocks need no to be one next to the other). To know them, you have to analyse the structure of the filesystem you use. I don't know if there's an API to retrieve them easily, but in the worst case you can analyse the source code of the filesystem... good luck!
2
C functions are translated into assembly. If you respect the C calling convention, you can write a "C function" directly in assembly. Try reading this and this for x86.
3
You can call windows API from asm. Forget MS-DOS, MS-DOS is dead, MS-DOS is not Windows, the cmd is a sort of "emulation"... indeed no, not an emulation but just a command line interface that resemble the one MS-DOS users was used to. But it is not exaclty the same, i.e. there are no MS-DOS system interrupt you can use. Iczelion's assembly tutorials, though old, could be an interesting resource. (If links expire, try with the wayback machine)
4
I do not own Win7 and never installed nasm on windows, so I can't say anything about.
For the first question just drag the file into the address bar in the browser