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
Related
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.
I want to make a tool similar to zerofree for linux. I want to do it by allocating a big file without zeroing it, look for nonzero blocks and rewrite them.
With admin privileges it is possible, uTorrent can do this: http://www.netcheif.com/Articles/uTorrent/html/AppendixA_02_12.html#diskio.no_zero , but it's closed source.
I am not sure this answers your question (need), but such a tool already exists. You might have a look at fsutil.exe Fsutil command line tool. This tool has a huge potential to discover the internal structures of NTFS files and can also create file of any size (without the need to zeroing it manually). Hope that helps.
Wrote a tool https://github.com/basinilya/winzerofree . It uses SetFileValidData() as #RaymondChen suggested
You should try SetFilePointerEx
Note that it is not an error to set the file pointer to a position
beyond the end of the file.
So after you create file, call SetFilePointerEx and then SetEndOfFile or WriteFile or WriteFileEx and close the file, size should be increased.
EDIT
Raymonds suggested SetValidData is also good solution, but this requares privileges, so shouldn't be used often by anyone.
My solution is the best on NTFS, because it supports feature known as initialized size it means that after using SetFilePointerEx data won't be initialized to zeros, but after attempt to read uninitialized data you will receive zeros.
To sum up, if NTFS use SetFilePointerEx, if FAT (not very likely) - use SetValidData
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()
Say I have app TestApp.exe
While TestApp.exe is running I want a separate program to be able to read the executable code that is resident in memory. I'd like to ignore stack and heap and anything else that is tangential.
Put another way, I guess I'm asking how to determine where the memory-side equivalent of the .exe binary data on disk resides. I realize it's not a 1:1 stuffing into memory.
Edit: I think what I'm asking for is shown as Image in the following screenshot of vmmap.exe
Edit: I am able to get from memory all memory that is tagged with any protect flag of Execute* (PAGE_EXECUTE, etc) using VirtualQueryEx and ReadProcessMemory. There are a couple issues with that. First, I'm grabbing about 2 megabytes of data for notepad.exe which is a 189 kilobyte file on disk. Everything I'm grabbing has a protect flag of PAGE_EXECUTE. Second, If I run it on a different Win7 64bit machine I get the same data, only split in half and in a different order. I could use some expert guidance. :)
Edit: Also, not sure why I'm at -1 for this question. If I need to clear anything up please let me know.
Inject a DLL to the target process and call GetModuleHandle with the name of the executable. That will point to its PE header that has been loaded in the memory. Once you have this information, you can parse the PE header manually and find where .text section is located relative to the base address of the image in the memory.
no need to inject a dll
use native api hooking apis
I learned a ton doing this project. I ended up parsing the PE header and using that information to route me all over. In the end I accomplished what I set out to and I am more knowledgeable as a result.
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).