Why is this? I located an instruction I want in a loaded program. The instruction looks like this (in Softice):



So, I made my trainer to insert one NOP there, and it didn't work. So, I fire up IDA and I go to check to see if I am in fact NOPing the right address. IDA returns this:



So my question is, what the heck? Where'd my offset go that appeared in Softice? I tried to search the forums but I couldn't quite figure out what to search for...I tried "offsets changing" and "offsets different" but neither worked....

Thanks.

We're not talking Winmine any more huh? It probably means the code has changed after the program is loaded, evidence of decryption perhaps. Is your game not packed? Your IDA disassembly is a bit, er, barren of descriptive information...

Haha, sorry about the lack of descriptive information. But this is so baffling and new to me that I had no idea what else to write! I'm afraid I don't really know what packing is. I have a general idea, but nothing more. What other information can I include to help you help me?

This similar problem confused the hell out of me a while back. Basically one of 2 things is likely occurring.

1. The prog has some self-decryption code. A section of code within the exe has been encoded/enciphered in some way, and once the app has passed some critical point (registration check etc), the code is decrypted. What you see in sice is the "live" code, after the decryption routine has been completed. What you see in the IDA deadlisting is the enciphered code. If you search in this forum, there is an extensive thread started by me about a prog that does exactly this.

2. The prog has obfuscated a jump (not sure of the correct term for this). wdasm is very suceptible to this. In essence, there is a jump to this section of code somewhere else in the exe that changes the first instruction "seen". This is hard to explain in text, but imagine this:

These are some opcodes starting at offset 423a1d:
AB CD EF GH IJ KL

If we place a jmp 423a1d somewhere else in our exe, a disasm prog will see:
AB CD EF GH IJ KL

However, if we then place a jmp 423a1e (except, we do it via an offset, for example ebp+N) in our exe and step through the code as it runs, softice will see:
BC DE FG HI JK

AB is obviously a different opcode to BC, and thus is a different instruction. Therefore you can see how a jump to a single extra byte will *apparently* cause a different opcode/instruction to appear in the live analysis than in the deadlist, at almost the same location.

I hope that's made some kind of sense, it's very easy to demonstrate with an actual exe or a piece of paper. If you are absolutely 100% sure that doing this won't cause problems, you can strategically place a couple of NOP's.

To clarify, somewhere in your code will be a jump to the code block containing in instruction at 423A1D. Let's randomly call this location 423A10, for sake of example. In the deadlist, you WON'T find a jump to 423A10, however if you set a bpm x on this location in sice the breakpoint will trigger because of a jump. What you'll probably find is that a number of bytes immediately PRECEEDING 423A10 will never be called during the app's execution. Thus, if you NOP those bytes (ie: NOP's to 423A10) then reload the deadlist, your disasm prog will be able to correctly interpret it. Note that you shouldn't go NOP'ing everything in sight! Doing this will ONLY work if it's (what I call) an obfuscated jump - if it's a self-decryption block, then it will seriously damage the exe!

I'm sure others will explain better, or poke holes in that explanation. Or you'll post more info and we'll realise it's actually sputnik that's causing the problem. Either way I'm a beginner at this too, so YMMV and good luck

Hmm. That's a little above my head, but I think I get what you're saying. Mostly, anyway ;-).

What other information can I provide for you? I'm very intrigued by this new development, so I want to solve it . I'm attempting to make a trainer for a game...and that DEC EAX instruction is where it decreases the lives counter. I took the code from my previous (successful :-D) trainer for Minesweeper, and modified it to put one NOP at that location (the one I listed in the original post), but it does not work. So maybe there's some other important part that I'm missing.

Keep in mind this is only my second trainer/real ASM project ever!

Thanks.

Mostly though, IDA has mucked up on the start/finish of functions prolly.

Try changing from CODE type to UNKNOWN type and come to your address, then convert to CODE.

If you find your instruction there, most likely IDA has not disassembled correctly (that's one of the reasons why its called INTERACTIVE)



Have Phun

Right. So....how shall I go about doing this?

Looking at your menu options would be a good start. Maybe something which indicates hints of changing "code to unknown" or "data" and then changing it back. It is often useful to RTFM which comes with the program.

Regards,

God forbid I should have to read some documentation ;-).

