Is there a way to create a console application program that asks input data (eg users birth dates, favourite food, everything) and does anything i program it to do and keep those data stored in that .exe when i close it?
This way, when I'll open it again, all those datas will still be saved there, so I just have to update or modify them.
Don't save data inside your executable but outside of it
Is there a way to create a [...] program that asks input data [...] then keep those data stored in that .exe when i close it?
There is no simple way (but you don't need that). What you want is related to persistence and application checkpointing.
In practice, you probably want to store data in a file -not your executable- (perhaps using some textual format like JSON) or in some database (perhaps as simple as some sqlite, or interacting with some RDBMS like PostGreSQL). For things like birthdays and food preference, an sqlite database file is probably the good approach (see some SQLite tutorial). Put efforts in the good design of your database schema.
This way, when I'll open it again, all those datas will still be saved there
Those datas will still be there if you keep them in some outside file (perhaps a simple myappdata.sqlite one). You can easily design your program to create that file if it does not exist (this happens only the first time you run your program; on the next runs, your program would successfully read that data from that outside file at startup).
In most current operating systems (read this textbook to learn more about OSes) notably Windows, MacOSX, Linux, Android, ..., the executable is supposed to be read-only. And it might be running in several processes at the same time (in such case, what should happen? Think of ACID properties).
The usual practice is to store data outside of the executable (most programs, including your text processor, your compiler, your web browser, ... are doing that). You don't explain why you want to store some data inside the executable, and doing so is unusual and highly operating system specific and executable format specific (for Linux, study carefully elf(5)...)
I would suggest to save the data in some optional file (or database) - its filepath could have some wired-in constant default, etc.... At startup, you check the existence of that data (e.g. with access(2) on POSIX, or just by handling the failure case of fopen or sqlite3_open etc....). If it does not exist, you initialize your program data somehow. At exit (or save time), you write that data. BTW most programs are doing so.
Notice that on most operating systems and computers, a software is not simply a single executable file, but much more (e.g. required libraries and dependencies, configuration files, data files, build automation scripting such as Makefile, etc...). Its installation is a well identified technical process (sometimes a quite complex one), and package managers are helpful.
My feeling is that without specific motivation, you should not even try to store (mutable) data (persistently) in your executable (it is complex, brittle since very OS & compiler and build-chain specific, unusual, and opens vulnerabilities).
For completeness, some programs did actually write some data by rewriting their executable. On Linux, GNU emacs is doing that (in practice, only during its installation procedure) in its unexec.c file (very brittle, since OS & compiler specific) but that feature is disputed and is likely to disappear.
Many other systems deal cleverly with orthogonal persistence: SBCL has some save-lisp-and-die primitive (it usually persists the state in some other "image" file). Poly/ML has some export facility. J.Pitrat's CAIA system (see this paper and his blog; a 2016 tarball of CAIA is available -with permission- on my home page) is able to regenerate entirely all its C code and all the required data (in thousands of files). FullPliant is persisting its state in a well organized file tree. Such persistence or checkpointing techniques are tied to garbage collection (so you should then read the GC handbook) and are using techniques and algorithms close to copying garbage collection.
FWIW, my current project, bismon, is orthogonally persisting its entire heap, but do that outside of the main executable (in an ideal world, I would like to re-generate all the C or C++ source code of it; I am far from that goal).
My recommendation is to keep your software in several files: its executable, the C++ source code related to it, its data files (and probably much more dependencies, i.e. shared libraries or DLLs, font and image files, required binaries, etc...). Then you don't need to overwrite your executable when persisting your state. Since you mention C++ (which is not homoiconic), you could generate the C++ code of your system (then called a Quine program) with its persistent data (and leave the recompilation of all that generated C++ to the system's C++ compiler). I also recommend to make your self-generating program some free software. (if you do that, be nice to edit your question to gives its URL).
In C++, you might keep the data inside the executable (again, it is a bad idea, and I hope to have convinced you to avoid that approach) in the following way: You add one C or C++ source file (e.g. mydata.cc) which contains only data (e.g. some big const char data[]="... many lines of data ...";) - BTW, the XBM file format could be inspirational. You keep all the other *.o object files (in a place known to your program). To save data, you regenerate that mydata.cc file (with the new data for your current state) at each save operation, and at last you run the appropriate commands (perhaps using std::system in your code) to compile that mydata.cc and link it with the kept *.o into a fresh executable. So every save operation requires the recompilation of data.cc and its linking with other *.o object files (and of course the C++ compiler and linker, perhaps with additional build automation tools, becomes a required dependency of your program). Such an approach is not simpler than keeping an external data file (and requires to keep those *.o object files anyway).
This way, when I'll open it again, all those datas will still be saved there
If your goal is just to get the data if it was written in the past, just keep the data in some optional database or file (as many programs do: your word processor would ask you to save its document before exiting if you start it without any document and write a few words in it) outside of your executable and write it before exiting your program. No need to overwrite your executable!
What you want to do requires the ability to write into (and possibly read from) an executable while it is running. As far as I know this is not possible.
While it is possible to change the behaviour of a running executable based on the user input which it is pre-conditioned to receive (think of a video game), it is not possible to store those inputs directly into the exe.
Video games store the progress, points of the player (which are the result of the inputs from the player) into a file(s) outside the running .exe.
So you will have to store the data in a file outside of the .exe file.
I normally use google protocol buffers to do this.
A good explanation of them can be found here.
They are free, simple to use and supported for C++.
They are better than other formats like XML.
Some of the advantages are mentioned here
Protocol buffers have many advantages over XML for serializing structured data.
Protocol buffers:.
are simpler
are 3 to 10 times smaller
are 20 to 100 times faster
are less ambiguous
generate data access classes that are easier to use programmatically
managing birth dates
As I explain in my other answer (which you should read before this one), you don't want to save data inside your .exe file.
But I am guessing that you want to keep user birth date (and other data) from one run to the next. This answer focus mostly on that "users birth date" aspect and guesses that your question is some XY problem (you really care about birth dates, not about overwriting an executable).
So, you decide to keep them somewhere (but outside of your executable). That could be a textual file; perhaps using JSON or YAML format, or some other textual file format that you define properly, specified in EBNF notation in some document; or a binary file (perhaps protocol buffers as suggested by P.W, or some sqlite "database file", or your own binary format that you need to document properly). It is very important to document properly the file format you are using.
Dealing with a textual file (whose format you have well defined) is easy with just fopen. You first need to define well defined a file path, perhaps as simple as
#define MYAPP_DATA_PATH "mydata.txt"
or better
const char* myapp_data_path = "mydata.txt";
(in reality, you better use some absolute file path to be able to run your program from various working directories, and provide some way to redefine it, e.g. thru program options, i.e. command-line arguments)
You might also need to organize some data structure (a global variable MyData global_data; perhaps) keeping that data. In C++, you'll define some class MyData; and you want it to have at least member functions like void MyData::add_birth_date(const std::string& person, const std::chrono::time_point& birthdate); and void MyData::remove_birth_date(const std::string& person);. Probably you'll have more classes like class Person; etc...
using textual format
So your application starts first by filling global_data if a file mydata.txt exists (otherwise, your global_data keeps its empty initial state). That is simple, you'll have some initialization function like:
void initial_fill_global_data(void) {
std::ifstream input(myapp_data_path);
// the file opening could have failed.... then we return immediately
if (!input || !input.good() || input.fail())
return;
Of course, you need to parse that input. Use well known parsing techniques that would call global_data.add_birth_date appropriately. Notice that for the JSON format, you'll find good C++ libraries (such as jsoncpp) to make that really easy.
Before exiting your application, you should save that file. So you would call a save_global_data function wich outputs into the mydata.txt file the contents of MyData. BTW, you could even register it with std::atexit.
The functions initial_fill_global_data and save_global_data could be member functions (perhaps static ones) of your MyData class.
You might want your program to lock the data file. so that two processes running your program won't make havoc. This is operating system specific (e.g. flock(2) on Linux).
using an sqlite database file
I also suggested to keep your data in an sqlite database file. Read some sqlite tutorial and refer to sqlite C & C++ interface reference documentation. Then you need to think of a well designed database schema. And you don't need anymore to keep all the data in memory, since sqlite is capable of managing a big amount of data (many gigabytes), more that what fits in memory.
Obviously you need a global database pointer. So declare some global sqlite3*db;. Of course, myapp_data_path is now some "mydata.sqlite" path. Your main starts by opening that (and creating an empty database if necessary) using
int opsta = sqlite3_open(myapp_data_path, &db);
if (opsta != SQLITE_OK) {
std::cerr << "failed to open database " << myapp_data_path
<< " with error#" << opsta << "=" << sqlite_errstr(opsta)
<< std::endl;
exit (EXIT_FAILURE);
}
If the database did not exist, it is created empty. In that case, you need to define appropriate tables and indexes in it. My first suggestion could be something as simple as
char* errormsg = NULL;
int errcod = sqlite3_exec(db,
"CREATE TABLE IF NOT EXISTS data_table ("
" name STRING NOT NULL UNIQUE,"
" birthdate INT"
")",
&errormsg);
if (errcod != SQLITE_OK) {
std::cerr << "failed to create data_table " << errormsg << std::endl;
exit(EXIT_FAILURE);
}
Of course, you need to think of some more clever database schema (in reality you want several tables, some database normalization, and you should cleverly add indexes on your tables), and to prepare the queries (transform them into sqlite_stmt-s) done in your program.
Obviously you should not save data inside your executable. In all my approaches above, your myapp program behaves as you want it to be. The first time it is running, it initialize some data -outside of the myapp executable- on the disk if that data was missing. The next times, it reuses and updates that data. But that myapp executable is never rewritten when running.
Could somebody explain I/O to me? From everything I'm gathering, it can be summed up, abstractly, as the way computers interact with humans and vice versa. The I/O channel, or the "how", can run the gamut depending on external devices and/or internal OS management.
So what does the IO class in Ruby do? And how is it different from that of Java or C?
And take this code for instance:
x = IO.sysopen("file_name")
p x
The return is a Fixnum based on the file descriptor. In this case, the "file_name" is a pdf file and return a 7. What does the return object mean?
First of all, sysopen is a very low-level way of interacting with the system. For normal input and output in Ruby, you should use File.open instead.
The number returned by sysopen is called a "file descriptor". It's essentially an index into an array, but not a Ruby array; it lives inside the part of a process's memory which is maintained by the operating system. The first file descriptor, number 0, is called "standard input". Input calls will read from this input stream by default. The second, 1, is called "standard output"; output calls send their output there by default. And the third, 2, is called "standard error", which is where error messages go. All three of those are opened by the operating system before Ruby even starts. Normally they're all tied to the terminal, but you can change that with shell redirection.
As a general rule, when you open an extra file, the first one you open will get file descriptor 3, the next 4, and so on. So if you get a 7 back, that just means that Ruby has opened 4 other files by the time it gets to your code. And that's all it means. You can't tell anything else about an open file just based on the number. You have to hand that number off to a system call which can go look at the file descriptor array to see what's up.
But in Ruby, you usually have no reason to know or care about file descriptor numbers. You deal with instances of the IO class (and its subclasses like File for specific types of I/O). You call methods on the IO objects, and they handle the details of the system calls for you. The object referred to by the predefined constant STDIN (which is also the initial value of the global variable $stdin) knows that its file descriptor is 0, so you don't have to know that.
I want to copy an integer variable from user space to kernel space.
Can anyone give me a simple example how to do this?
I came to know that we can use get_user but i am unable to know how..
Check man pages of copy_to_user and copy_from_user.
Write a simple kernel module, with read/write operations, and register and char device for them, something like /dev/sample.
Do an application write/read, on fd opened by this application.
Now you need to implement the mechanism for transferring this data to kernel space and read back whatever returned.
- In write you do a copy_from_user, before this check passed buffer is valid or not.
- In read you do a copy_to_user.
Make sure error conditions are taken care of, and open call implementation should keep track of how many opens are there, if you want to implement multiple open, and this count should be decremented, when application calls a close on opened FD.
Do you follow ?
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'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