I am trying to insert the new code caves inside windows malware PE files by expanding the size of existing sections. I was able to dig out the existing code caves in the file but expanding the size of existing sections to insert code caves (just the empty space) is confusing me a lot as it can easily break the file. Can someone help me with the details I should be looking at to insert those empty spaces which are not initially present inside the file?
Related
I have a file that can be opened thru notepad application.
Basically, this file(which can be opened thru notepad) is created by a software and that software uses the values inside that file to run. You can edit the values inside the file using its software.
I just want specific lines(values) to be restricted from being edited because I am implementing strict values inside that file that no one will be able to edit except me.
Is there any clever way to restrict specific lines inside that file from being edited?
I tried the basic way - I used the change permission read/write on that file but I can't change ANY values inside the file which is undesirable.
Note: I have very little to no experience about python, c++, or java but any suggestion will give me idea to learn from it.
Edit:
Here's an example inside the file:
[Type Data]
Comment=Standard Dispense
[Shared_A]
802=1
807=750
11=0
12=0
.
What I want is restrict the value from row/column "807" which is equal to number 750.
I want this number 750 not to be edited even from the software so that other people will not mess it up. I want to set this value as standard value.
Is there any program that you can write inside that file so that it cannot be edited from the software unless I open that file and edit it?
I work from a production/manufacturing company that uses the software that is used for dispensing.
A text file is simply a sequence of bytes that represent code units to encode code points in any given character set. Every byte value is a potentially legal character encoding, leaving no values to encode additional semantics (like guard regions).
With that it should be obvious that there is nothing you can do to partially limit editing of a file using a standard text editor. Whatever problem you are trying to solve, this is not a solution. Next time around you might want to ask about the problem you are trying to solve rather than your proposed solution.
I am rebuilding a site with docpad and it's very liberating to form a folders structure that makes sense with my workflow of content-creation, but I'm running into a problem with docpad's hard-division of content-to-be-rendered vs 'static'-content.
Docpad recommends that you put things like images in /files instead of /documents, and the documentation makes it sound as if otherwise there will be some processing overhead incurred.
First, I'd like an explanation if anyone has it of why a file with a
single extension (therefore no rendering) and no YAML front-matter,
such as a .jpg, would impact site-regeneration time when placed
within /documents.
Second, the real issue: is there a way, if it does indeed create a
performance hit, to mitigate it? For example, to specify an 'ignore'
list with regex, etc...
My use case
I would like to do this for posts and their associated images to make authoring a post more natural. I can easily see the images I have to work with and all the related files are in one place.
I also am doing this for an artwork I am displaying. In this case it's an even stronger use case, as the only data in my html.eco file is yaml front matter of various meta data, my layout automatically generates the gallery from all the attached images located in a folder of the same-name as the post. I can match the relative output path folder in my /files directory but it's error prone, because you're in one folder (src/files/artworks/) when creating the folder of images and another (src/documents/artworks/) when creating the html file -- typos are far more likely (as you can't ever see the folder and the html file side by side)...
Even without justifying a use case I can't see why docpad should be putting forth such a hard division. A performance consideration should not be passed on to the end user like that if it can be avoided in any way; since with docpad I am likely to be managing my blog through the file system I ought to have full control over that structure and certainly don't want my content divided up based on some framework limitation or performance concern instead of based on logical content divisions.
I think the key is the line about "metadata".Even though a file does NOT have a double extension, it can still have metadata at the top of the file which needs to be scanned and read. The double extension really just tells docpad to convert the file from one format and output it as another. If I create a straight html file in the document folder I can still include the metadata header in the form:
---
tags: ['tag1','tag2','tag3']
title: 'Some title'
---
When the file is copied to the out directory, this metadata will be removed. If I do the same thing to a html file in the files directory, the file will be copied to the out directory with the metadata header intact. So, the answer to your question is that even though your file has a single extension and is not "rendered" as such, it still needs to be opened and processed.
The point you make, however, is a good one. Keeping images and documents together. I can see a good argument for excluding certain file extensions (like image files) from being processed. Or perhaps, only including certain file extensions.
I'm using PowerBuilder 10.5 and as a newbie I'm a bit stuck and since Google isn't giving me a satisfying answer I'm asking some advice from the Stack Overflow group.
I have a Rich Text Edit field in which the user can write something, insert pictures and so forth. Once finished, he goes to the „Search“ command button and clicking it searches for the batch file that will suit his needs (copy that text into an existing word document, create a new word and place the folder on web, and so fort – there are 6 different batches). The code in the clicked event of „Search“ command button is this:
String ls_s
GetFileOpenName('PB_app', ls_s, ls_s, 'BAT', "Win Batch Files (*.BAT),*.BAT", 'C:\Programs\Test')
And here come my problems: I can't connect my app and the selected batch file. I'd like the path of the selected batch file to be visible in the Single Line Edit filed, but I have no idea how to get there, not to mention I'm point blank at how to connect PB app, batch file, how to even say to the batch file – „That text in rich text edit field is the one you have to work with?“…?
So I need some advice, guidance, perhaps some links or names of any literature that would help me understand how it should be done. I've lost two days and got nowhere, and I just need some piece of advice to get me going…
Your problem is that the original programmer used one variable for two return values. If you declare a new string variable and pass it instead of the first ls_s, you'll see this will return you the path. If you run into trouble, PB has a good help file (and the manuals are also online) which covers GetFileOpenName().
Good luck,
Terry
When looking at PE files in a hex editor, I often encountered some bytes between the section table and the first section, which doesn't really make sense to me. As far as I am concerned, there should be a 00-byte padding in order to fit the alignment. However, here is a screenshot which demonstrates the opposite:
As it turned out the highlighted block is pretty much the Bound Import Table. But I am still confused. Why is this table not located in a section? Is this always the case or is it just the specification of a certain compiler/linker? I did not find any documentation on this specific issue. Everything one can find on this topic basically says:
DOS MZ Header
DOS Stub
PE Header
Section Table
Section 1
Section 2
Section 3
... and so on
Before I encountered this issue I was not even aware of the fact, that there can be things outside of the sections (besides the ones i listed above, of course).
[EDIT]
Proof of concept (Since Mox did not believe me):
Data directories such as the IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT can exist outside of sections. Another example of a data directory existing outside of any known section would be the IMAGE_DIRECTORY_ENTRY_CERTIFICATE data directory which is the data directory used to store the certificate information when an executable is signed.
Data directories can point to data outside of a section, with-in a section, or they can point to the entire section. The IMAGE_DIRECTORY_ENTRY_RESOURCE data directory points to the entire ".rsrc" section. Certain data directories point to known sections and these are documented in the PE format specification by Microsoft.
Items like the bound import table can be written wherever the linker wants to put them in the raw image. It just overwrites the zero bytes with the table and makes the pointer correct in the data directory. You could probably even overwrite the middle of the DOS header or stub with the import table and it would work as long as the pointer in the directory was correct.
As far as I can see with LordPe, the IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT entry of iexplore.exe is empty.
both 32bit and 64bit versions of IEXPLORE.EXE don't have IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT entries.
Here a snaphot of LordPE, showing the 64bit version of IEXPLORE.EXE on a Windows 7 machine and (in green) the missing IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT entry:
It looks like you don't look at the right directory entry.
We're creating an app that is going to generate some text files on *nix systems with hashed filenames to avoid too-long filenames.
However, it would be nice to tag the files with some metadata that gives a better clue as to what their content is.
Hence my question. Does anyone have any experience with creating files with custom metadata in Ruby?
I've done some searching and there seem to be some (very old) gems that read metadata:
https://github.com/kig/metadata
http://oai.rubyforge.org/
I also found: system file, read write o create custom metadata or attributes extended which seems to suggest that what I need may be at the system level, but dropping down there feels dirty and scary.
Anyone know of libraries that could achieve this? How would one create custom metadata for files generated by Ruby?
A very old but interesting question with no answers!
In order for a file to contain metadata, it has to have a format that has some way (implicitly or explicitly) to describe where and how the metadata is stored.
This can be done by the format, such as having a header that says where the "main" data is stored and where the "metadata" is stored, or perhaps implicitly, such as having a length to the "main" data, and storing metadata as anything beyond the "main" data.
This can also be done by the OS/filesystem by storing information along with the files, such as permission info, modtime, user, and more comprehensive file information like "icon" as you would find with iOS/Windows.
(Note that I am using "quotes" around "main" and "metadata" because the reality is that it's all data, and needs to be stored in some way that tools can retrieve it)
A true text file does not contain any headers or any such file format, and is essentially just a continuous block of characters (disregarding how the OS may store it). This also means that it can be generally opened by any text editor, which will merely read and display all the characters it finds.
So the answer in some sense is that you can't, at least not on a true text file that is truly portable to multiple OS.
A few thoughts on how to get around this:
Use binary at the end of the text file with hope/requirements that their text editor will ignore non-ascii.
Store it in the OS metadata for the file and make it OS specific (such as storing it in the "comments" section that an OS may have for a file.
Store it in a separate file that goes "along with" the file (i.e., file.txt and file.meta) and hope that they keep the files together.
Store it in a separate file and zip the text and the meta file together and have your tool be zip aware.
Come up with a new file format that is not just text but has a text section (though then it can no longer be edited with a text editor).
Store the metadata at the end of the text file in a text format with perhaps comments or some indicator to leave the metadata alone. This is similar to the technique that the vi/vim text editor uses to embed vim commands into a file, it just puts them as comments at the beginning or end of the file.
I'm not sure there are many other ways to accomplish what you want, but perhaps one of those will work.