All right. What I did, and I probably did it wrong, is this: I went to offset 423A1F in IDA, selected "jz" (see my previous posts), pressed d, selected the "db" on the newly created offset 423A1F, pressed c, and this showed up:



The bold line is the result of that c keystroke. Then I also pasted what was at that jump location. This is rather odd. Originally in Softice I found a DEC instruction, and now it appears (to me, I'm a noob, remember?) that it's changed into an ADD instruction?

What's going on here?

(by the way, for the next few days I won't have access to this computer, so I won't be able to test out any other suggestions you guys make until I have access again.)

edit!

I converted the next offset to code from data, and this is what resulted!


Is this finally the location of that pesky DEC instruction? And in the event that it is, what offset should I tell my trainer to NOP?

I don't think your DEC EAX is going to magically appear by twiddling with IDA. What's important are the actual opcodes, you should turn them on by going into Options/General/Disassembly and fill in the Number of Opcode Bytes field to 6 or 8 or something (a + sign will mean an instruction has more bytes not displayed).

Now look for the actual opcode for DEC EAX (48) at that disasm address in IDA. If it isn't there then, again, the code is changed after the program is loaded (decryption, overwriting), a static disassembly won't show this (use OllyDbg). If by chance the opcode 0x48 IS at address 423A1F, then something is either screwy or it might be some SMC (search!) as Silver described. You can do a byte search as well for the Sice opcodes in a hex editor, if they ain't there your IDA disassembly is next to useless.

Yeah...the opcode is not present at that location. Nor is anything else even remotely similar to 0x48, not that it would make much of a difference ;-).

Now the next step is...what? Unpacking it...or something?

edit: though...0x84 is at address 423A1F...could, by some very odd chance, be it?

Okay, here would be my next step. You've located the code you need to change, you've found that the code is different when live than when (the same location is) viewed in the deadlist. Thus the next thing I would do would be to use procdump to dump out the live exe into a deadlist you can analyze.

For sake of argument, as we don't know the code structure, the best way to do this is to set a sice breakpoint at 423A1F (bpm x 423A1F). Make a note of the opcodes from 423A1F onwards (just a couple of bytes is fine). Next, with the EIP on 423A1F, use the sice "a" command to assemble/patch some instructions. Type "jmp eip", hit enter and then escape. You'll see the dec instruction at 423A1F change to the jmp - you've now put your exe in a loop. Control-D out of sice, load procdump and dump the exe (full image) to a file. Once procdump is finished, you'll need to task manager kill the exe task as it's in an infinite loop. Incidentally if you followed this, you've also just learned a very basic principle behind unpacking

Now you have another exe on disk that is exactly the same as what you see in sice. Load your favourite hex editor, and go to the DISK/FILE offset equivalent to 423A1F (note the difference here, you'll need to learn a little about for RVAs etc) - we can't tell you this unless we see the PE headers. At this location you'll see the opcode EB FE (someone correct me if I'm wrong, but off the top of my head EB FE is the opcode for jmp eip). Remember you made a note of the opcodes at 423A1F when you were in sice? Overwrite EB FE with the opcodes you wrote down, and save the exe.

You can now load it into ida etc and analyze it, which is what you wanted to do all along. Bear in mind of course, you can't run this exe you dumped - you can only use it to gain an understanding of the code structure at runtime.

All that said (and I hope it helps), I'm not sure why you want to do this. You've already used sice to find the instruction you need to change, so the on-disk structure of the encrypted/enciphered exe is irrelevant and not worth analyzing. All you need to worry about is making your trainer manipulate the exe image in memory - which, unless I've misunderstood, you already know how to do.

*edit* I just saw your edit, are you saying you can see 0x84 in IDA at 423A1F in the deadlist? In which case................ To save confusion, can you paste about 10 bytes at 423A1F as you see them in sice, and as you see them in IDA in the deadlist?

I haven't done this for some time...a lot of rust. If you look at your two code statements above, you'll see they are only two bytes off. i.e. the 00423A1F - 2 =00423A1D. I'm bothered by the 001B before the Sice code statement, since I'm used to seeing a CS: instead of a 001B. I'm wondering if that is a context problem? Does the 001B correspond to your CS register value? If not, you have to find out why. If you are in a different context, for whatever reason, and the 001B you listed is not the CS register, there's no way the Sice and IDA codes will match.

