相关文章推荐
面冷心慈的枕头  ·  Digital Micrograph ...·  9 月前    · 
潇洒的火锅  ·  WPF DataGrid ...·  1 年前    · 
干练的水桶  ·  java.lang.NoSuchMethod ...·  2 年前    · 
强健的烤面包  ·  Python 切片操作 - 掘金·  2 年前    · 
Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

I'm trying to code a exe packer/protector as a way of learning more about assembler, c++, and how PE files work. I've currently got it working so the section containing the EP is XORed with a key and a new section is created that contains my decryption code. Everything works out great except when I try and JMP to the original EP after decryption.

Basically I do this:

DWORD originalEntryPoint = optionalHeader->AddressOfEntryPoint;
// -- snip -- //
    crypted.put(0xE9);
 crypted.write((char*)&orginalEntryPoint, sizeof(DWORD)); 

But instead of it jumping to the entry point, ollydbg shows that this code disassembles to:

00404030   .-E9 00100000    JMP 00405035 ; should be 00401000 =[

and when I try to change it manually in olly the new opcode shows up as

00404030    -E9 CBCFFFFF    JMP crypted.00401000

Where did 0xCBCFFFFF come from? How would I generate that from the C++ side?

To whomever might stumble upon this, there was a similar question over at RE.SE where I provided a very detailed explanation: reverseengineering.stackexchange.com/questions/19459/… – NirIzr Sep 26, 2018 at 19:59

relative E9 jmp encoding is used like this:

CURRENT_RVA: jmp (DESTINATION_RVA - CURRENT_RVA - 5 [sizeof(E9 xx xx xx xx)])

push + ret is the best solution if you have VA address and the image is not relocated

My edit on this answer addressed serious performance problems with push/ret but unfortunately the poster rolled it back. If you care about performance on modern x86, use mov eax, dst / jmp eax instead of unbalancing the return-address predictor with a ret that doesn't match up with a call (agner.org/optimize). And/or see Call an absolute pointer in x86 machine code. mov/jmp costs 1 extra byte vs. push/ret and avoids future branch mispredicts if you ret from the target – Peter Cordes Nov 26, 2019 at 4:30

I think that E9 is an opcode for a relative jump: its operand specifies a relative distance to be jumped, plus or minus from the start of the next instruction.

If you want the operand to specify an absolute address, you would need a different opcode.

Jumps are usually relative. There's an opcode EA for a jump to an absolute far address, and opcodes for jumps to an indirect address (where the operand specifies the memory location wich contains the address to be jumped to). – ChrisW Oct 9, 2009 at 22:17 @baordog The question was, "Where did 0xCBCFFFFF come from?" Anyway apparently the OP understood the answer, and/or was satisfied by EA in the comment. – ChrisW Aug 1, 2016 at 0:38

opcode for absolute indirect jump is FF + 4byte address. This is most often used for jumptables of addresses stored in data.

Absolute addresses do require relocation when not loaded to the expected address, so relative addresses are generally preferred. Code for relative jumps is also 2 bytes smaller.

Intel optimization manual states that the cpu expects call and ret to be used in pairs, so the ret without a call suggested in answer 2 would cause what they call a "performance penalty".

Also, if the code was not loaded to the same address that the compiler assumed, the ret would probably crash the program. It would be safer to calculate a relative address.

@Laie it still makes sense since FF is the opcode and we know the mnemonic is jmp. It could be FF /4 or FF /5 since they are both jump absolute indirect -- one being a near and the other a far jump. But yes, FF 25 aa bb cc dd is how you would observe FF /4 (the more common of the two) in machine code. – Graeme Wicksted Feb 16, 2017 at 19:33 The last paragraph isn't right: push imm32 / ret won't crash, relocating the code won't change the absolute target address that ret jumps to. The problem is performance: unbalancing the return-address stack will make some future returns mispredict. A mov reg,imm32 + 2-byte register-indirect jump is probably your best bet (rather than loading a pointer from memory) if for some reason you can't just encode a jmp rel32 from a known address,. Call an absolute pointer in x86 machine code. – Peter Cordes Apr 27, 2018 at 4:35 @ThomasTempelmann: How to jump to memory location in intel syntax for both x64 and x32 has both, including the machine code, and Call an absolute pointer in x86 machine code is about x86-64, and works for jmp as well as call. Normally mov rax, imm64 / jmp rax is your best bet. (Pick any register you can clobber at this point.) – Peter Cordes Oct 13, 2022 at 4:02

Thanks for contributing an answer to Stack Overflow!

  • Please be sure to answer the question. Provide details and share your research!

But avoid

  • Asking for help, clarification, or responding to other answers.
  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.