Cheat Engine

[xmydl]

Hello, there. Thank you for reading this content.
This is basically a question using Cheat Engine debugging a crackme program which uses command prompt/Power Shell/etc. to execute without gui.
I tried dynamically debugging it in IDA and x64dbg. However there are too many obfuscated instructions and functions which made me headache. I found Cheat Engine's Code Filter and Ultimap function is really good analyzing the specific program. However here comes the question.
I dumbly can't find the entry point and the functions I need. It seems not to appear in the disassembly. I don't really know how these programs without gui works in command prompt but I assume it the same as the programs with gui. I tried search instructions in HEX but nothing shows up. How could I debug it in Cheat Engine?

I tried enable DBVM and kernel debugger but it's not the case.
Again, thank you for reading this dumb question and I'd be really grateful if anyone helped me find out the answer.

[LeFiXER]

The crackme is probably packed.

[xmydl]

Oh!! I used DiE & NAUZ File Detector but it shows that it's not packed. Actually what obfuscated is not the main function but the input encoding/decoding algorithm itself.

[++METHOS]

[LeFiXER]

I second ++METHOS. Cheat Engine has its place within a reverse engineer's toolkit though.

Is the crackme .NET? Check with ExeInfoPE to find out more information about the target. Your request itself does not contain much information. You have to assume that people know nothing of what you have, or what steps you have taken. The more information you provide, the better chance of someone being able to help you.

[xmydl]

Thanks!
I in all cases barely use CE for debugging crackmes. But it may be useful to this specific program.
In fact it's just a really simple exe. The source code was written in C++ and using Visual Studio 2017 compiling. What other info may I provide?

[LeFiXER]

Some techniques which have been prevalent in the past are setting breakpoints on API calls that deal with text like GetWindowTextA/W, GetWindowTextLengthA/W. As for finding the OEP, DiE should provide that information. It will only be incorrect if the executable is packed. You can also check the entropy of the executable, because it is possible to spoof the compiler therefore making the target appear unpacked, but is in fact packed.

[xmydl]

Thanks for the information!
Setting breakpoints on API calls is a must-required skill in nowadays software cracking. I tried analyzing some of the modern softwares and all of them encrypted crucial strings such as 'correct' and even 'OK' button's string. It may require setting breakpoint on specific event such as WM_LBUTTONDOWN which is supported by x64dbg. However this is only a simple crackme focusing the encryption of password strings but not other strings. So I assume it wouldn't acquire these sort of skills.
I also checked the entropy. It's around 6 and being 70% possibility of unpacked. Which I considered as more likely unpacked.

What's splendid is that I surprisingly found the reason why I can't find the entry point. When debugging a command-prompt executable, you'll need to choose the exe at first neither in Applications nor in Windows, but in Process. I don't know the specific reason but somehow windows run PowerShell/cmd and the exe seperately.

[LeFiXER]

It's likely because an executable can have many processes. CreateProcess is also an API which is quite often used. Strings are also often built dynamically in modern software rather than being hardcoded in a data section. At least for strings which are considered sensitive.

[++METHOS]

If I recall, the old lena151 tutorials had some information on obfuscation. If the target is packed in any way, you will want to sort that out first, though.

As mentioned, we can only guess about many things without looking at the file(s) ourself.