In a PE/COFF format file (for example, a Windows executable) in the section headers there is a field called Characteristics which has a bit mask value of IMAGE_SCN_MEM_SHARED (0x10000000) which is described by the spec as "The section can be shared in memory." What does this mean? Shared with what?
Also, as long as we are on this topic, what is the difference between the IMAGE_SCN_MEM_EXECUTE setting and the IMAGE_SCN_CNT_CODE setting?
Do the read / write settings result in flags being set on the memory to make readable/writable?
That means this section memory can be shared with another process instance of the same image.
Related
I am reading this docs to study wasm binary format. I am finding it very tough to understand the composition of element section. Can someone please give me an example / explanation about it ? Maybe similar to one given here
The element segments section
The idea of this section is to fill the WebAssembly.Table objects with content. Initially there was only one table, and its only possible content were indexes/ids of functions. You could write:
(elem 0 (offset (i32.const 1)) 2)
It means: during the instantiation of the instance fill index 1 of table 0 with a value of 2, like tables[0][1] = 2;. Here 2 is the index of the function the table will store.
The type of element segment above is called active nowadays, and after the instantiation it will no longer be accessible by the application (they are "dropped"). From the specs:
An active element segment copies its elements into a table during instantiation, as specified by a table index and a constant expression defining an offset into that table
So far so good. But it was recognized that there is a need for a more powerful element segment section. Introduced were the passive and the declarative element segments.
The passive segment is not used during the instantiation and it is always available at runtime (until is not dropped, by the application itself, with elem.drop). There are instructions (from the Bulk memory and table instructions proposal, already integrated into the standard) that can be used to do operations with tables and element segments.
A declarative element segment is not available at runtime but merely serves to forward-declare references that are formed in code with instructions like ref.func.
Here is the test suite, where you can see many examples of element segments (in a text format).
The binary format
Assuming that you parser the code, you read one u32, and based on its value you expect the format from specification:
0 means an active segment, as the one above, for an implicit table index of 0, and a vector of func.refs.
1 means a passive segment, the elemkind (0x00 for func.ref at this time), followed by a vector of the respective items (func.refs).
2 is an active segment.
3 means a declarative segment.
4 is an active segment where the values in the vector are expressions, not just plain indexes (so you could have (i32.const 2) in the above example, instead of 2).
5 passive with expressions
6 active with table index and expressions
7 declarative with expressions
For this reason the specs says that from this u32 [0..7] you can use its three lower bits to detect what is the format that you have to parse. For example, the 3th bit signifies "is the vector made of expressions?".
Now, all that said, it seems that the reference types proposal is not (yet) fully integrated into the specification's binary format (but seems to be in the text one). When it is you will be able to have other then 0x00 (func.ref) for an elemkind.
It is visible that some of this formats overlap, but the specification evolves, and for backward compatibility reasons with the earliest versions the format is like this today.
I have an examination paper of Operating System Concepts which contains a rather hard problem and I have to review it before taking exam. I don't quite understand about the problem and don't know how to count the number of blocks of a file referred on the problem. Please help me.
An operating system uses 32-bit pointer to allocate files with linked list method. Assume a block of data has the size of 4KB and the first 32 bits of the block contains the pointer, the rest contains the data. We also assume that the following function has been successfully called in an application program:
fd = open('myfile.bin',O_RDONLY);
and myfile.bin is a file having the size of 20480 bytes.
a) Count the number of blocks that needs to be read (including the block that contains the pointer to the first block of the list) when we perform the following system function
lseek(fd,16385,SEEK_SET); read(fd,&c,1);
b) Count the number of blocks that needs to be read when we have to continue performing the following system function right after the system function performance in part a.
lseek(fd,2048,SEEK_CUR); read(fd,&c,1);
Recently, when I reading the webgl spec. I have a question about below, since my program has randomly error on chrome browser due to it:
What will happen if an attribute is used in program without binding a buffer and enabled during a call to drawArrays or drawElements?
The spec only says that:
If a vertex attribute is enabled as an array, a buffer is bound to
that attribute, but the attribute is not consumed by the current
program, then regardless of the size of the bound buffer, it will not
cause any error to be generated during a call to drawArrays or
drawElements.
If a vertex attribute is enabled as an array via
enableVertexAttribArray but no buffer is bound to that attribute via
bindBuffer and vertexAttribPointer, then calls to drawArrays or
drawElements will generate an INVALID_OPERATION error
Can anyone help me on this??
The second paragraph says you'll get an error, always, if you enable an attribute but don't bind a buffer.
There's 4 possibilities
You have an attribute enabled with a buffer bound and that attribute is used by the current shader program.
In this case the buffer must be large enough to handle whatever you try to draw. In other words if you have a buffer with 3 vertices but you ask WebGL to draw 4 vertices you'll get an error. Or if you call gl.drawElements and one of your indices is greater than 2 you'll get an error.
You have an attribute enabled with a buffer bound and that attribute is NOT used by the current shader program.
In this case there will be no error even if the buffer is not large enough because the buffer is not used.
You have an attribute enabled with NO BUFFER bound.
In this case you'll get an error, always.
You have an attribute disabled
In this case it will use the value supplied by calling gl.vertexAttrib4f or one of its variants.
The 2 paragraphs you quoted from the spec cover cases 2 and 3 above.
I have a binary image for an embedded CPU where a memory area contains a number of pointers to entry points into the binary. This is an interrupt vector table in the binary used by the CPU. How can I hint to IDA what this memory is, so it can use the entry points for its analysis?
I'll assume you already have your IDB setup using the correct processor for the loaded binary image.
If the image file is a raw file (ie, without a header), you can define the low/high address suspiciousness limits under the Disassembly tab in Options->General.
With this set, you can set the first element in this vector to be an offset by either placing the text cursor on the first byte and pressing 'O' or 'Ctrl+O'. You can also do 'Ctrl+R' for a 'user-defined' offset (brings up a dialog with multiple options). All the various offsets can be viewed under Edit->Operand type->Offset->...
With the first element set, and with your text cursor on it, you can then hit the '*' key on your numpad to create an actual array (assuming you know how many elements are in the vector). This should apply the same operand type information to all the elements in the array. Since in this case the operand is an offset, IDA should (automatically) try and disassemble the bytes which are referenced.
Note: if an elements value falls outside the suspiciousness limit, it won't be turned into an offset
If this is a raw image, you may wish to setup some Segments info (Shift+F7) if you know the binary contains sections of pure code or pure data. I'm not sure off hand if the 'automatic disassembly' mentioned above is done only when a segment's class is defined as 'CODE' or if it even matters.
Note: you can always re-run analysis by pressing the colored circle icon in the toolbar (it should green, else IDA is busy doing something) or by clicking "Reanalyze program" in the Analysis tab in General->Options.
I want to let the user save some bigger data in a shared object by choice. Is it possible to define the size the user needs to allow?
I'ld like to set the minimum to at least 10 MB to have some extra space for future usage.
I'm talking about this permission window:
http://www.flexdevelopers.com/b/uploaded_images/permission-773954.png
Thanks
Yes. SharedObject.flush() takes a minDiskSpace:int parameter.