When ever I'm in decode mode in Hiew, and I push F5 to goto a hex code,it says "Jump out of file". It says that with every hex code I type in...Does anyone know what's wrong with it?

hi,

you didn't state the notation using (virtual / raw ?)
check hiew again and C how offsets change switching global/local mode, make clear how are virtual offsets mapped

I take it that you want to jump to a specified address after pushing F5. Do this: Push F5, then hit the period sign button (".", without quotes), then type in the address. Hit enter. This is the normal procedure. But if you have found an address using softice, and if the target is packed, you will still get the message you mentioned. Then you have to unpack the target first...

regards,
hobgoblin

The tools I use are W32DSM89, and Hiew.

Whenever I try to crack a file, I open it using W32DSM and search in string data refrences for the string. I double click on it, and scroll up until I see the first je or jne. I then open up notepad, and type in the @offset code without the @offset or the h at the end. Then I close W32DSM and open Hiew. I search for the file. Then I hit F4 and decode it, then I hit F5, and I typed in the offset code. It said Jump Out of File. So I tried putting the period in front of it. It didn't give me the jump out of file error message, but it didn't move to the code.

Does anyone know the problem?

Aerzan:

Do you know and understand the difference between the addressing mode between W32DSM89 and a hex viewer such as
Hiew? By that I mean do you know the difference between VRA (virtual relative addressing) and Raw or Real (file offset addressing)?

W32DSM89 uses VRA or virtual addressing and most hex viewers use Raw addressing, or location within the file. Virtual addressing is "relative" to the OEP while Raw is a spot within the file on disk. I don't use Hiew, but if you aren't converting the VRA addresses to Raw addresses you can expect that a je to an address such as je 0040125D, and the "40125D" was what you entered, are almost certainly going to get a location which is a "jump out of file." Here's a thread which discusses some of these issues on another problem with W32DSM89
http://www.woodmann.net/forum/showthread.php?threadid=3607&perpage=15&pagenumber=2

Also see this one, where DakienDX discusses this issue:http://www.woodmann.net/forum/showthread.php?threadid=2239&highlight=virtual+address+real+address

He wrote:
{Quote}
You must know that Win32 programs have 'segments', which have a virtual address space where they are loaded into. Your program searches for strings and displays their physical offset. These 'segments' have a virtual size, a virtual address, a physical size and a physical address. Physical means here the place in the file and it's real size. The virtual address is a position in memory where the program is loaded into and the virtual size the memory size the program allocates.

It is nothing unusual that the data from 400h in the original file is loaded into the memory at address 00401000h. So if your program would find a string at 484h in the file, W32Dasm would show it at address 00401084h.

If you go onto a disassembled line in W32Dasm, it should show you the 'virtual' address, but also the corresponding 'physical' address.

All segments are defined in the PE-header. You should search for some information on it and try to understand how it works.
[End Quote]

Aimless then added:
[Quote]

alternatively...

try putting your wdasm green bar on the line which you want to find the address of.

On the left hand side the address you see is the "Virtual Address". that means, as it is in memory

On the STATUS BAR, you will see an address. This is the physical address in the file.
[End Quote]

Do a little more research on these issues and you will probalby find your answer. The status bar, at the bottom, will show you something like "Code Data @00401234 (the address of the je instruction, not the jump address) @Offset 00000634h in file (whatever). From this example the 634h is what you want. If you are using that type of offset already, it is probably packed and needs to be unpacked before the file is big enough for the address to still be "in the file." Can't tell more from you question.
Also remember there is a big difference between "634h" and "634" but I don't know Hiew to know whether it explicitly recognizes a hex number from a decimal one.
Regards.

Thanks for your reply, JML

First off, No, I do not know the difference between VRA and Raw offset addressing. Most tutorials I read simply state to open the file with W32DSM, disassembly it, search for the Registration Unsuccessful text, scroll up and look for the first je or jne you see, write down the offset address, open Hiew, Hit F5 type it in, and then change 75 to 74, or 0F85 To 0F84 or vice versa. Then they state that the program should be cracked. Not one that I read explained anything about VRA or Raw addressing.