It's possible that you have inserted too many bytes somewhere and put the two apps out of sync. Does your app even load correctly? I suggest you begin again with a fresh copy of your trainer. Run it and look at the Sice code, then run it through IDA. Be sure to do what Kayaker suggested: turn on the code display in IDA under 'options' so you can see the opcodes listed in IDA.

If you are inserting bytes, try it manually with a hex editor like UEdit first. Take several of the preceding bytes from the Sice code, or successive bytes, and use the UEdit search engine to find those bytes in the trainer exe. You can do the same with IDA, if you can locate the code location you want. IDA has it's own hex listing, if you want to use it. Uedit will let you alter the exact location in the exe. Of course, if the program is packed, you wont find them.

Sometimes the search engine turns up too many values. Try another code phrase in the immediate vicinity of the Sice code area you want to find in the exe. If you get the right one, you can narrow the search down to one or two finds. Change the code in UEdit and save. Then run the trainer.

You can usually tell if a program is packed when you run it through IDA. If it complains of a bad import table as you load the app, you can bet it's a packed program. If there are no errors as you load it into IDA, it's usually a good indication that the app is not packed. That does not mean it doesn't have some self-modifying code, however.

You have to be careful with changing data to code in IDA. Sometimes you'll tell it to convert to code, and the resulting disassembly looks like code, but it is not. It's really hard to tell sometimes, since a lot of programs include data in the code. There are also jump tables and other goodies to confuse the matter.

Through experience, you can pick out areas in the code like NOPs (0x90) and rows of 0xCC's. A 0xCC on it's own is usually a legitimate instruction or bit of data. A lot of times, hitting the first bit after a series of 0x90's, or rows of 0xCC's, and changing them to code, will give you legitimate code. Other times it wont. You can also identify jump tables by identifying correctly the corresponding jump instructions, 0xEB, etc. If you see lots of EB's in close proximity to each other, you can change them to code and they will form a jump table.

I'm trying to say that hitting an area of code in IDA and converting to code does not assure it is code.

Sure.
Softice:


IDA:


WaxfordSqueers:
001B does indeed correspond with my CS register value. As for the rest, what I'm doing is *making* a trainer for a game. So, the NOP (and it's only one) that I insert to the application only does it at runtime, so it's gone the next time I launch the game. And there weren't any errors loading the game into IDA....

Does this code change as you trace through it? For example, after you trace line 001B:423A19 (execute the MOV instruction), is the code still the same at that address, or does it change? I assume after the POP EDI instruction above, there will be a RET statement coming up. If so, check the code before tracing into the RET statement.

The IDA code looks too good to be a fluke. The thing I notice about it is the parameter '208' which is a common offset. i.e. MOV [ESI + 00000208]. That same value shows up in the IDA printout.

It's pretty tough thinking this out without more detail. Even at that, I don't have the expertise to do in-depth analysis.

This is a follow up on your initial question. Something just came out of the fog between my ears. I'm not an expert on the way apps are loaded by the OS, but it seems to me the base address of 400000 is not written in stone. The app is loaded there only if that address is available. I think there is also an option available to the programmer to load at an alternate address, although I'm not sure.

You might check the 400000 address 'after' your app is loaded. If I remember correctly, you should see the MZ header (the DOS stub) at 0x400000, and a little further on, you'll see the PE header. A little study on PE headers, and the way an OS loads them, will make this clearer. It's possible there is an offset between the Sice address and the IDA address. In fact, look at the beginning of the IDA disassembly and see if it starts at 400000.

You are correct in the fact that the programmer/linker can decide the (suggested) imagebase themselves, but for normal executables it will never be the case that this address is "unavailable" or "already taken", as long as it's inside the allowed range. This is because each process has its own virtual memory space in the operating system, with the possibility of using the exact same virtual addresses as any number of other applications at the same time (they will map to different physical addresses though, but that's another story).

