Hello I try to learn reverse engineering, so i use from process hacker to view dynamic strings in the process's memory...
i get something like this :
Address Length Result
-----------------------
0x853978 (43): hello
0xfb5e1a8 (86): hello alex !
now i want to know how can i get/find reference address for them ?
I try with WinHex but i cant, i don't know how can i do this, is it possible to find reference assembly address in file form memory address (for ex : 0x853978) or this is not possible in any way.
anyone can help ?
It's variation of halting problem, so it's impossible, but some imperfect weak heuristic can be done in polynomial time to find common patterns.
If the code writer decided to avoid common patterns of loading the address, for example for obfuscation reasons it may be calculated from polynomial, etc.. it will be practically impossible to find with software tool, so then only disassembling the code and understanding it helps.
But... why you failed with winhex even in non-cryptic case.
You didn't post any info about your platform, so let's guess it's x86-64. Then most of the binaries are PIC, so the code referencing particular data is doing it through relative offset added to the current rip (instruction pointer). Like lea rdx,[rip+1234] ; rdx = address of string "hello" .. and then +1234 bytes beyond this instruction opcode is the first byte 'h'. So creating a tool, which would treat all possible combinations as displacement offsets and adding them to current virtual address may help to find reference to particular spot of binary.
Even if you would know, you are looking for 1234 displacement, the x86 is little-endian, so 32b displacement constant 1234 == 0x4d2 is stored in memory as d2 04 00 00.
But normally in RE some disassembler tool is used to disassemble the code as well, so you can inspect it on your own, and find out how it works, and where it does access particular memory. The disassemblers are not perfect (due to the same reason, as I mentioned at beginning), but the best ones have reasonably tuned heuristics to correctly detect common code and disassemble it in reasonably readable way (although if somebody dares to use some tricks to make it harder for disassembler and add anti-debug measures, you will probably have to get back to the good old paper + pencil and simulate it manually to break through the initial defences to make it debug-able).
This answer sounds probably quite bleak and negative, in reality you will usually meet binaries which are either completely non-tricky, or just poorly obfuscated, and most of the professional disassembler tools will produce reasonable results to just read them as asm source, also debugger should work well with most binaries. Although if that code was produced by high level language compiler, there will be thousands of lines of code, with stripped debug info, so it's good to have experience to pinpoint code where to focus, as you can't go through *all* of it in reasonable time.
edit:
You can also use memory access breakpoint debugging on some platforms, to find out any "live" referencing instruction during runtime. This will not show all of them, unless you force the code to run through all combinations, but if you are interested which code does access it in particular case, this is enough.