I have tried this with many programs, and it proved to be inaffective. Don't criticize my "Newbieness" but I have not cracked one program in all the attemps that I've tried (which is about 10-20).

I have even read tutorials with target programs, and I have not been able to follow them. Most of them that I read, use softice (which I cannot use due to my computer (windows XP)) and the others use programs that I can't find because the tutorials and/or programs are.... (forgive me if I'm being offensive) "outdated".

But I think the real problem is me.

But back to the topic:

I think I found out the problem.

Most tutorials I've read tell me to create a backup copy of the program. So, I right click on whatever.exe, and click create shortcut, and it creates shortcut to whatever.exe. When I'm in Hiew, looking for the program, it lists: whatever.exe, and whatever.lnk.

And I clicked on the backup copy of it to edit it. I'm guessing that that was my mistake. I was supposed to click on the whatever.exe, instead of the whatever.lnk. And I suspect I was getting the "Jump out of file" error message, because the offset code was not located in the .lnk file?

I'm not very good at cracking...in fact, I'm very horrible. but I hope I can learn...someday.

Aerzan

Aerzan:

We all start as newbies with no knowledge and we achieve some knowledge by reading other peoples works and analysis. No matter how much you have read there will always be more to read and more to learn. Don't be too critical of yourself. There are plenty of others who will fulfill that role for you. Even without understanding Virtual and Raw address you went through the steps correctly and it didn't work because you did something differently from what you read in the tut. (made a link file and tried to change that.)

This illustrates something both good and bad about following tuts.They give you a path to follow which leads to a solution. However if the variables change, if that specific version of the software is not available or has been updated, the path might lead nowhere. Second, if you just blindly follow the path, rather than trying to understand the "what" and "why" of what is happening, you aren't actually learning because you really don't understand why it works.

There is a very great amount of material needed to begin to understand how to become a competent reverse code engineer and the more one attempts to shortcut the learning process the less effective one will eventually become. There are certain very basic concepts, like understanding assembly language basic coding and the use of registers and how certain essential API's function that are NECESSARY to have a good grasp of what's happening when you use the tools.

IMPATIENCE is the most difficult issue to overcome. We want to crack program x right now and we don't want to take the time necessary to learn the basics before we jump in, bash it, and can brag to our friends what we've accomplished. It is by the nature of the beast a loooong process and ongoing. Give yourself time to gather the information and keep working and come here when you are stumped. Be proud of the fact that YOU figured out what the problem was, rather than embarassed that you made it in the first place. One of the major ways we learn is by making and discovering our mistakes. Now this is one mistake you wont make again.

By the way, to make a backup copy you want to use the "save as" function and save the "new" copy with a different name you will recognize as your 2nd copy of programx.exe.

Regards.

thanks for your reply. You've been a big help so far.

I am still confused on how to create a backup copy.

Do you simply open the file, then goto save as? This does not work with some programs, such as GMUD. I right click, and I see "run as" but I can't find any Save as, except in editors, such as notepad, wordpad, etc, but I don't think this is the function you were talking about.

Hello JMI !

Hiew takes all numbers without a suffix as hexadecimal numbers and they must start with a digit. You can append a "h" but it doesn matter.
If you want to enter a decimal number, you've to append "t" to the number. (Hiew 6.30+)

Hello Aerzan !

JMI is not talking about a right click on the program in the windows explorer, but about the "Save as" function in Hiew. At least I suppose that.

Simply open a file in Hiew, press [Ctrl]+[Num-*] to mark the whole file and F2 (PutBlock) -> filename and leave the offset empty or put "0" in the field.

If you want to do this in the explorer, drag&drop the file in the same directory with the [Ctrl] button pressed. Then you've a file "Copy of program.exe" you can work with.

Thanks Dakien!

I found the drag&drop + ctrl method a lot easier!

Now I can try to crack programs without the fear of messing them up and having to redownload them

Aerzan

DakienDX and Aerzan:

I was having a little brain freeze from lack of food and was indeed thinking of file editors, rather that explorer and/or wincommander and/or drag & file type programs. DakienDX has beaten me to the correct response and enlightened us on how to use Hiew better.

Regards.