The problem you describe can arise for DLL-files though, if some other loaded module of a certain process has already allocated the address range specified in the PE header of a module that loads after it. In this case the operating system will rebase the second module as it sees fit, by help of the relocation info that can be found in DLL files most of the time.

Ok, I held down F8 for a few seconds, and CS stayed at 001B the whole time . And, no, the next instruction after that POP EDI one is:


If it is in fact good code showing up in IDA, what am I doing wrong? What should my next step be?

edit: Quick question: is there a way to copy information from Softice and paste it into, say, this window so that I have an easier way of transferring code fragments while posting on this board?

Hi

Try breaking at the start of program and checking that address to see which instructions are there before the app has had a chance to execute. In theory it should be the IDA disassembly, but could have been overwritten several times by the time you "found" it using Softice.

Can you match up *any* IDA & Sice addresses, say around a recognizable API such as GetStartupInfoA or the first GetModuleHandleA, which should be called early in the code. If you can't find any matches, then the IDA disasm may be offset for some reason as Waxford mentions.

It seems a little unusual for a non-packed app to overwrite a section of code. Perhaps the IDA disasm is only throwaway startup code and for a (large?) game the programmer thought it more efficient to reuse the memory? But then there's the possible global var_208...

All right...don't flame...I looked meticulously through the command reference and attempted a Google search or three...I don't know how to do three things with Softice (and many more, but these are the most important at the moment ;-)):
- Break at the beginning of program execution.
- Finding such "recognizable API" calls as GetStartupInfoA in a running program.
- Jump to a specific code offset. (I have to find the address of the lives variable every time I want to jump to 423A1F, so I can do a bpmb)

Help? *bambi eyes*

Thanks for clarifying that. Is it possible that the PE header could be offset from where it's supposed to be located in the PE header data? For example, if it was supposed to be at 0x4000100 and the start of code was at 0x401000 in the PE header data, is there a way the loaded PE header could be offset from those values?

I'm thinking IDA may read the image file differently than how the OS loads it.

Basically, you use the loader. You'll find it in the Sice directory and it actually has the word 'loader' with it. You should learn how to use the loader anyway, since it's invaluable at times. For example, in your winice.dat file, you are supposed to have certain imports listed to load automatically at startup. With the loader, you can load them after startup. You can also start the app from the loader and tell it where you want it to break...at start of code or at winmain.

There's another way to do it that I haven't used a lot. Actually, there's a small app that will do the same thing. It loads a 0xCC (I think) in place of the first byte of executable code. I'm not sure whether you have to use the loader, or if you can just run the app, but Sice breaks on the 0xCC because it thinks it's a breakpoint. Please check this information for accuracy. At least it will give you something to research and maybe teach you a bit about loading.

Once you've told the loader to begin, it might stop at a strange looking screen that looks like an error happened. Just single-step over the page (<T><Enter> and you'll be at the very first byte of executable code (note: be sure you choose the first byte of executable code as a stopping point and not winmain. They are not the same.). You were joking about hitting F8 over and over and nothing happening. I don't use F8, prefering <T> plus <Enter>. That gives a single step. If you start single stepping at the first instruction after the loader, and if you have the key imports loaded, like kernel32, user32, MFC, etc., you will notice instructions like the one Kayaker mentioned near the beginning of the code.

