Sharing in Typed Module Assembly Language
Dominic Duggan
Department of Computer Science
Stevens Institute of Technology
Hoboken,NJ07030.
dduggan@https://www.doczj.com/doc/f02812539.html,
Abstract.There is a growing need to provide low-overhead software-
based protection mechanisms to protect against malicious or untrusted
code.Type-based approaches such as proof-carrying code and typed as-
sembly language provide this protection by relying on untrusted compil-
ers to certify the safety properties of machine language programs.Typed
Module Assembly Language(TMAL)is an extension of typed assem-
bly language with support for the type-safe manipulation of dynamically
linked libraries.A particularly important aspect of TMAL is its support
for shared libraries.
1Introduction
Protection of programs from other programs is an old and venerable problem, given new urgency with the growing use of applets,plug-ins,shareware software programs and ActiveX controls(and just plain buggy commercial code).His-torically the conventional approach to providing this protection has been based on hardware support for isolating the address spaces of di?erent running pro-grams,from each other and from the operating system.The OS kernel and its data structures sit in a protected region of memory,and machine instructions are provided to“trap”into the kernel in a safe way to execute kernel code.
While this approach to protection is widely popularized by operating systems such as Windows2000and Linux,there is a growing desire to?nd alternatives. The problem is that this technique is a fairly heavyweight mechanism for pro-viding protection,relying on expensive context switching between modes and between address spaces.Although application designers have learned to pro-gram around this expensive context switching(for example,bu?ering I/O in application space),this approach breaks down very quickly in software systems composed of separately authored subsystems that do not place much trust in each other,and where context switches may occur much more frequently than in an OS/application scenario[36].
In the OS research community,investigation of alternatives has been mo-tivated by the demands of modular micro-kernel operating systems,where OS modules outside the kernel might not be trusted.Software fault isolation(where the loader inserts software sandboxing checks into machine code[35])and the SPIN project(where type-safe OS modules are compiled by a trusted compiler
R.Harper(Ed.):TIC2000,LNCS2071,pp.85–116,2001.
c Springer-Verlag Berlin Heidelberg2001
86 D.Duggan
[5])are examples of approaches to providing protection in software rather than hardware.Sandboxing in Java VMs has also been motivated by the expense of hardware-based memory protection for applets[36].The commercial world is see-ing an explosion in the use of component technology,exempli?ed by Java Beans and ActiveX controls.This use of component technology again motivates the need to?nd some relatively lightweight software-based approach to protection in running programs.
Proof-carrying code[30,29]and typed assembly language[28,27]are ap-proaches to providing this protection at low run-time cost.These approaches are examples of self-certifying code.A compiler produces a certi?cate that a program satis?es some property of interest,for example,that the program is well-typed. The user of a compiled program can check that the certi?cate supplied with a program is valid for that program.If the check succeeds,the program can be run without run-time checks for the safety properties veri?ed by the certi?cate.This approach has the advantage of moving the compiler out of the trusted computing base,while reducing the need for run-time checks in the code.
Typed assembly language(TAL)enforces a type discipline at the assembly language level,ensuring that malicious or carelessly written components cannot use“tricks”such as bu?er over?ows or pointer arithmetic to corrupt the data structures in a running program.Unlike the typed machine language underlying the JVM,TAL is not tied to a particular language’s type system or interpreter architecture.Instead the type system is a moderately generic high-level type system with procedures,records and parametric polymorphism,while the target assembly language is any modern RISC or CISC assembly language.The type system is designed to be rich enough that it can serve as a target for compilers for many di?erent languages,while at the same time having as much freedom as possible in its choice of code optimizations,parameter-passing conventions,and data and environment representations[10].
Given the importance of component technology as a motivating factor for TAL,it is clear that there should be support for manipulating components in a type-safe but?exible manner.Modular Typed Assembly Language(MTAL) extends TAL to typed object?les and type-safe linking[14].However this is limited by the assumption that all of a program is linked together before the program is run,with linking happening outside of the program itself.Dynamic linking may be used to avoid loading an entire library when only a small part of the library will be needed.For example,the Linux kernel uses dynamic linking to load in kernel modules on an as-needed basis.While static linkers do a good job of only linking those parts of a library that a program references,they cannot predict in advance what of the referenced modules a program might actually use. Dynamic linking is also useful for shared libraries,allowing several processes to share a commonly used library in memory.Indeed one can consider the operating system itself as a shared library,one that is made available in a protected region of memory to all running programs.
Our interest is in extending TAL with support for dynamic linking and shared libraries.Glew and Morrisett[14]consider some alternative approaches to ex-
Sharing in Typed Module Assembly Language87 tending MTAL with dynamic linking1,but this consideration is only informal. One issue that they do not consider,which is central to our work,is what model dynamic linking should use for software components and for linking components.
An obvious candidate is the ML module system[26],which provides fairly sophisticated support for type-safe linking as a language construct[23,6].Indeed this is the philosophy underlying MTAL,which relies on a phase-splitting trans-formation to translate ML modules to TAL object?les.However the problem with this approach is that it leads to two di?erent models of linking:
1.At the source language level,linking is based on applying parameterized
modules.Higher-order parameterized modules may be useful for separate compilation[16,15,18,24,19],but there are still problems with supporting recursive modules[8](as are found in Java and C).
2.At the assembly language level,linking is based on a type-safe version of the
Unix ld command.Circular imports present no problem at this level,but much of the sophistication of the type system for ML modules is lost.This is unfortunate,since there are many lessons to be learned from ML that could fruitfully be applied to develop rich linking operations for languages such as Java.
This article describes Typed Module Assembly Language(TMAL),an ex-tension of TAL with run-time support for loading,linking and running modules. Work on dynamic linking has focussed on class loading in the Java virtual ma-chine[21].Java has the problem of a weak MIL.On the other hand,ML has a powerful MIL but no support for dynamic linking.The current work was orig-inally motivated by the desire to bridge this gap.TMAL pursues a model of linking that is closer to the MTAL approach than the ML approach,because it is closer to the form of linking used by popular languages such as Java.TMAL enriches the MTAL approach in several ways,drawing lessons from the ML ex-perience,but also limiting the ML approach in some ways that are not limiting for Java applications,but do avoid problems with extending ML modules to support Java.
We make the following contributions to TAL:
1.We enrich TAL with coercive interface matching,which allows a module
to be coerced to an expected type that makes some?elds of the module “private.”This is present in for example the ML module system,but not in MTAL.On the other hand,ML does not provide the same linking primitives as MTAL.
2.We enrich TAL with support for shared libraries.This is supported in the
ML module language but not in MTAL.On the other hand,ML does not 1Glew and Morrisett refer to“dynamic linking”as the process of linking an executable with libraries when it is?rst invoked,while they refer to“dynamic loading”as the linking and loading of libraries at an arbitrary point during execution.Our use of the generic term dynamic linking is meant in the latter sense.We provide separate operations for“loading”a module(re?ecting it from the core language to the module language)and for“linking”(linking together two modules).
88 D.Duggan
support recursive modules,which are present in MTAL and which complicate the de?nition of shared libraries.
3.We extend TAL with primitives for type-safe dynamic linking.Our approach
resolves some open problems with dynamic linking and abstract data types.
In particular,because types exported by modules are named but opaque (wholly or partially),it is not possible for run-time type checking to discern the underlying representation type for an abstract type.
TMAL arises out of work on a high-level module language,incorporating ideas from ML but with application to languages such as Java,including support for recursive DLLs and shared libraries[12].It can be viewed as a demonstration of how the semantics of that module language can be incorporated into typed assembly language.A central aspect of this scheme is the proper treatment of shared libraries,an important issue that is addressed in the ML module lan-guage but not in more low-level typed module languages[7,14].A related issue is a phase distinction in module languages2,between the link-time phase of a module and the run-time phase of a module.The link-time phase is characterized by the application of linking operations to combine a library with other libraries. The run-time phase is initiated by the execution of the initialization code for a library,during or after which the de?nitions in the library are available to a running client.In static linking the client is always another software component with which the library is linked.With dynamic linking,the client is the running program that loads and initializes the library.This issue is not often explicitly acknowledged in the literature.In TMAL it is recognized by an explicit initial-ization operation,dlopen,that provides the demarcation point between these two phases in the lifetime of a module.
In Sect.2we give a brief review of TAL and MTAL.In Sect.3we reconsider the approach used in MTAL to represent abstract types that are exported by typed object?les,and in particular how type equality and type de?nitions are handled.In Sect.4we give an overview of TMAL.The next four sections describe the operations of TMAL in more detail.In Sect.5we describe TMAL’s support for coercive interface matching.In Sect.6we describe how types and values can be dynamically obtained from a module in TMAL.In Sect.7we describe how shared libraries can be constructed in TMAL.In Sect.8we describe how DLLs are loaded in a type-safe manner in TMAL.Finally Sect.10provides our conclusions.
For reasons of space,we are unable to provide a comprehensive discussion of the various issues in module type systems that motivate some of the design choices presented here.The reader desirous of more contextual discussion than that presented here,is invited to consult[12].The TMAL type system is based on the linking calculusλlink,itself intended as a compilation target language 2This should not be confused with the phase distinction between compile-time and run-time explicated by Harper et al[16].The phase distinction between link-time and run-time does not exist in the latter calculus,because it translates module-level linking(functor application)to core language operations(function application and generic instantiation).
Sharing in Typed Module Assembly Language89 for a more high-level module languageλmod,described in[12].The correctness properties ofλlink carry over to TMAL.There may be some interest in verifying a translation fromλlink to TMAL.
2Modular Typed Assembly Language
In this section,we review Typed Assembly Language(TAL)and Modular Typed Assembly Language(MTAL).This review is largely based on descriptions in the literature[28,10,14].The syntax of MTAL is given in Fig.1.Typed Assembly Language can be explained as the result of carrying types in a high-level language through the compilation process,all the way to the?nal output of assembly language in the backend.Starting with a high-level language,say with procedures
K∈Kind::=ty|(K1→K2)
A,B∈Type Cons::=t|int|?[t1,...,t m]Γ|
A j11,...,A j k k
j∈Initialization Flag::=0|1
Φ∈Type Heap Interface::={t1:K1,...,t k:K k}
Ψ∈Value Heap Interface::={x1:A1,...,x k:A k}
Γ∈Register File Type::={r1:A1,...,r k:A k}
?∈Type Var Context::={t1:K1,...,t k:K k}
h∈Heap Value::=code[t1,...,t m]Γ.I| w1,...,w k
r∈Register Name::=r0,r1,...
w∈Word Value::=n|x|w[A1,...,A k]|...
v∈Small Value::=w|r
TH∈Type Heap::={t1→A1,...,t k→A k}
VH∈Value Heap::={x1→h1,...,x k→h k}
R∈Register File::={r1→w1,...,r k→w k}
I∈Instruction Sequence::=i1;...;i k
i∈Instruction::=add r1,r2,v|malloc r[A]|jmp v|...
Int∈Interface::=(Φ,Ψ)
O∈Object File::=[Int I?(TH,VH):Int E]
E∈Executable::=(TH,VH,x)
P∈Program State::=(TH,VH,R,I)
Fig.1.Syntax of MTAL
90 D.Duggan
and records,programs are translated to an assembly language where procedures have been translated to code segments(with code for environment-handling)and records have been translated to heap blocks.Thus for example the procedure de?nition:
int fact(int x){
int y=1;
while(x!=0)y=(x--)*y;
return y;
}
is translated to the code segment:
fact:code[]{a0:int,ra:?[]{v0:int}}.
mov v0,1
jmp loop
loop:code[]{a0:int,v0:int,ra:?[]{v0:int}}.
bz a0,ra
mul v0,a0,v0
sub a0,a0,1
jmp loop
The register ra is the continuation or return address register,pointing to the code to be executed upon return.The fact procedure expects an integer in the argument register a0,and returns to its caller with an integer in the value return register v0.We use MIPS gcc calling conventions to name the registers in examples.
In general heap values h have the form:
1.A code segment code[t1,...,t m]Γ.I,with register?le typeΓ={r1:
A1,...,r n:A n}.This is a code segment parameterized over m type variables t1,...,t m and expecting its n arguments in the argument registers r1,...,r n.
The types of the values in the argument registers are speci?ed in the register ?le type.I is the sequence of assembly instructions for the code sequence.
This segment has the code type?[t1,...,t m]Γ.
2.A heap block w1,...,w k where the k values w1,...,w k are word val-
ues.Such a heap block has a heap block type A j11,...,A j k k ,where each j h∈{0,1}indicates if the h th slot has been initialized.Note that the tuple type A j11,...,A j k k should not be confused with tuples of types;we do not therefore have tuple kinds,although they could be added straightforwardly.
Parametric polymorphism is used in an essential way to abstract over the call stack in typing a procedure de?nition.For example the most general de?nition of fact is:
fact:code[EnvT]{a0:int,sp:EnvT,ra:?[]{v0:int,sp:EnvT}}.... where the sp register points to the environment of the calling procedure.The type parameter EnvT ensures that the continuation is passed the calling proce-dure’s environment upon return.
Sharing in Typed Module Assembly Language91 An operational semantics is speci?ed using program states of the form (VH,R,I),where
1.VH={x→h}is a value heap,a mapping from labels to heap values h;
2.R={r→h}is a register?le,a mapping from register names to values;and
3.I is a sequence of typed assembly instructions.
Program states are typed using register?le typesΓ={r:A}and heap types Ψ={x:A},where the latter maps from labels to types.The heap contents are unordered and may contain circular references.
Modular TAL(MTAL)extends these concepts to object?les for independent compilation and type-safe linking.An untyped object?le imports some values and exports some values,identi?ed by labels pointing into the object?le heap.A MTAL object?le places types on the imported and exported labels.Furthermore, to support the exportation of abstract data types,an MTAL object?le imports and exports types and type operators,identi?ed by labels pointing into a type heap in the object?le.An object?le O in MTAL has the form
[(ΦI,ΨI)?(TH,VH):(ΦE,ΨE)]
whereΦI andΦE are type interfaces mapping labels to kinds,ΨI andΨE are value interfaces mapping labels to types,TH={t→A}is a type heap mapping labels to type and type operator de?nitions and VH={x→h}is a value heap mapping labels to initial values.ΦI andΨI provide the interfaces for imported types and values,whileΦE andΨE provide the interfaces for exported types and values.An interface is a pair Int=(Φ,Ψ)of type and value heap interfaces.
There are three operations in the MTAL module language:
1.Linking:O1link O2;O combines the object?les O1and O2into the
single object?le O.Imports in O1and O2may be resolved during linking.
Interface checking ensures that resolved imports have the correct type. 2.Executable formation:(O,x)prg;E identi?es the label for executing the
code of the object?le.Type-checking ensures that this label is bound in the value heap,and that all imports have been resolved.
3.Execution of an executable:E exec;P produces a program state of the
operational semantics from an executable.Program states are extended to include a type heap,and have the form(TH,VH,R,I).
3Type Heap Reconsidered
Before giving a description of TMAL,it is useful to explain how our treatment of the type heap and type identity di?ers from that of MTAL.In MTAL there are two views of a type:
1.Within an object?le,a type exported by that object?le is completely trans-
parent.The de?nition of a type label is given by its binding in the type heap, TH.Because the type heap may contain circular bindings,there are word
92 D.Duggan
value operations unroll(w)and roll t(w)that unfold and fold the de?nition of a type label in the type of w,respectively.For example if a?le system module de?nes a?le abstract type t as int1,int1 ,and w is a word value with this type,then roll t(w)gives a word value with type t,that is with the concrete type folded to the de?ned type.This means that all types de?ned in object?les are datatypes.In other words,there is no equality theory for implicitly ununfolding the de?nitions of type identi?ers exported by object ?les,so type equivalence for such type identi?ers is based on name equiva-lence rather than structural equivalence.
2.Outside of an object?le,a type exported by that object?le may be trans-
parent or opaque.The interface only provides the kind,and the type heap is only visible within the module.Hicks et al[9]use a module system similar to MTAL,except that they also allow an object?le to export some of its type de?nitions,so types may be made transparent to clients.
The advantage of requiring all de?ned types to be datatypes is that recursive types are assured to be iso-recursive types3,thus greatly simplifying the problem of type-checking.The problem with this approach is that it does not adequately handle type sharing for shared libraries.This is explained in more detail in[12]. Consider for example the following Objective ML code[31]:
module type S=sig type t;val x:t end
module S1:S=struct type t=C;val x=C end
module S2:(S where type t=S1.t)=S1
if true then S1.x else S2.x
The module S1de?nes a datatype t with single constructor C,and binds the?eld x to this constructor.The last conditional type-checks because S2.x has type S2.t,and the type of S2includes the constraint t=S1.t,which is also the type of S1.x.The structure S1is an example of a shared library,in the sense that the identity of its(abstract)type component S1.t is shared with S2.t.The datatype restriction,on the other hand,requires the insertion of marshalling and unmarshalling code at the interface of a shared library,severely curtailing its usability.An example is provided in[12].
It is informally mentioned in the description of MTAL that the implemen-tation includes singleton kinds to expose type de?nitions to clients of object ?les.However this is not formalized in the type system and therefore several important issues are left unresolved.For example it is not hard,using singleton kinds,to de?ne two mutually recursive types in separate object?les,and link-ing those?les then results in equ-recursive types.This problem can be avoided by only allowing singleton kinds to contain type labels,where the de?nitions remain encapsulated in the type heap in the object?le.In terms of the type 3Harper,Crary and Puri[8]make the distinction between iso-recursive and equ-recursive types.The latter require an equality theory for types that includes a rule for implicitly unrolling a recursive type.The former do not require this equality, and instead rely on operations in the language for explicitly folding and unfolding recursive types.
Sharing in Typed Module Assembly Language93 system presented here,this amounts to only allowing type sharing constraints in the interface,and not allowing type de?nitions to be exposed.
In our type system we allow both exposure of type de?nitions,and type sharing,to be expressed in module interfaces.This is done without allowing equ-recursive types in the type system.This is done by separating these two uses of type information in the interface:
1.Exposure of type de?nitions is expressed using box kinds.Box kinds di?er
from singleton kinds in the following way:whereas singleton kinds allow implicit equality of a type identi?er with the type in its singleton kind,box kinds require explicit coercions in the term language between a type identi?er and the type in its box kind.
2.Type sharing is expressed using type sharing constraints.The type system
includes an equality theory that is merely the congruence closure of an equal-ity between type identi?ers de?ned by a context of type sharing constraints.
Since equality is only between identi?ers,there is no problem with analysing recursive constraints.This is particularly important when we consider dy-namic type-checking of DLLs.
TMAL replaces the roll t and unroll operations of MTAL,with operations for constructing and deconstructing values of types with box kind:
Introduction Elimination
MTAL Expression roll t(w)unroll(w)
MTAL Side-Condition w:A,TH(t)=A w:t,TH(t)=A
TMAL Expression fold t(w)unfold t(w)
TMAL Side-Condition t: A,w:A t: A,w:t Because the TMAL operations are typed independently of the type heap,box kinds can be used to expose type de?nitions in the interface of an object?le.In contrast with singleton kinds,because explicit coercions are required between a type with box kind and the type in its kind,recursive types are guaranteed to be iso-recursive types.
4Typed Module Assembly Language
Fig.2provides the syntax of Typed Module Assembly Language.In comparison with MTAL,the major changes in module interfaces are:
1.We enrich kinds with box kinds A.For simplicity we only consider simple
types in this account.Box kinds generalize to type operators with some care
[12].
2.We enrich import and export interfaces Int with a type sharing contextΞ.
This is a set of equality constraints between type identi?ers.
94 D.Duggan
K∈Kind::=ty| A
A,B∈Type Cons::=t|int|?[t1:K1,...,t m:K m]Γ
| A j11,...,A j k k | |OT|Int j∈Initialization Tag::=0|1
Φ∈Type Heap Interface::={t1::t1:K1,...,t k::t k:K k}
Ψ∈Value Heap Interface::={x::x1:A1,...,x::x k:A k}
Ξ∈Type Sharing Cons::={t1～=t 1∈K1,...,t k～=t k∈K k}
Γ∈Register File Type::={r1:A1,...,r k:A k}
?∈Type Var Context::={t1:K1,...,t k:K k}
h∈Heap Value::=code[t1:K1,...,t m:K m]Γ.I
| w1,...,w k | w,OT |O|ST r,r m,r s∈Register Name::=r0,r1,...
w∈Word Value::=n|x|w[A1,...,A k]|...
v∈Small Value::=w|r
TH∈Type Heap::={t1::t1:K1B A1,...,t k::t k:K k B A k}
B A∈Type Binding::= A(Type De?nition)
|～=t(Shared Type Binding)
VH∈Value Heap::={x1::x1:A1B e1,...,x k::x k:A k B e k}
B e∈Value Binding::= h(Value De?nition)
|～=x(Shared Value Binding)
R∈Register File::={r1→w1,...,r k→w k}
ρ∈Renaming Substitution::={n1→n 1,...,n k→n k}
I∈Instruction Sequence::=i1;...;i k
i∈Instruction::=add r1,r2,v|malloc r[A]|jmp v|...
Int∈Interface::=(Φ,Ψ,Ξ)
OT∈Object File Type::=[Int I?Int E]
O∈Object File::=[Int I?(TH,VH):Int E]
ST∈Symbol Table::={t→t,x→y}
P∈Program State::=(TH,VH,R,I)
Fig.2.Syntax of TMAL
Sharing in Typed Module Assembly Language95
Purpose Instruction Semantics
Linking,dllink r m1,r m2,r m3Link modules
interface dlcoerce r m1,r m2,OT Coerce to interface
matching dlrename r m1,r m2,ρRename external labels
Dynamic dlopen r s,r m Initialize module
imports dlsym t[t:K]r s1,r s2,t Import type
dlsym v r,r s,x Import value
Shared dlsetsym t r m1,r m2,t,t Set shared type
de?nitions dlsetsym v r m1,r m2,v,x Set shared value
Dynamic dldynamic r,v,OT Construct DLL
linking dlload r m,r1,r2,OT Extract module
Fig.3.Summary of TMAL instructions
3.To support coercive interface matching,we add external labels to type and value heap interfaces.As explained in the next section,this allows some of the?elds in a module to be safely made private,whereas allowing private ?elds in MTAL leads to the possibility of run-time name clashes.
There are two forms of module values in TMAL:
1.Modules or object?les O≡[Int I?(TH,VH):Int E].This de?nes a type heap TH and a value heap VH,that may be linked with other such heaps using the TMAL operations.Int I≡(ΦI,ΨI,ΞI)is the interface of symbols imported by the module,while Int E≡(ΦE,ΨE,ΞE)is the interface of symbols exported to clients of the module.
2.Symbol tables ST≡{t→t,x→x}.A symbol table arises from the initial-ization of a module.Initializing a module adds its type and value de?nitions to the type and value heaps,respectively,of the running program.The sym-bol table provides mappings from the external labels of the module to the heap addresses of its de?nitions.TMAL provides operations for dynamically importing these addresses into a running program,using a symbol table to perform a run-time lookup based on external labels.
A type heap de?nition t::t:K
B A has one of two forms:
1.A de?nition of the form t::t:K A de?nes a branded type t with external name t and de?nition A.External names are explained in the next section. The most general kind for such a type is A,revealing the structure of the type de?nition.This is a subkind of ty,the kind of simple types that makes type de?nitions opaque.
96 D.Duggan
2.A de?nition of the form t::t:K～=t de?nes a shared type t that is equated
to the type t .Such a type sharing de?nition can be exposed in an interface by a type sharing constraint t～=t ∈K.
Similarly a value heap de?nition x::x:A B e has one of the two forms x::x: A h(analogous to a value heap de?nition x→h in MTAL)or x::x:A～=y (a value sharing de?nition).Module initialization transforms a value sharing de?nition to a value heap de?nition x::x:A h by looking up the de?nition of y in the heap.Initialization may detect circular value sharing de?nitions,which correspond to values with no clearly de?ned initial values.
Are?rst-class modules necessary for dynamic linking?In TMAL,modules are manipulated(loaded,coerced and linked)at run-time.This in itself does not necessarily require modules as?rst-class values,and indeed TMAL is based on a module language where there is a strict separation between module values and simple values[12].Nevertheless a critical part of the transition from a high-level language to TAL is closure conversion,where environment slots are allocated for local variables in a procedure,and the contents of the register?le are saved to the environment on a procedure call.Since some local variables may be bound to module values,it is therefore necessary in TMAL to make modules into?rst-class values.For example,the kernel language described in[12]includes a letmod construct for binding a local module identi?er to a module:
letmod s=Mod in Expr
where Mod is a module language expression and Expr a core language expression. Closure conversion then requires that an environment slot be allocated for the free module identi?er s,leading to the need for?rst-class modules.
This potentially has some unpleasant consequences.For example Lillibridge [22]has demonstrated that type-checking is undecidable for a type system with ?rst-class modules.The source of this undecidability is a subtype relation be-tween modules that allows?elds to be made private,and allows type de?nitions to be made opaque.There is no such subtype relation in the core language of TMAL,and therefore no such subtyping for modules.This makes“?rst-class”modules in TMAL strictly less powerful than general?rst-class modules.For example with general?rst-class modules,it is possible for the two arms of a con-ditional to return modules with di?erent interfaces,by having the result interface contain the intersection of the?elds of the two modules.However the weak type system for modules in TMAL is su?cient for the purposes of closure conversion, and avoids the undecidability problems with more general type systems.
Rather than allowing type subsumption for modules,TMAL has a dlcoerce instruction for explicitly coercing a module to a required type.This coercion operation requires that the module’s type be a subtype of the required type:
OT OT ??OT≡[Int I?Int E],OT ≡[Int I?Int E],
Int I Int I and Int E Int E
Int Int ??Int≡(Φ,Ψ,Ξ),Int ≡(Φ ,Ψ ,Ξ ),
Sharing in Typed Module Assembly Language97
Φ≤Φ ,Ψ≤Ψ ,andΞentailsΞ
Φ≤Φ ??Φ≡{t k::t k:K k},Φ ≡{t m::t m:K m},k≥m,K m≤K m Ψ≤Ψ ??Ψ≡{x k::x k:A k},Ψ ≡{x m::x m:A m},k≥m,A m=A m So interface containment reduces to kind containment(where the only contain-
ments are of the form A≤ty)and equality between types.The latter equality relation includes entailment based on sharing constraints in the context.The lat-ter constraints can only relate type identi?ers,so the equality relation includes rules for forming the congruence closure of these equalities.Because sharing constraints can only relate type identi?ers,it is straightforward to extend the language of types with type operators(λ-abstraction)andβ-conversion of types.
The type formation rules for modules(object?les)and symbol tables are provided in App.A.These operations are discussed in Sect.5–8,and formally speci?ed in App.B.
5Coercive Interface Matching
MTAL assumes that all?eld names are globally de?ned,and interface matching is based on these global?eld names.Any“implicit”renaming of an identi?er requires it to be rewritten globally.There is no notion(as in our approach)of di?erentiating between external and internal names,with internal names locally bound,and therefore allowing local renaming of these internal names to avoid name clashes during linking.In the MTAL approach,if two modules have?elds with the same name,these names are references to the same global symbol, and any renaming of the symbol must be performed in both modules.As a consequence,if?elds of an object?le are made private in MTAL,there is no way to rename the private?elds in order to avoid name clashes when this object ?le is linked with other object?les.
We want to support run-time linking where a library is loaded from disk into the program address space and linked with other libraries.Type safety requires a run-time type check at some point in this scenario.This type check requires that the labels do not admit implicit renaming(such as alpha-conversion in the lambda-calculus).We do not expect that all labels of the loaded library are known,only those labels speci?ed in the expected interface in the run-time type check.Following the MTAL approach,there is the potential for confusion of labels because some of the“hidden”labels in the loaded library may be the same as labels in the libraries it is linked with.
This is the motivation for generalizing labels in type and value heap interfaces to include external names t and x.Type and value heap interfaces have the form
Φ={t::t:K}andΨ={x::x:A}
The internal names t and x represent local(type and value)heap addresses. These names admit implicit renaming or alpha-conversion,corresponding to re-locating symbols in a heap.The external names t and x represent external labels
98 D.Duggan
that allow reference to the internal contents of a heap component of a module from outside.To allow?elds of a module to be made private,external type and value names in type and value heaps include the special symbol ,the name of a private?eld.Fields in a module are made private using the dlcoerce instruc-tion,that changes the external names of?elds made private to .The private external name should never appear in a type or value heap type.
Before the contents of a module can be used by a running program,its heaps must be combined with the program heaps.This combination ensures that the internal labels of the module heaps are distinct from the internal labels in the program heaps.
Following[12],we provide three operations for combining and adapting mod-ules.The choice of these operations is informed by an analogy between module combination and process composition in process algebras such as CCS[25]:
Operation TMAL CCS
Linking dllink r m1,r m2,r m3(P|Q)
Coercion dlcoerce r m1,r m2,OT(P\x)
Renaming dlrename r m1,r m2,ρP[ρ]
The dllink instruction links together two modules,combining the type and value heaps.The modules being linked together are in the source registers r m2and r m3,and the result of linking is left in the destination register r m1.The exports of the resulting module are the union of the exports of the two modules,while the imports are the union of the imports of the linked modules minus any imports that are resolved by linking.To obtain a coherent result,the type rules require that the external labels of the exports of the two linked modules are distinct.To maintain this restriction,the external labels of a module must always be visible in the type of the module.The linking operation also requires that the internal labels of the exports of the modules be distinct.Since internal names are bound within a module,they can be renamed to avoid name clashes when merging the ?elds of the modules being linked.In a concrete implementation,this renaming is handled straightforwardly by relocating the internal addresses of two object ?les that are linked together.
The dlcoerce instruction is necessary because of the absence of a subsump-tion rule based on interface containment for modules.This latter subsumption rule is not allowable because of the requirement that the external labels of a module must always be visible in its type.The coercion operation performs a run-time adaptation of a module,removing some of its external labels.The cor-responding de?nitions are no longer visible to external clients of the module,but are still accessible via their internal labels to other de?nitions within the module. The source module is in register r m2,while the result of coercion is left in the destination register r m1.The type to which the module is coerced is speci?ed by the object?le type OT.This type annotation is mostly only for type-checking, and can be removed before execution.The part of the annotation that must be
Sharing in Typed Module Assembly Language99 preserved during execution is the association between external names and inter-nal names;TMAL includes instructions for looking up a?eld in an initialized module based on its external name.
The dlrename instruction is a second operation for coercive interface match-ing,and renames some of the external labels in a label.A renaming substitution ρis an injective mapping from external labels to external labels.Since exter-nal names are used at run-time,this renaming substitution must be applied at run-time.
6Dynamic Imports
The instructions given in the previous section operate on values at the module language level.At the heart of the TMAL approach are the instructions that connect the module language level to the core language level.In theλmod module language described in[12],this connection is provided by an init operation that initializes a module and introduces its de?nitions into a local scope in a core language program.In TMAL the init operation is realized by three instructions,for initializing a module and for importing its de?nitions into the scope of a running thread:
Operation TMAL
Initialize module dlopen r s,r m
Import type dlsym t[t:K]r s1,r s2,t
Import value dlsym v r,r s,x
These operations allow a program to import some of the symbols from a DLL, using the external labels of a DLL to access its de?nitions.
The dlopen instruction expects a pointer to a module in register r m.The instruction initializes the module,addings its type and heap bindings to the program heaps,and building a symbol table with mappings from the module ?elds to their bindings in the program heaps.A pointer to this symbol table is left in register r s.
The dlsym t instruction imports a type de?nition into the local context of the current thread,while the dlsym v instruction imports a value de?nition. The dlsym t operation imports a type symbol from a DLL into a register,using the external label of the type symbol and the symbol table of the DLL to map to the internal label.Note that the internal label cannot be known statically; the internal label is chosen at the point where the DLL is initialized and its value de?nitions are added to the program’s value heap.This is in contrast with MTAL,where heap locations are referenced by globally bound internal names, and where renaming to avoid name clashes is not possible.In TMAL,the internal label is chosen so that there is no clash with the labels already given to program heap contents.Since the complete contents of the program heap are not known until run-time,there is no way to know the internal label during type-checking.
100 D.Duggan
The dlsym t instruction expects a pointer to a pointer to a symbol table in register r s2,and speci?es the external name t of the type symbol to be imported in the local thread address space.The instruction binds the type parameter t in subsequent instructions to the type heap address corresponding to this external name.The symbol table type must be modi?ed so that references to the global heap address are rebound to this local type parameter,for type-checking sub-sequent importations of de?nitions that rely on this type symbol.Register r s1is left with a pointer to a symbol table of this modi?ed type.
The dlsym v operation imports(the heap address of)a value de?nition from a DLL into a register,using the external label of the value de?nition and the symbol table of the DLL to map to the internal label.The external name x of the de?nition is speci?ed in the instruction,and the instruction leaves the value heap address of the de?nition in the value register r.
//Assume s1points to loaded file system module
dlopen s2,s1//Initialize module
dlsym t[FileT:ty]s3,s2,File
//Import file type
dlsym v s4,s3,open//Import file open operation
mov a0,file name//Load file name
mov ra,retpt[FileT]//Load continuation
jmp s4[EnvT]//Jump to file open operation
retpt:code[FileT]{v0:FileT,sp:EnvT}...
file name:"/etc/passwd"
Fig.4.Example of dynamic imports
Fig.4gives an example of the use of these operations.Assuming the s1reg-ister points to a module,the dlopen instruction initializes that module,addings its type and value heap de?nitions to those of the running program.The result of initialization is a pointer,in the s2register,to a symbol table mapping from the external labels of the module to the addresses of its de?nitions in the program heaps.
The important proviso in the dlsym v operation is that none of the free type variables in the type of a value de?nition are bound by the type heap de?nitions addressed by the symbol table.For example,recalling the example in Fig.4, assume that the symbol table resulting from initializing the?le system module has type:
type File::File:ty
val open::open:
?[EnvT:ty]{a0:String,sp:EnvT,ra:?[]{v0:File,sp:EnvT}
Sharing in Typed Module Assembly Language101 The abstract?le type File occurs free in the type of the open operation.There-fore the dlsym v instruction cannot import this de?nition immediately.The reason is that the register?le type resulting from this importation would have no binding for the type identi?er File in the type of the v0register.
In order to import the open operation,the type identi?er File that occurs free in its type must?rst be imported from the DLL.This is done using the dlsym t operation.In the example in Fig.4,the dlsym t instruction binds a local type identi?er FileT to the abstract type File de?ned by the DLL.The s3register is bound to a new symbol table with type:
val open::open:
?[EnvT:ty]{a0:String,sp:EnvT,ra:?[]{v0:FileT,sp:EnvT}
The abstract?le type in the type of the open operation has been relocated to a type bound in the local context of the current thread,therefore it is now possible to import the open de?nition from the DLL.
7Shared Libraries
Heaps in modules may contain shared type bindings t::t:K～=t and shared value bindings x::x:A～=y.If all linking is performed before a program runs, then shared bindings are unnecessary.However shared bindings become crucial in an environment where modules are initialized at run-time.
For example,consider a module implementing a network protocol.This im-plementation requires some operations and types that are only provided by the operating system.Module linking can be used to combine these modules into a single module implementing the operating system with that protocol:
//Assume s1points to loaded OS module
//Assume s2points to loaded protocol module
dllink s3,s1,s2//Link OS,protocol modules
dlopen s4,s3//Initialize module
dlsym t[Conn:ty]s5,s4,Conn//Import connection type
dlsym v s6,s5,open//Import conn open operation However there is a di?culty with this approach:the operating system will have already been initialized when the program runs.In fact the operating sys-tem is really the?rst module to be initialized,and a running program is just another module that has been loaded and initialized by code de?ned in the operating system module.
Similar remarks apply to access to OS operations from a process.The process must somehow have access to labels into the OS type and value heaps4,but it is unrealistic to expect a program to be linked with its own copy of the OS module 4As mentioned in Sect.1,approaches such as typed assembly language should be regarded as an alternative to current heavyweight protection mechanisms such as hardware-based memory protection and the use of library stubs to trap to the OS.
102 D.Duggan
before execution can begin.The OS is one example of a shared library,a library that is loaded and initialized once,and that is subsequently available to other libraries as they are loaded.
The following instructions allow a program to construct a shared library:
Operation TMAL
Set shared type dlsetsym t r m1,r m2,t,t
Set shared value dlsetsym v r m1,r m2,r,x
The dlsetsym t instruction allows a reference to a type to be added to the export list of a module,while dlsetsym v instruction allows a reference to a value to be added.These are not the only way that shared value and heap de?nitions can be constructed.For example,the initial value heap in a module may contain the de?nition of another module(manipulated by the parent module at run-time)that has aliases for value and type bindings,where the child module de?nitions that are shared are bound in the parent module heaps,or are imported or exported by the child module.However the aforesaid instructions are the only way to introduce aliases into a module,for shared bindings that are not available until run-time.For example,they are the only way to add bindings for OS types and operations into a module that requires those OS de?nitions.Once such a shared library has been constructed,the dllink instruction allows it to be linked with other modules.
The dlsetsym t instruction expects a pointer to a module in register r m2, and a pointer into the type heap in type“register”t.The module should import a type de?nition with external label t and with a kind compatible with t.The instruction moves the type?eld with label t from the import list of the module to the export list,binding to the?eld to the type heap pointer given by t,and the resulting module is given in register r m1.
The dlsetsym v instruction expects a pointer to a module in register r m2,and a heap address in register r.The?eld labelled with x in the module is moved from the import list to the export list,bound to the value heap pointer in r,and a pointer to the resulting module is left in register r m1.
Returning to the example above of a protocol module,suppose that this module requires a type ProtId of protocol identi?ers and an operation deliver from the OS.The latter operation is used by this protocol module to deliver a protocol data unit to the next protocol above it in the protocol stack.
//Assume s1points to initialized OS module
//Assume s2points to loaded protocol module(PM)
dlsym t[ProtId:ty]s1,s1,ProtId//Import prot id type dlsym v s3,s1,deliver//Import deliver operation dlsetsym t s2,s2,ProtId,ProtId//Export protocol id to PM dlsetsym v s2,s2,s3,deliver//Export deliver to PM
dlopen s4,s2//Initialize PM
Sharing in Typed Module Assembly Language103
Alternatively,if the code for initializing the protocol module is in the OS itself,then this code can be de?ned as:
//Assume s2points to loaded protocol module(PM)
dlsetsym t s2,s2,ProtId,ProtId//Export protocol id to PM dlsetsym v s2,s2,deliver,deliver//Export deliver to PM
dlopen s4,s2//Initialize PM
where ProtId and deliver are direct references into the type and value heaps, respectively,in the module implementing the OS.
For example,considering the example above of assigning the ProtId and deliver?elds of a protocol module,assume that the protocol module has type: import type ProtId::ProtId
import val deliver::deliver:?[EnvT]{a0:ProtId,...}
export type Conn::Conn
export val open::open:?[EnvT]{a0:String,...}
Then setting the ProtId?eld with the ProtId type de?ned in the OS module results in a module with type:
export type ProtId1::ProtId
import val deliver::deliver:?[EnvT]{a0:ProtId1,...}
export type Conn::Conn
export val open::open:?[EnvT]{a0:String,...}
sharing type ProtId1～=ProtId
In this case the internal type name ProtId1is a renaming of the internal name for the type of protocol identi?ers,so as to avoid a name clash with the internal type name ProdId in the OS module.If the OS module has a value heap label deliver with type
?[EnvT]{a0:ProtId,...}
then the type sharing constraint allows this type to be equated with the type of the deliver heap label in the protocol module.This allows the dlsetsym v instruction to be used to assign this value?eld.
8Dynamic Loading
The?nal set of instructions are used to attach run-time type information to a DLL.This type information is used in a run-time type check,to ensure that a DLL that is loaded from disk or from the network has the required module type. There is an instruction dldynamic for bundling a value with a type description, and another instruction dlload for checking that a DLL has a speci?ed type.
Operation TMAL
Construct DLL dldynamic r,v,OT
Extract module dlload r m,r1,r2,OT
104 D.Duggan
The type expression denotes the type of a DLL.The dldynamic instruc-tion associates a type descriptor OT with the heap address of a module in a DLL value w,OT ,of DLL type.To be completely accurate,object?les should be stripped of unnecessary type information before run-time.Then the only places where type information is required are(a)the external labels of import and ex-port lists(since these labels are used by various instructions to look up?elds in modules and symbol tables,and(b)in the dldynamic and dlload instructions above,and DLL values.We forgoe specifying this type-erasure semantics for lack of space.
The dlload instruction extracts a module from a DLL.This instruction also requires the value representation of a module type,the type that is expected of the module in the DLL.The instruction performs a run-time interface contain-ment check,and if this succeeds it coerces the module in the DLL to the required type.If the interface check fails,control transfers to the failure continuation in register r2.
The interface check includes a check for entailment of type sharing con-straints.The simple form of type sharing constraints,only relating type iden-ti?ers,and the fact that the bindings in the type heap are opaque,facilitate this entailment check.The fact that type heap bindings are opaque also has the bene?t that the dynamic type check cannot violate encapsulation of abstract types;this is explained in more detail in[12].
9Related Work
There has been a great deal of work on the semantics of module interconnection languages,particularly in the context of the ML module system[16,15,18,19, 33].The notion of separating external and internal?eld names,with the latter allowing renaming to avoid name clashes,originated with Harper and Lillibridge [15].A related idea is used by Riecke and Stone to allow?elds of an object to be made private,and the object then extended with a?eld with the same external name.Similar notions of internal and external names appear in the module calculi of Ancona and Zucca[4]and Wells and Vestergaard[38].
Cardelli[7]gives a semantics for Unix-style linking in terms of a simpleλ-calculus,ensuring that all symbols in a program are resolved before it is executed. Flatt and Felleisen[13]and Glew and Morrisett[14]extend this work to consider typed module contents and circular import dependencies.It is not clear what the type of a module is in these approaches(linking simply resolves imports against exports in a type-safe way).Glew and Morrisett do not support shared libraries(type sharing)or dynamic linking.Flatt and Felleisen allow dynamic linking of units.However the invoke operation for initializing a unit returns a single core language value;there is no other way for a program to access the contents of a unit.The invoke operation takes as arguments types and values from the running program that can be provided as imports to a library before initialization.So there are really two linking operations with units:the linking operation for merging units and the more limited linking that is implicitly part of
先教大家一些基础知识,学习破解其实是要和程序打交道的,汇编是破解程序的必备知识,但有可能部分朋友都没有学习过汇编语言,所以我就在这里叫大家一些简单实用的破解语句吧! ---------------------------------------------------------------------------------------------------------------- 语句:cmp a,b //cmp是比较的意思!在这里假如a=1,b=2 那么就是a与b比较大小. mov a,b //mov是赋值语句,把b的值赋给a. je/jz //就是相等就到指定位置(也叫跳转). jne/jnz //不相等就到指定位置. jmp //无条件跳转. jl/jb //若小于就跳. ja/jg //若大于就跳. jge //若大于等于就跳. 这里以一款LRC傻瓜编辑器为例，讲解一下软件的初步破解过程。大家只要认真看我的操作一定会！假如还是不明白的话提出难点帮你解决，还不行的话直接找我！有时间给你补节课！呵呵！ 目标：LRC傻瓜编辑器杀杀杀~~~~~~~~~ 简介：本软件可以让你听完一首MP3歌曲，便可编辑完成一首LRC歌词。并且本软件自身还带有MP3音乐播放和LRC歌词播放功能，没注册的软件只能使用15天。 工具/原料 我们破解或给软件脱壳最常用的软件就是OD全名叫Ollydbg，界面如图： 它是一个功能很强大的工具,左上角是cpu窗口,分别是地址,机器码,汇编代码,注释;注释添加方便,而且还能即时显示函数的调用结果,返回值. 右上角是寄存器窗口,但不仅仅反映寄存器的状况,还有好多东东;双击即可改变Eflag的值,对于寄存器,指令执行后发生改变的寄存器会用红色突出显示. cpu窗口下面还有一个小窗口,显示当前操作改变的寄存器状态. 左下角是内存窗口.可以ascii或者unicode两种方式显示内存信息. 右下角的是当前堆栈情况,还有注释啊. 步骤/方法 1. 我们要想破解一个软件就是修改它的代码，我们要想在这代码的海洋里找到我们破解关键的代码确实很棘 手，所以我们必须找到一定的线索，一便我们顺藤摸瓜的找到我们想要的东东，现在的关键问题就是什么
----------------<小A分>---------------- 一、概论 壳出于程序作者想对程序资源压缩、注册保护的目的，把壳分为压缩壳和加密壳(强壳)两种 "UPX" "ASPCAK" "TELOCK" "PELITE" "NSPACK(北斗)" ... "ARMADILLO" "ASPROTECT" "ACPROTECT" "EPE(王)" "SVKP" ... 顾名思义，压缩壳只是为了减小程序体积对资源进行压缩，加密壳是程序输入表等等进行加密保护。 当然加密壳的保护能力要强得多！ -----------<小A分割线>------------- 二、工具的认识 OllyDBG ring3 shell层级别的动态编译工具、 PEid、 ImportREC、 LordPE、 softIce ring0级别调试工具 -------------<小A分割>------------------- 三、常见手动脱壳方法 预备知识 1.PUSHAD （入栈/压栈）代表程序的入口点, 2.POPAD （弹栈/出栈）代表程序的出口点，与PUSHAD想对应，一般找到这个OEP就在附近 3.OEP：程序的入口点，软件加壳就是隐藏了OEP（或者用了假的OEP/FOEP），只要我们找到程序真正的OEP，就可以立刻脱壳。 ------------<小A分割线>-------------------- 方法一：单步跟踪法 1.用OD载入，点“不分析代码！” 2.单步向下跟踪F8，实现向下的跳。也就是说向上的跳不让其实现！（通过F4） 3.遇到程序往回跳的（包括循环），我们在下一句代码处按F4（或者右健单击代码，选择断点——>运行到所选） 4.绿色线条表示跳转没实现，不用理会，红色线条表示跳转已经实现！ 5.如果刚载入程序，在附近就有一个CALL的，我们就F7跟进去，不然程序很容易跑飞，这样很快就能到程序的OEP 6.在跟踪的时候，如果运行到某个CALL程序就运行的，就在这个CALL中F7进入 7.一般有很大的跳转（大跨段），比如 jmp XXXXXX 或者 JE XXXXXX 或者有RETN 的一般很快就会到程序的OEP。 近CALL F7 远CALL F8 Btw:在有些壳无法向下跟踪的时候，我们可以在附近找到没有实现的大跳转，右键-->“跟随”,然后F2下断，Shift+F9运行停在“跟随”的位置，再取消断点，
脱壳或去皮的方法 一、脱壳 常用的脱壳有碾搓法、撞击法、剪切法及挤压法外，剥壳方法还有摩擦法。值得注意的是，任何剥壳机往往是一种剥壳方法为主而几种剥壳方法为辅的综合作用的结果。 摩擦法：利用摩擦形成的剪切力使皮壳沿其断裂而产生撕裂破坏，除下的皮壳整齐，便于选除，适用于韧性皮壳。 前述的脱壳法都是利用机械对农作物籽粒产生机械力的作用而实现脱壳的，以下是非机械式的脱壳方法。 能量法：利用籽粒在一个特殊环境中经受一定时间的高温高压作用，使得大量热量或气体聚集于籽粒壳内，并使籽粒内外达到气压平衡，然后让籽粒瞬间脱离高温高压环境，此时，聚集在籽粒壳与仁间的压力瞬时爆破，从而实现脱壳目的。 真空法：利用壳内外产生的压力差进行脱壳。它与能量法脱壳的不同之处在于它不是使气体进入籽粒壳内，而是在一定的范围内，在真空泵的抽吸作用下使壳外压力降低，壳内部处于相对较高压力状态，当压力差达到一定数值时，使外壳爆裂。一般采用单真空源与多个装料爆壳室相结合的配置。 微波爆壳法：利用电磁场的作用力对籽粒进行破壳。当微波作用于需脱壳的籽粒时，籽仁内水分子在交变电磁场的作用下将电磁能转化为热能。这种转变使籽仁在短时间内具有很高的能量，并迅速向外扩散，水分也沿着能量传递的方向迅速外迁，籽仁组织内部的部分结合水分转变为自由水分汽化逸出，导致籽仁失水而收缩。汽化逸出的自由水分以一定的压力作用于外壳，破坏了籽仁与外壳的贴合。同时，外壳在微波的作用下,组织内结合水分减少使纤维组织韧性下降、强度降低。由于籽仁与外壳在微波作用下的变形不一致，导致籽仁与外壳的分离，使脱壳成为可能。 二、去皮 用于去除果蔬表皮的去皮机，按去皮对象可分为： 1.块状根茎类原料去皮机； 2.果蔬去皮机。 除常用的机械去皮和化学去皮还有一些其他方法。 蒸汽加热去皮法：用于马铃薯、胡萝卜等块状茎类作物去皮前表面爆裂处理作业，特别适合外形凹凸不平且不规则的物料去皮。
新手入门学习——脱壳破解练习第一期拿到一个软件，先看看是加的什么壳。用PEiD查得【Upack V0.37-V0.39 -> Dwing *】 接着拿出破解第一要物OD进行脱壳（注意选好点的版本，由于Upack壳做了变形，有些版本的OD打开时会出错，最好是用英文版的） OD载入…… 我使用简单一点的ESP定律。 00401018 > BE B0114000 MOV ESI,脱壳破解.004011B0 0040101D AD LODS DWORD PTR DS:[ESI] 0040101E 50 PUSH EAX 0040101F FF76 34 PUSH DWORD PTR DS:[ESI+34] 00401022 EB 7C JMP SHORT 脱壳破解.004010A0 F8前进到【0040101F】，在寄存器窗口ESP处点右键，在数据窗口跟随【0012FFC0】 如下图：
//数据窗口点右键，下硬件断点。shift+F9运行 0012FFC0 004011B8 脱壳破解.004011B8 0012FFC4 7C82F23B 返回到 kernel32.7C82F23B 0012FFC8 00000000 //来到OEP，通过观察可以发现，这是一个典型的VB入口。这里记得要删除硬件断点！004011B8 68 24184000 PUSH 脱壳破解.00401824 //OEP 004011BD E8 EEFFFFFF CALL 脱壳破解.004011B0 004011C2 0000 ADD BYTE PTR DS:[EAX],AL 004011C4 0000 ADD BYTE PTR DS:[EAX],AL 004011C6 0000 ADD BYTE PTR DS:[EAX],AL 004011C8 3000 XOR BYTE PTR DS:[EAX],AL 记录新入口地址【11B8】
OD 新人入门基础教材 OD 是个好工具但很多新哥们不懂用可惜咯 首先我介绍下 OD正个界面： 各个窗口的功能如上图。简单解释一下各个窗口的功能，更详细的内容可以参考 TT 小组翻译的中文帮助： 反汇编窗口：显示被调试程序的反汇编代码，标题栏上的地址、HEX 数据、反汇编、注释可以通过在窗口中右击出现的菜单界面选项->隐藏标题或显示标题来进行切换是否显示。用鼠标左键点击注释标签可以切换注释显示的方式。 寄存器窗口：显示当前所选线程的 CPU 寄存器内容。同样点击标签寄存器 (FPU) 可以切换显示寄存器的方式。 信息窗口：显示反汇编窗口中选中的第一个命令的参数及一些跳转目标地址、字串等。 数据窗口：显示内存或文件的内容。右键菜单可用于切换显示方式。 堆栈窗口：显示当前线程的堆栈。
要调整上面各个窗口的大小的话，只需左键按住边框拖动，等调整好了，重新启动一下 OllyDBG 就可以生效了。 启动后我们要把插件及 UDD 的目录配置为绝对路径，点击菜单上的选项->界面，将会出来一个界面选项的对话框，我们点击其中的目录标签： 因为我这里是把 OllyDBG 解压在 F:\OllyDBG 目录下，所以相应的 UDD 目录及插件目录按图上配置。还有一个常用到的标签就是上图后面那个字体，在这里你可以更改 OllyDBG 中显示的字体。上图中其它的选项可以保留为默认，若有需要也可以自己修改。修改完以后点击确定，弹出一个对话框，说我们更改了插件路径，要重新启动 OllyDBG。在这个对话框上点确定，重新启动一下 OllyDBG，我们再到界面选项中看一下，会发现我们原先设置好的路径都已保存了。有人可能知道插件的作用，但对那个 UDD 目录不清楚。我这简单解释一下：这个 UDD 目录的作用是保存你调试的工作。比如你调试一个软件，设置了断点，添加了注释，一次没做完，这时 OllyDBG 就会把你所做的工作保存到这个 UDD 目录，以便你下次调试时可以继续以前的工作。如果不设置这个 UDD 目录，OllyDBG 默认是在其安装目录下保存这些后缀名为 udd 的文件，时间长了就会显的很乱，所以还是建议专门设置一个目录来保存这些文件。 另外一个重要的选项就是调试选项，可通过菜单选项->调试设置来配置：
一、概论 壳出于程序作者想对程序资源压缩、注册保护的目的，把壳分为压缩壳和加密壳两种 UPX ASPCAK TELOCK PELITE NSPACK ... ARMADILLO ASPROTECT ACPROTECT EPE SVKP ... 顾名思义，压缩壳只是为了减小程序体积对资源进行压缩，加密壳是程序输入表等等进行加密保护。当然加密壳的保护能力要强得多！ 二、常见脱壳方法 预备知识 1.PUSHAD （压栈）代表程序的入口点, 2.POPAD （出栈）代表程序的出口点，与PUSHAD想对应，一般找到这个OEP就在附近 3.OEP：程序的入口点，软件加壳就是隐藏了OEP（或者用了假的OEP/FOEP），只要我们找到程序真正的OEP，就可以立刻脱壳。 方法一：单步跟踪法 1.用OD载入，点“不分析代码！” 2.单步向下跟踪F8，实现向下的跳。也就是说向上的跳不让其实现！（通过F4） 3.遇到程序往回跳的（包括循环），我们在下一句代码处按F4（或者右健单击代码，选择断点——>运行到所选） 4.绿色线条表示跳转没实现，不用理会，红色线条表示跳转已经实现！ 5.如果刚载入程序，在附近就有一个CALL的，我们就F7跟进去，不然程序很容易跑飞，这样很快就能到程序的OEP 6.在跟踪的时候，如果运行到某个CALL程序就运行的，就在这个CALL中F7进入 7.一般有很大的跳转（大跨段），比如jmp XXXXXX 或者JE XXXXXX 或者有RETN的一般很快就会到程序的OEP。 在有些壳无法向下跟踪的时候，我们可以在附近找到没有实现的大跳转，右键-->“跟随”,然后F2下断，Shift+F9运行停在“跟随”的位置，再取消断点，继续F8单步跟踪。一般情况下可以轻松到达OEP！ 方法二：ESP定律法 ESP定理脱壳（ESP在OD的寄存器中，我们只要在命令行下ESP的硬件访问断点，就会一下来到程序的OEP了！） 1.开始就点F8，注意观察OD右上角的寄存器中ESP有没突现（变成红色）。（这只是一般情况下，更确切的说我们选择的ESP值是关键句之后的第一个ESP值） 2.在命令行下：dd XXXXXXXX(指在当前代码中的ESP地址，或者是hr XXXXXXXX)，按回车！ 3.选中下断的地址，断点--->硬件访--->WORD断点。 4.按一下F9运行程序，直接来到了跳转处，按下F8，到达程序OEP。 方法三：内存镜像法
第一部分基础知识及运用 知识点1 语音 【教学目标】 1．依据教学大纲，了解《考试说明》对此项考查的要求。 2．通过分析高考试题，寻求规律，掌握考查的重点。 3．加强备考方法的指导，强化基础训练。 【教学方法】 讲练结合，注重积累。 【教学重点难点】 重点：复习方法指导； 强化语音识记。 难点：学习态度； 习惯性误读字和生僻字的识记。 【课时安排】 六课时。其中知识点1语音以及知识点精练的讲解需要二课时；知识清单“容易读错的字”讲解需要二个课时；同步检测语音部分考试及讲解二课时。 【教学过程和步骤】 一、导入 对口高考语文复习方法 （一）分析学生现状 语文基础不是很好；要做好打持久战的准备。 （二）语文复习方法 1．语文复习要注重教材，重点是教材中的字词和应用文写作； 2．语文知识要及时去记、去背；及时扫除知识障碍； 3．语文知识重在积累，重在坚持不懈，持之以恒； 4．多做题目，特别是阅读题，要勤于动笔； 5．提纲挈领，总体把握每一个知识点的内容。 二、讲解新课 （一）本知识点包括以下几方面的内容 考纲解读；知识点精讲（例题解析——高考真题；方法指导）；知识点精练。 （二）讲析新课 1．复习定向 所谓“识记”，就是识别和记忆。识记的对象是“现代汉语普通话的字音”。普通话是中华民族的母语，正确“识记现代汉语普通话的字音”，是考生必须具备的能力。 我国自1977年恢复高考以来，语音题一直是高考必考题型。1996年后语音题所考内容及题型开始趋于稳定，要求相当明确，即只考“识记现代汉语普通话的字音”。 2．指导学生阅读“知识点1语音”（复习用书P1——4页） （1）学生看并做高考语音题。 （2）寻找高考总趋向：近年来高考对语音的考查，难度有所降低，据统计，1996年语音题考12字，超出常用字的5个，1997年超出4个，1998年和2001年、2002年全部是常
脱壳找OEP7种基本方法 七种找OEP的方法 OD手动脱壳的7种法则 方法一：单步跟踪法 1.用OD载入，点“不分析代码！” 2.单步向下跟踪F8，实现向下的跳。也就是说向上的跳不让其实现！（通过F4） 3.遇到程序往回跳的（包括循环），我们在下一句代码处按F4（或者右健单击代码，选择断点——>运行到所选） 4.绿色线条表示跳转没实现，不用理会，红色线条表示跳转已经实现！ 5.如果刚载入程序，在附近就有一个CALL的，我们就F7跟进去，不然程序很容易跑飞，这样很快就能到程序的OEP 6.在跟踪的时候，如果运行到某个CALL程序就运行的，就在这个CALL中F7进入 7.一般有很大的跳转（大跨段），比如jmp XXXXXX 或者JE XXXXXX 或者有RETN 的一般很快就会到程序的OEP。 PS:在有些壳无法向下跟踪的时候，我们可以在附近找到没有实现的大跳转，右键-->“跟随”,然后F2下断，Shift+F9运行停在“跟随”的位置，再取消断点，继续F8单步跟踪。一般情况下可以轻松到达OEP！ 方法二：ESP定律法 ESP定理脱壳（ESP在OD的寄存器中，我们只要在命令行下ESP的硬件访问断点，就会一下来到程序的OEP了！） 1.开始就点F8，注意观察OD右上角的寄存器中ESP有没突变成红色。（这只是一般情况下，更确切的说我们选择的ESP值是关键句之后的第一个ESP值） 2.在命令行下：dd XXXXXXXX(指在当前代码中的ESP地址，或者是hr XXXXXXXX)，按回车！ 3.选中下断的地址，断点--->硬件访--->WORD断点。 4.按一下F9运行程序，直接来到了跳转处，按下F8，到达程序OEP。 方法三：内存镜像法 1：用OD打开软件！ 2：点击选项——调试选项——异常，把里面的忽略全部√上！CTRL+F2重载下程序！ 3：按ALT+M,打开内存镜象，找到程序的第一个.rsrc.按F2下断点，然后按SHIFT+F9运行到断点，接着再按ALT+M,打开内存镜象，找到程序的第一个.rsrc.上面的.CODE（也就是00401000处），按F2下断点！然后按SHIFT+F9（或者是在没异常情况下按F9），直接到达程序OEP！ 方法四：一步到达OEP 1.开始按Ctrl+F,输入：popad（只适合少数壳，包括UPX，ASPACK壳），然后按下F2，F9运行到此处 2.来到大跳转处，点下F8，到达OEP！
小学六年级语文基础知识总复习练习（答案）（一）字、词一．改正下列成语中的错别字。 直接了当（截）焕然一新（焕）道貌暗然（岸）既往不究（咎） 别出心栽（裁）礼上往来（尚）难以名壮（状）色厉内茬（荏） 如火如茶（荼）因地治宜（制）推心至腹（置）纷至踏来（沓） 原形必露（毕）谈笑风声（生）委屈求全（曲）金壁辉煌（碧） 二．直写出下面代称的含义 “杏林”指医生“桃李”指学生（指自己所教的学生）“手足”指弟兄 “汗青”指史册“杜康”指美酒“红豆”指相思 三．巧填成语。 １.填叠词。 威风凛凛忠心耿耿风尘仆仆千里迢迢衣冠楚楚大名鼎鼎文质彬彬人才济济 ２．填恰当的字。 一贫如洗视死如归对答如流倒背如流巧舌如簧度日如年心急如焚守口如瓶胆小如鼠心细如尘 ３.填上表示动物名称的字，组成成语。 亡（羊）补牢飞（蛾）扑火（牛）刀小试童颜（鹤）发 金（蝉）脱壳门可罗（雀）（马）到成功浑水摸（鱼） ４．填上与人体有关的字，组成成语。 尖（嘴）猴（腮）（皮）开（肉）绽（唇）枪（舌）剑劈（头）盖（脸） （肝）（胆）相照扬（眉）吐气（趾）高气扬千钧一（发） ５．填颜色，组成语。 （银）装素裹（绿）树成荫万古长（青）（紫）气东来灯（红）酒（绿）半（青）半（黄） 面（红）耳（赤）姹（紫）嫣（红）（青）山（绿）水（白）纸（黑）字（青）（黄）不接 （黑）（白）分明 ６.“然＂字组合。 （潸）然泪下（勃）然大怒（油）然而生（轩）然大波（庞）然大物（泰）然处之 （寂）然无声（愤）然不顾（截）然不同（蔚）然成风 ７.在下面括号内填上一个数，组成成语，并使各等式成立。 （一）步登天＋（八）面玲珑﹦（九）霄云外（一）触即发＋（六）亲不认﹦（七）窍生烟 （五）体投地－（一）毛不拔﹦（四）通八达（五）花（八）门－（两）面（三）刀﹦（三）令（五）申四.补充句子 失之毫厘，谬之千里得道多助，失道寡助前人栽树，后人乘凉兼听则明，偏听则暗 人无远虑，必有近忧近朱者赤，近墨者黑乘兴而来，败兴而归远在天边，近在眼前 不鸣则已，一鸣惊人一着不慎，满盘皆输不以为耻，反以为荣己所不欲，勿施于人五．下面是广告中运用的成语，你能写出正确的成语吗？ 百衣百顺（百依百顺）闲妻良母(贤妻良母)默默无蚊（默默无闻）乐在骑中（乐在其中） 语过添情（雨过天晴）牙口无炎（哑口无言）无胃不至（无微不至）食全食美（十全十美） 天尝地酒（天长地久）饮以为荣（引以为荣）触幕惊新（触目惊心）诗情花艺（诗情画意） 六.成语对对子。（注意对仗要工整，意思要相对）。 例：粗茶淡饭（山珍海味）流芳百世（遗臭万年）井然有序（杂乱无章）指鹿为马（循名责实）固若金汤（危如累卵）精雕细刻（粗制滥造）雪中送炭（锦上添花）伶牙俐齿（笨嘴拙舌）七．下面人名各取自什么成语？ 杜鹏程（鹏程万里）魏建功（建功立业）王任重（任重道远）刘海粟（沧海一粟）丁慧中（秀外慧中）陶成章（出口成章）焦若愚（大智若愚）刘青云（青云直上）沈致远（宁静致远） 八.成语之最。 1.最贵重的东西（价值连城） 2.最近的距离（近在咫尺） 3.最激烈的竞争（龙争虎斗） 4.最快的阅读（一目十行） 5.最高超的医术（妙手回春） 6.最快的速度（一日千里） 7.最紧急的情况（十万火急）8.最好的记忆（过目成诵）9.最深刻的见解（入木三分） 10最大的嘴巴（气吞山河）11.最诚恳的道歉（负荆请罪）12.最小的地方（方寸之地）
咖啡交流 一．咖啡的栽培传播历史 自古以来，咖啡多产于南北回归线之间，巴西，哥伦比亚和印尼咖啡产量高居全球第一，第二，第三。而两百年前这三个国家一棵咖啡树也没有。那咖啡树栽培是如何传播开的呢？ 咖啡树原产于非洲东岸的衣索比亚高地。西元525年，衣索比亚人攻占叶门并统治了50年，因此把咖啡豆引进叶门，回教徒发觉咖啡豆具提神妙用，想尽办法垄断市场，严禁生咖啡豆出口。 垄断两百年后，1600年，印度一名虔诚的回教徒巴巴布丹前往麦加朝圣，迷上咖啡，偷偷把叶门的七颗生咖啡豆贴在肚皮上，走私生豆出境成功，种植于印度的甘卓吉力山。 1616年，荷兰人从叶门移植一株咖啡树到阿姆斯特丹试种失败。因为气候寒冷，经此教训，荷兰人1658年把树苗移往较温暖的锡兰，1699年又在爪哇试种成功。 法国人看到荷兰人试种咖啡成功，分外眼红，首先移植印度咖啡树苗到法国南部试种，下霜冻死。1714年，阿姆斯特丹市长赠送给法王路易十四一株咖啡树，路易十四如获至宝，为这株小树盖了一座暖房。1718年，法国人将巴黎暖房培育的树苗移植到非洲东部的波旁岛结出的咖啡豆更小，因此被取名为波旁种，再移回巴黎暖房。法国爱国军官狄克鲁认为法国也可拥有自己的咖啡农庄，请当局送他一棵树苗由他护送到加勒比海的属地栽培，遭到王室拒绝。狄克鲁不死心，趁着夜黑风高，潜进暖房偷走一棵树苗，狄克鲁费尽千辛万苦，终将咖啡树苗栽培成功，种咖啡的厚利也传遍加勒比海和中南美洲地区，海地，古巴，牙买加的地马拉，哥伦比亚和巴西相继投入咖啡树栽培业。 值得一提的是，法国在东非外海波旁岛试种的咖啡辗转传到肯亚，坦桑尼亚，巴西和夏威夷康纳岛，有趣的是肯亚就位于阿拉比卡咖啡原产地衣索比亚的南粼。一直到1900年才由英国传教士从波旁岛引进，也就是说咖啡绕地球一大圈，又回到非洲。
修改病句复习指导 1、掌握一些常见的病句的类型; 2、能指出句子中的毛病,并加以改正; 3、能正确地使用修改符号修改句子。 常见的病句种类有:(l)成分残缺词序颠倒;(2)前后矛盾;(3);(4)指代不明;(5)标点误用;(6)关联词用错;(7)重复啰嗦;(8)搭配不当;(9)归类有误;(10)不符合事实一、成分残缺 例：⑴我们要用实际行动贯彻推广普通话的号召。 ⑵在文娱晚会上表演了精彩的节目。 ⑶这道题最后终于被解答出来了。 ⑷数学作业他都做完了，只剩下最后一道题还没算出得数来。 ⑸星期天，我穿上洁净的衣服，把脏衣服脱下来。 ⑹既然有天大的本领，也不能骄傲。 ⑺大家的眼睛都集中到主席台上。 一、成分缺少这类病句主要有2种类型。 1、句子缺少了主要成份。 ［例1：正在仔细地批改学生的作业。］ ［例2：我们从小讲卫生的好习惯。］ ［例3：校园里到处洋溢着欢乐。］ 2、句子中多了一些词语造成成份残缺。 ［例：经过这次活动，使我受到了深刻的教育。］ 二、用词不当这类病句主要有2种类型。 1、用错了近义词。 ［例：红军长征时期的生活非常艰巨。］ 2、用错了关联词。［例：虽然我们是为人民服务的，但是我们有缺点，就不怕别人批评指出。］ 三、搭配不当这类病句主要有3种类型。 1、句中主要成份不搭配。 ［例：他的写作水平明显改进了。］ 2、修饰限制的词语与中心词不搭配。
［例：农民伯伯在山坡上种了许多欣欣向荣的果树。］ 3、一个词语和两个词语搭配，其中一个搭配，另一个不搭配。 ［例：星期天，我在家里写了一篇文章和一幅图画。］ 四、词序颠倒这类病句主要有3种类型。 1、主动者和被动者颠倒。 ［例：集邮对我特别感兴趣。］ 2、先后发生的几件事颠倒。 ［例：气象小组的同学记录并收听了天气预报。］ 3、修饰限制的词语用错了对象。 ［例：在回家的路上，他唱起心情舒畅的歌。］ 五、重复累赘这类病句主要有3种类型。 1、句子中用了相同意思的几个词语。 ［例：那个房间非常宽敞得很。］ 2、修饰限制的词语与中心词中的字意思重复。 ［例：松树屹立在陡峭的险峰上。］ 3、句子中用了没有必要用的词语。 ［例：那个三条边的三角形画好了。］ 六、指代不明代词分为人称代词［我、你、他（她、它）、我们……］，指示代词［这、那、这里、那儿……］和疑问代词［谁、哪里］三种，指代不明的病句指的是代词使用错误。这类病句主要有2种类型。 1、一个代词同时代替几个人或物，造成指代混乱。 ［例：刘明和陈庆是好朋友，他经常约他去打球。］ 2、指示代词和疑问代词误用。 ［例：哪里有困难，他就出现在那里。］ 七、前后矛盾这类病句主要有2 种类型。 1 、句子的主要意思前后矛盾。 [例:这个养猪场养的猪不少于500 头左右。]
基础知识步骤八【J】 一、多音字： 几其奇 ①jī茶几、窗明几净、几率①jī郦食其[Lì Yìjī人名] ①jī奇数 ②jǐ几时②qí其间②qí奇装异服 稽诘亟 ①jī稽考、稽查、有案可稽①jí诘屈聱牙①jí亟待 ②qǐ稽首②jié诘难．[nàn] ②qì亟[屡次]来问讯．[xùn]革荠济假 ①jí病危急①jì荠菜①jǐ人才济济①jiǎ假意 ②gé革命②qí荸．[bí]荠②jì无济于事、缓不济急②jià假日 间浅监 ①jiān间冰期、间不容发、间距①jiān浅浅流水①jiān监视 ②jiàn亲密无间、间隔、反间计、间断②qiǎn浅陋②jiàn监生 渐犍见 ①jiān渐染、东渐于海①jiān犍牛①jiàn见笑 ②jiàn渐次②qián犍为[地名] ②xiàn图穷匕首见强将嚼 ①jiàng 倔强、强嘴①jiāng将息①jiáo嚼舌 ②qiáng强弩之末、强横．[hèng] ②jiàng将士②jiào倒嚼[反刍] ③qiǎng勉强、强词夺理、强求③qiāng将进酒③jué咀嚼、过屠门而大嚼浆教角槛 ①jiāng浆果①jiāo教书①jiǎo角度①jiàn栏杆或槛车 ②jiàng浆糊②jiào 教诲．[huì] ②jué角斗、口角、角逐②kǎn门槛 缴校节 ①jiǎo缴获①jiào校场、校订①jiē节骨眼 ②zhuó系在箭上的丝绳，射鸟用②xiào校舍②jié节奏 结桔解禁 ①jiē结了果、结巴①jié桔梗①jiě解嘲、解甲归田①jīn情不自禁 ②jié结果、结账②jú桔子②jiè押解、解差、解元②jìn禁止 ③xiè浑身解数
仅尽劲 ①jǐn不仅、仅仅①jǐn尽早、尽快①jìn劲头、干劲 ②jìn [将近] ②jìn尽力、尽如人意②jìng劲爆、劲歌、劲舞、劲射 靓据趄 ①jìng靓妆①jū拮据①jū趑趄[行走困难或犹豫] ②liàng靓丽②jù据说②qiè趔．[liè]趄 圈卷隽 ①juān把鸡圈起来①juǎn卷曲①juàn隽永、隽语 ②juàn圈养、猪圈②juàn手不释卷②jùn隽秀[同“俊”] ③quān圈子 噱倔龟 ①jué可发一噱①jué倔强①jūn龟裂[皲裂] ②xué噱头②juè倔头倔脑②guī乌龟 ③qiū龟兹 期 ①jī期年 ②qī期颐[100岁] 二、重点字音： 解[jiě]甲归田 解[jiè]元[明清两代乡试第一名] 浑身解[xiè]数 解铃还须系[xì]铃人 感慨系[xì]之 可发一噱[jué] 噱[xué]头 戏谑[xuè] 龟[jūn]裂 皲[jūn]裂 皴[cūn]裂 讥诮[qiào] 积重[zhòng]难返 及笄[jíjī] 赍[jī]志而没 犄[jī]角 通缉[jī] 缉[jī]拿 编辑[jí] 辑[jí]录 畸[jī]形 跻[jī]身 箕踞[jījù] 齑[jī]粉 京畿[jī] 岌岌[jí]可危 诘[jí]屈聱[áo]牙 荆棘[jí] 舟楫[jí] 挤轧[yà] 脊[jǐ]梁 脊髓[jǐsuǐ] 掎[jǐ]角之势 刀戟[jǐ] 伎俩[jìliǎng] 觊觎[jìyú] 偈[jì]语 寄寓[yù] 雪霁[jì] 鲫[jì]鱼 发髻[jì] 后稷[jì] 文件夹[jiā] 夹[jiā]层 夹[jiā]带 夹[jiā]克 汗流浃[jiā]背 家给[jǐ]人足 豆荚[jiá] 戛[jiá]然而止 脸颊[jiá] 甲胄[zhòu] 岬[jiǎ]角 肩胛[jiǎ] 驾驭[yù] 稼穑[jiàsè] 奸宄[guǐ坏人] 奸佞[nìng] 信笺[jiān]
小学六年级语文基础知识总复习练习（一）（答案）（一）字、词一．改正下列成语中的错别字。 直接了当（截）焕然一新（焕）道貌暗然（岸）既往不究（咎） 别出心栽（裁）礼上往来（尚）难以名壮（状）色厉内茬（荏） 如火如茶（荼）因地治宜（制）推心至腹（置）纷至踏来（沓） 原形必露（毕）谈笑风声（生）委屈求全（曲）金壁辉煌（碧） 二．直写出下面代称的含义 “杏林”指医生“桃李”指学生（指自己所教的学生）“手足”指弟兄 “汗青”指史册“杜康”指美酒“红豆”指相思 三．巧填成语。 １.填叠词。 威风凛凛忠心耿耿风尘仆仆千里迢迢衣冠楚楚大名鼎鼎文质彬彬人才济济 ２．填恰当的字。 一贫如洗视死如归对答如流倒背如流巧舌如簧度日如年心急如焚守口如瓶胆小如鼠心细如尘 ３.填上表示动物名称的字，组成成语。 亡（羊）补牢飞（蛾）扑火（牛）刀小试童颜（鹤）发
金（蝉）脱壳门可罗（雀）（马）到成功浑水摸（鱼） ４．填上与人体有关的字，组成成语。 尖（嘴）猴（腮）（皮）开（肉）绽（唇）枪（舌）剑劈（头）盖（脸） （肝）（胆）相照扬（眉）吐气（趾）高气扬千钧一（发）５．填颜色，组成语。 （银）装素裹（绿）树成荫万古长（青）（紫）气东来灯（红）酒（绿）半（青）半（黄） 面（红）耳（赤）姹（紫）嫣（红）（青）山（绿）水（白）纸（黑）字（青）（黄）不接 （黑）（白）分明 ６.“然＂字组合。 （潸）然泪下（勃）然大怒（油）然而生（轩）然大波（庞）然大物（泰）然处之 （寂）然无声（愤）然不顾（截）然不同（蔚）然成风 ７.在下面括号内填上一个数，组成成语，并使各等式成立。 （一）步登天＋（八）面玲珑﹦（九）霄云外（一）触即发＋（六）亲不认﹦（七）窍生烟 （五）体投地－（一）毛不拔﹦（四）通八达（五）花（八）门－（两）面（三）刀﹦（三）令（五）申
壳的工作原理及手动脱壳的方法) 1)Entry Point(入口点) PE格式的可执行文件的执行时的入口点，即是PE格式中的Entry Point。 用PEditor或者LordPE之类的PE查看工具看看NotePad.exe，你就会看到Entry Point的值。也就是说NotePad.exe在执行时的第一行代码的地址应该就是这个值。（当然应该加上基地址）2)Section(节区) PE格式文件是按节区进行规划组织的，不同的节区一般保存的数据的作用也不相同。通常使用缺省方式编译的程序文件，有CODE/DATA/TLS/.text/.data/.tls/.rsrc/.rdata/.edata/.reloc 等不同的名称，有的用于保存程序代码，如CODE和.text节区，有的用于保存程序中的变量的， 如DATA/.data节区，有的保存重定位信息，如.reloc，有的用于保存资源数据，如.rsrc。等 等等等，当然这是缺省情况下编译器产生的结构。 而节区名称和节区中的数据其实没有必然的联系，节区中保存的数据也没有什么硬性的限制。所 以你可以在编译时用开关参数改变这些情况。 3)ImageBase(基地址) 不仅程序文件按节区规划，而且程序文件在运行时Windows系统也是按节区加载的。那么每一 块的节区的顺序如何？起始的地址是什么呢？ 这就由基地址决定。在程序的文件头部保存了每个节区的描述信息，比如有前面提到的节区名称，还有节区的大小，以及节区的相对虚拟地址(RVA)。 如果我们把节区的相对虚拟地址(RVA)加上基地址(ImageBase)就可以知道节区在内存中的虚拟地址(VA)了。Windows系统就是按照这个要求来加载各个节区的。这样Windows系统依次把各个节区放到了它相应的虚拟地址空间。 所以如果我们把相对虚拟地址（RVA)看成是坐标的偏移量的话，那么ImageBase就是原点了。有了这个原点，一切都简单了。 好了有了简要的介绍，我们来看看壳的加载过程吧。注意这里说的是一般情况，不特指某个壳，如果那样的话，我想那大概是洋洋洒洒几万字的了，好象我没有写过这么长的。虽然我的五笔练得还不错。 1)获取壳自己所需要使用的API地址
小学语文常识 1、中国历史朝代顺序：夏商、西周、东周、春秋、战国、秦、汉、三国、晋、南北朝、隋、唐、宋、元、明、清 三十六计：2、 第一计瞒天过海第二计围魏救赵第三计借刀杀人 第四计以逸待劳 第五计趁火打劫第六计声东击西第七计无中生有 第八计暗渡陈仓 第九计隔岸观火第十计笑里藏刀第十一计李代桃僵 第十二计顺手牵羊 第十三计打草惊蛇第十四计借尸还魂第十五计调虎离山第十六计欲擒故纵 第十七计抛砖引玉第十八计擒贼擒王第十九计釜底抽薪 第二十计混水摸鱼 第廿一计金蝉脱壳第廿二计关门捉贼第廿三计远交近攻 第廿四计假道代虢 第廿五计偷梁换柱第廿六计指桑骂槐第廿七计假痴不癫 第廿八计上屋抽梯 第廿九计树上开花第三十计反客为主第三十一计美人计第三十二计空城计 第三十三计反间计第三十四计苦肉计第三十五计连环计
第三十六计走为上 3、紧急求助电话电话号码： 火警——119 医疗急救——120 治安报警——110 交通事故——122 查号台——114 3、节日大全： 一月节日元旦[01/01] 二月节日情人节[02/14] 除夕[农历十二月三十] 春节[农历正月初一] 元宵节[农历正月十五] [03/28] 中小学生安全教育日[03/15] 国际消费者日[03/12] 植树节[03/08] 妇女节三月节日． 四月节日愚人节[04/01] 清明节[04/05] 世界卫生日[04/07] 五月节日 5.1劳动节[05/01] 中国青年节[05/04] 国际护士节[05/12] 母亲节[第2个星期天] 六月节日儿童节[06/01] 父亲节[第三个星期日] 端午节(五月初五) 七月节日建党节[07/01] 八月节日“八一”建军节[08/01] 七夕节[七月初七] 九月节日教师节[09/10] 中秋节[农历八月十五] 十月节日国庆节[10/01] 重阳节[农历九月九日] 十一月节日感恩节[11月第4个星期四] 十二月节日冬至节[12月21日] 圣诞节[12/25] 毛泽东诞辰
网络公牛(Netbull) 网络公牛是国产木马，默认连接端口23444。服务端程序newserver.exe运行后，会自动脱壳成checkdll.exe，位于C：WINDOWSSYSTEM下，下次开机checkdll.exe将自动运行，因此很隐蔽、危害很大。同时，服务端运行后会自动捆绑以下文件： win2000下：notepad.exe;regedit.exe，reged32.exe;drwtsn32.exe;winmine.exe。 服务端运行后还会捆绑在开机时自动运行的第三方软件(如：realplay.exe、QQ、ICQ等)上，在注册表中网络公牛也悄悄地扎下了根。 网络公牛采用的是文件捆绑功能，和上面所列出的文件捆绑在一块，要清除非常困难。这样做也有个缺点：容易暴露自己!只要是稍微有经验的用户，就会发现文件长度发生了变化，从而怀疑自己中了木马。 清除方法： 1.删除网络公牛的自启动程序C：WINDOWSSYSTEMCheckDll.exe。 2.把网络公牛在注册表中所建立的键值全部删除。 3.检查上面列出的文件，如果发现文件长度发生变化(大约增加了40K左右，可以通过与其它机子上的正常文件比较而知)，就删除它们!然后点击开始;附件;系统工具;系统信息;工具;系统文件检查器，在弹出的对话框中选中从安装软盘提取一个文件(E)，在框中填入要提取的文件(前面你删除的文件)，点确定按钮，然后按屏幕提示将这些文件恢复即可。如果是开机时自动运行的第三方软件如：realplay.exe、QQ、ICQ等被捆绑上了，那就得把这些文件删除，再重新安装。 Netspy(网络精灵) Netspy又名网络精灵，是国产木马，最新版本为3.0，默认连接端口为7306。在该版本中新添加了注册表编辑功能和浏览器监控功能，客户端现在可以不用NetMonitor，通过IE 或Navigate就可以进行远程监控了。服务端程序被执行后，会在C：Windowssystem目录下生成netspy.exe文件。同时在注册表HKEY_LOCAL_MACHINEsoftwaremicrosoftwindowsCurrentVersion Run下建立键值Cwindowssystemnetspy.exe，用于在系统启动时自动加载运行。 清除方法： 1.重新启动机器并在出现Staringwindows提示时，按F5键进入命令行状态。在C：windowssystem目录下输入以下命令：del netspy.exe; 2.进入HKEY_LOCAL_MACHINE
脱壳教程1：认识脱壳 一切从“壳”开始 首先大家应该先明白“壳”的概念。在自然界中，大家对壳这东西应该都不会陌生了，植物用它来保护种子，动物用它来保护身体等等。同样，在一些计算机软件里也有一段专门负责保护软件不被非法修改或反 编译的程序。它们一般都是先于程序运行，拿到控制权，然后完成它们保护软件的任务。就像动植物的壳 一般都是在身体外面一样理所当然（但后来也出现了所谓的“壳中带籽”的壳）。由于这段程序和自然界 的壳在功能上有很多相同的地方，基于命名的规则，大家就把这样的程序称为“壳”了。就像计算机病毒 和自然界的病毒一样，其实都是命名上的方法罢了。 最早提出“壳”这个概念的，据我所知，应该是当年推出脱壳软件 RCOPY 3 的作者熊焰先生。在几 年前的 DOS 时代，“壳”一般都是指磁盘加密软件的段加密程序，可能是那时侯的加密软件还刚起步不久吧，所以大多数的加密软件（加壳软件）所生成的“成品”在“壳”和需要加密的程序之间总有一条比较 明显的“分界线”。有经验的人可以在跟踪软件的运行以后找出这条分界线来，至于这样有什么用这个问题，就不用我多说了。但毕竟在当时，甚至现在这样的人也不是很多，所以当 RCOPY3 这个可以很容易就 找出“分界线”，并可以方便的去掉“壳”的软件推出以后，立即就受到了很多人的注意。老实说，这个 我当年在《电脑》杂志看到广告，在广州电脑城看到标着999元的软件，在当时来说，的确是有很多全新的构思，单内存生成 EXE 可执行文件这项，就应该是世界首创了。但它的思路在程序的表现上我认为还有很多可以改进的地方（虽然后来出现了可以加强其功力的 RO97），这个想法也在后来和作者的面谈中得到了证实。在这以后，同类型的软件想雨后春笋一般冒出来，记得住名字的就有： UNKEY、MSCOPY、UNALL .... 等等，但很多的软件都把磁盘解密当成了主攻方向，忽略了其它方面，当然这也为以后的“密界克星”“解密机器”等软件打下了基础，这另外的分支就不多祥谈了，相信机龄大一点的朋友都应该看过当时的广告了。 解密（脱壳）技术的进步促进、推动了当时的加密（加壳）技术的发展。LOCK95和 BITLOK 等所谓 的“壳中带籽”加密程序纷纷出笼，真是各出奇谋，把小小的软盘也折腾的够辛苦的了。正在国内的加壳 软件和脱壳软件较量得正火红的时候，国外的“壳”类软件早已经发展到像 LZEXE 之类的压缩壳了。这类软件说穿了其实就是一个标准的加壳软件，它把 EXE 文件压缩了以后，再在文件上加上一层在软件被执行的时候自动把文件解压缩的“壳”来达到压缩 EXE 文件的目的。接着，这类软件也越来越多， PKEXE、AINEXE、UCEXE 和后来被很多人认识的 WWPACK 都属于这类软件，但奇怪的是，当时我看不到一个国产的 同类软件。 过了一段时间，可能是国外淘汰了磁盘加密转向使用软件序列号的加密方法吧，保护 EXE 文件不被 动态跟踪和静态反编译就显得非常重要了。所以专门实现这样功能的加壳程序便诞生了。 MESS 、CRACKSTOP、HACKSTOP、TRAP、UPS 等等都是比较有名气的本类软件代表，当然，还有到现在还是数一数二的，由台湾 同胞所写的 FSE 。其实以我的观点来看，这样的软件才能算是正宗的加壳软件。 在以上这些加壳软件的不断升级较劲中，很多软件都把比较“极端”技术用了上去，因为在这个时候DOS 已经可以说是给众高手们玩弄在股掌之间了，什么保护模式、反 SICE 、逆指令等等。相对来说，在 那段时间里发表的很多国外脱壳程序，根本就不能对付这么多的加壳大军，什么 UPC、TEU 等等都纷纷成 为必防的对象，成绩比较理想的就只有 CUP386 了，反观国内，这段时间里也没了这方面的“矛盾斗争”。加壳软件门挥军直捣各处要岗重地，直到在我国遇到了 TR 这个铜墙铁壁以后，才纷纷败下阵来各谋对策，但这已经是一年多以后的事情了。我常想，如果 TR 能早两年“出生”的话，成就肯定比现在大得多，甚
语文基础知识大全
修改病句复习指导 1、掌握一些常见的病句的类型; 2、能指出句子中的毛病,并加以改正; 3、能正确地使用修改符号修改句子。 常见的病句种类有:(l)成分残缺词序颠倒;(2)前后矛盾;(3);(4)指代不明;(5)标点误用;(6)关联词用错;(7)重复啰嗦;(8)搭配不当;(9)归类有误;(10)不符合事实一、成分残缺 例：⑴我们要用实际行动贯彻推广普通话的号召。 ⑵在文娱晚会上表演了精彩的节目。 ⑶这道题最后终于被解答出来了。 ⑷数学作业他都做完了，只剩下最后一道题还没算出得数来。 ⑸星期天，我穿上洁净的衣服，把脏衣服脱下来。 ⑹既然有天大的本领，也不能骄傲。 ⑺大家的眼睛都集中到主席台上。 一、成分缺少这类病句主要有2种类型。 1、句子缺少了主要成份。 ［例1：正在仔细地批改学生的作业。］ ［例2：我们从小讲卫生的好习惯。］ ［例3：校园里到处洋溢着欢乐。］ 2、句子中多了一些词语造成成份残缺。 ［例：经过这次活动，使我受到了深刻的教育。］ 二、用词不当这类病句主要有2种类型。 1、用错了近义词。 ［例：红军长征时期的生活非常艰巨。］ 2、用错了关联词。［例：虽然我们是为人民服务的，但是我们有缺点，就不怕别人批评指出。］ 三、搭配不当这类病句主要有3种类型。 1、句中主要成份不搭配。
［例：他的写作水平明显改进了。］ 2、修饰限制的词语与中心词不搭配。 ［例：农民伯伯在山坡上种了许多欣欣向荣的果树。］ 3、一个词语和两个词语搭配，其中一个搭配，另一个不搭配。 ［例：星期天，我在家里写了一篇文章和一幅图画。］ 四、词序颠倒这类病句主要有3种类型。 1、主动者和被动者颠倒。 ［例：集邮对我特别感兴趣。］ 2、先后发生的几件事颠倒。 ［例：气象小组的同学记录并收听了天气预报。］ 3、修饰限制的词语用错了对象。 ［例：在回家的路上，他唱起心情舒畅的歌。］ 五、重复累赘这类病句主要有3种类型。 1、句子中用了相同意思的几个词语。 ［例：那个房间非常宽敞得很。］ 2、修饰限制的词语与中心词中的字意思重复。 ［例：松树屹立在陡峭的险峰上。］ 3、句子中用了没有必要用的词语。 ［例：那个三条边的三角形画好了。］ 六、指代不明代词分为人称代词［我、你、他（她、它）、我们……］，指示代词［这、那、这里、那儿……］和疑问代词［谁、哪里］三种，指代不明的病句指的是代词使用错误。这类病句主要有2种类型。 1、一个代词同时代替几个人或物，造成指代混乱。 ［例：刘明和陈庆是好朋友，他经常约他去打球。］ 2、指示代词和疑问代词误用。 ［例：哪里有困难，他就出现在那里。］ 七、前后矛盾这类病句主要有 2 种类型。 1 、句子的主要意思前后矛盾。