Chunk data can be returned as binaries or as compound terms. Compound terms are returned when chunks are referenced by names (atoms) rather than identifiers (strings). The names recognized and the corresponding identifiers are:
The option
Source code can be reconstructed from the debug information. Use encrypted debug information (see below) to prevent this.
The debug information can also be removed from BEAM files
using
Here is an example of how to reconstruct source code from
the debug information in a BEAM file
{ok,{_,[{abstract_code,{_,AC}}]}} = beam_lib:chunks(Beam,[abstract_code]).
io:fwrite("~s~n", [erl_prettypr:format(erl_syntax:form_list(AC))]).
The debug information can be encrypted in order to keep the source code secret, but still being able to use tools such as Xref or Debugger.
To use encrypted debug information, a key must be provided to
the compiler and
The default type -- and currently the only type -- of crypto
algorithm is
As far as we know by the time of writing, it is
infeasible to break
There are two ways to provide the key:
Use the compiler option
If no such fun is registered,
Store the key in a text file named
In this case, the compiler option
The
{debug_info, Mode, Module, Key}
The
Here is an example of an
7}|pc/DM6Cga*68$Mw]L#&_Gejr]G^"}].]]>
And here is a slightly more complicated example of an
7}|pc/DM6Cga*68$Mw]L#&_Gejr]G^"}].]]>
Do not use any of the keys in these examples. Use your own keys.
Each of the functions described below accept either the module name, the filename, or a binary containing the beam module.
The list of attributes is sorted on
"Abst" | "Attr" | "CInf" | "ExpT" | "ImpT" | "LocT" | "Atom"
It is not checked that the forms conform to the abstract format
indicated by
Reads chunk data for selected chunks refs. The order of the returned list of chunk data is determined by the order of the list of chunks references.
Reads chunk data for selected chunks refs. The order of the returned list of chunk data is determined by the order of the list of chunks references.
By default, if any requested chunk is missing in
Returns the module version(s). A version is defined by
the module attribute
1> beam_lib:version(a). % -vsn(1).
{ok,{a,[1]}}
2> beam_lib:version(b). % -vsn([1]).
{ok,{b,[1]}}
3> beam_lib:version(c). % -vsn([1]). -vsn(2).
{ok,{c,[1,2]}}
4> beam_lib:version(d). % no -vsn attribute
{ok,{d,[275613208176997377698094100858909383631]}}
Calculates an MD5 redundancy check for the code of the module (compilation date and other attributes are not included).
Returns a list containing some information about a BEAM file
as tuples
The name (string) of the BEAM file, or the binary from which the information was extracted.
The name (atom) of the module.
For each chunk, the identifier (string) and the position and size of the chunk data, in bytes.
Compares the contents of two BEAM files. If the module names
are the same, and all chunks except for the
The
The
The
The
The
Given the error returned by any function in this module,
the function
The
If there already is a fun registered when attempting to
register a fun,
The fun must handle the following arguments:
CryptoKeyFun(init) -> ok | {ok, NewCryptoKeyFun} | {error, Term}
Called when the fun is registered, in the process that holds
the fun. Here the crypto key fun can do any necessary
initializations. If
CryptoKeyFun({debug_info, Mode, Module, Filename}) -> Key
Called when the key is needed for the module
CryptoKeyFun(clear) -> term()
Called before the fun is unregistered. Here any cleaning up
can be done. The return value is not important, but is passed
back to the caller of
Unregisters the crypto key fun and terminates the process
holding it, started by
The