You don't want to step into these unless you don't mind being dragged through the kernel for long periods of time. (BTW...I haven't tried to reverse in XP and references to kernel32, etc., may no longer apply). Anyway, when you come to an import like StartupInfo, stop immediately before it and hit <P> plus <Enter>. That will jump you right over to the other side of the import's code.

If you happen to get caught in the import code, you can often extricate yourself if you hit F12 immediately. Or you can hit F5 to make the program run. Of course, it will either go to the end of execution or stop at the next break point. At least you can reload and start over at the beginning of code.

On your way in, single-stepping, you'll arrive at Call instructions. You can jump over some of these, and others you can't. I used to make printouts of the code from the first instruction after the loader. I'd try each call instruction to see how many I could jump over. If one of them threw me to the end of execution, I'd just start over. It teaches you a lot about how apps are loaded and initialized. Eventually, you'll reach the function like GetStartUpInfo, that are in English.

Get a good function reference. I used Win32 Programming API Bible for years, but it's aimed at Win 95. After a while, you can tell by the parameters preceding the function exactly what it is trying to do. Also, you get used to the initialization functions and can save yourself loads of tracing time by jumping over them.

What Kayaker is telling you to do, however, is examine the code around the area of GetStartUpInfo, or one of the early imports. It will be in English characters if you have loaded it's import. That function is part of kernel32 or user32, so these have to be loaded in memory. Otherwise the function will not appear in character form, but as a Call to a numerical address.

You can make your reversing a lot easier by making .nms files using IDA. I haven't done this recently, but what it does is give character handles, in English, to functions rather than the numerical values you usually see in MFC code.

Print out a page of the code while you're in Sice, then go looking for the GetStartUpInfo function in IDA. The offsets should match, and the code should be the same. If they are different, check the exact differences in offsets, and that should be transferrable to the code section you are checking.

To jump to a specific code offset, first get into an area of code where you can stop the app. For example, BPX on GetStartUpInfo and run the app. Sice will break just into GetStartUpInfo. F12 over it so you're at the instruction on the other side of it. I think it's the 'g' instruction you use then (it's horrible when you've been away from this for a while). Anyway, at the Sice prompt, you enter g 0041Dxxx, or whatever the address is you want to jump to. It will take you right there in most cases. Of course, if you have breakpoints set in between, it will stop there first. :-)

[QUOTE][Originally Posted by WaxfordSqueers]

I'm answering my own reply to clarify the 'call' functions you will encounter as you trace in. .

As you trace from the start of code, and you hit the 'calls' I've mentioned, you can jump over many of them. If you can't jump over one, it's pretty well telling you to trace into it. Following one of the call functions, you should eventually hit winmain. When the program exits, it will return to the other end of that call you traced into and proceed to an exit.

Before you get to that particular call, however, you should hit a few calls with the name of the import after it. That's what you're looking for.

Not that unusual, I found a shareware app not too long ago that did precisely that...


Yes, it's available by default. In the sice Symbol Loader (IIRC), there is a menu option that displays the sice log - this is essentially everything outputted to the main sice "window".

Last point, not sure whether anyone has mentioned this to you but sice won't break on exe's that don't have the PE section marked as executable. If you pick up any basic unpacking tutorial (such as, manual unpacking UPX), it will explain how to check the executable flag in the PE section header and change it if necessary.

As I said, the main executable module of a process always gets its suggested address in practice, so these should always be displayed with the correct addresses in IDA. Other modules like DLLs are quite likely to get a different imagebase in IDA than during execution inside a process though.

No. Copy and paste are high level Windows functions, Sice is below windows, and windows services are not working, for the most part.

You can print the screen and copy from there, or, I think IceExt has a service that allow you to dump the contents of the screen into a file, or, learn to use the log service in the loader. you can save pieces of disasm code while you trace it.

Consider your self flamed for using animal seduction tactics. . .
If I see a deer looking at me, I reach for my shotgun

Jump to an specific code offset

in Sice type: u 00423A1F ; 'u' means unassemble

or whatever code offset you wish, Sice will display it in the code window.

Be aware that if you type an address that does not corespond to the true begining of an isntruction, the code you will see is wrong. Look up the concept of "code frame" which I think is at the heart of your problem.

Alright nadies it is considerably "unsportsman like" to be hunting deer with a "shotgun". Rifles are the perferred weapon of choice and the only legal one in this country. Although it is always open season on certain newbie questions, with whatever weapon may be at hand.

Regards,

Being a vegetarian, and incurable deer hugger (not to mention sheep...baaaa) I came across, with some amusement, an htm file entitled, "Butchering the Human Carcass for Meat". Now, that's what I call original. Something Hannibal Lecterish about it.

Thanks for all of your replies. I'm going to meticulously read through each of them tomorrow afternoon when I'm free with no work to do and see if I can make any more progress on this elusive problem .

(See? Newbies *can* learn and learn graciously. It's just that so many of them don't take the time to actually think out replies and questions, so they end up turning up like this: "guyz i really want 2 learn 2 crack. can u teech me?????". I'm trying really hard to learn and understand this stuff, and so you'll have to forgive me if I ask really lame and easy questions. But yes, thank you for your time.)