View Full Version : Program is checking Input after programs restart
C0d3r-F4N
September 19th, 2015, 06:58
Hello,
first, sorry for my bad english!
Second i've read the FAQ so i think i know the rules... if not, sorry!

Third, i'm a newbie in assembly.
I've a program that check the Input (of a "serial"

after you have restarted the program (to test if the "serial" is ok or not).
In short: Open the program, click "enter Key", put in a "serial", click "Ok" and a message pops up that the program must be restarted.
My problem is, OllyDBG terminated after the program is closed itself - logical.
After it's terminated in Olly i'm at a address which is not important (i think).

But if i breaked (paused) it before it closed itself, the program is in paused-mode.
Now i (really) don't know what i've looking for.

Aimless
September 19th, 2015, 07:21
Hello,
If it's checking the serial at restart, it's holding the serial somewhere... good guesses are:
1) memory
2) file on the computer
3) registry
4) temp area
Your plan of attack is to check out after entering the serial, which of the FINAL above places it stores. Note the word FINAL. It could take your serial, save it in memory, do something with it (or not), THEN save it in the registry (an example). Therefore, find out what is the FINAL status of your serial (modified/unmodified) and where it is FINALLY stored, before the program terminates for a restart.
Then, you can begin your program again and breakpoint in Olly (not that I'd use it - aesthetics, not functionality, of course) at the start and see where it's reading from the FINALLY saved place and doing the good/bad routine.
Then carry on usually.
Have Phun
C0d3r-F4N
September 19th, 2015, 08:06
Thanks for the fast reply!
I remember i saw my Input ("serial"

in the memory one times

, but i don't know how i've done this before.

There was a (as example) Test EAX, EAX (in code window) too.
One more question:
How can i find out where finally stored the input i've made (before the program closed itself)?
Have i break (paused) it before it's closed?
If i restart the program in Olly it starts on exact(ly) the same "code" as before.
Aimless
September 19th, 2015, 11:05
Hello,
It's up to you to find out where the finally stored input you've made goes. Too many techniques for finding the same, but break pointing on memory Read/Write and following each tentacle that may rise, will give you your results. Slow, but effective.
I would also suggest you defer the cracking till you've first learned the basic tools. IDA + Olly (or Windbg) will give you what you need, but you must learn how to use them first. There are nowadays so many VIDEO tutorials on how to crack. I'd suggest you start with the beginning ones first.
Have Phun
PS: Why do you want to crimp your neck and strain your eyes with debuggers? Get IDA, slice the program, then crack at leisure (sadly, no Vodka, but Scotch).
C0d3r-F4N
September 20th, 2015, 04:51
You are absolutly right

, i've to learn Olly first, but i think the best way to learn Olly is to use it like (or how?:thinking

i do it in the moment.

And yes, i've looked videos of Olly too.
Ohh and IDA isn't free, i want to use free tools!
blabberer
September 20th, 2015, 06:11
after clicking enter serial but before clicking ok pause ollydbg f12 look at call stack and set a breakpoint on the returns address of one or two or 3 frames below (preferably user code if possible) hit enter ollydbg will break on your breakpoint
hit alt+m (view memory ) and search for the fake serial , and set hardware access breakpoints on results you should be able to find the serial manipulating routine
C0d3r-F4N
September 20th, 2015, 07:12
Thanks, good idea!

But, if i entered a serial
without hit the enter-button and click F12 in Olly, look at call stack and set breakpoints, the programs window also do nothing (no reaction).

It seem like the window it's freezing.

So i can't hit the enter-button.
blabberer
September 20th, 2015, 08:20
baby you gotta run the debugger again f12 pauses the debugger and the app after setting breakpoint you gotta f9 the debugger so that the app also runs
you are kidding aren't you say yeah i ma kiddin ye mishter i gnow logiks donta teach me logika magika
C0d3r-F4N
September 24th, 2015, 11:44
@blabberer
Your last sentence

at your last answer.... i've read it more than once, but now i know you've wrote...

Oh and by the way... you don't need to teach me on "logica"!
The first sentence on your last answer i've understand by reading once a time.
For the future: Please write not in any "english slang"
if you want to teach anybody anything, thanks!
PS: You've got a PM!
Back2Topic:
I've tested it, but nothing found where the fake serial is.

But i know i saw it once in the past.

Kayaker
September 24th, 2015, 22:54
Along with the other suggestions, why don't you breakpoint on GetDlgItemText, GetWindowText or possibly SendMessage(WM_GETTEXT). That's the common way of following a SN after you enter it into a standard input field. You should be able to carefully follow it from there to where it writes the SN (or a derivation of) into the registry or a file, before the program forces you to restart. The SN will likely move to other addresses during this, so you could shortcut the process by using memory read/write breakpoints to follow the action.
If you're lucky you might find part of the algorithm used to check the SN (length, validity), which code might be reused when the program restarts and checks the SN for real. If not, you'll have to monitor registry or file reading to guide you to a suitable breakpoint. A tool such as Process Monitor will help with that, if you haven't already figured out exactly where it's stored.
C0d3r-F4N
September 27th, 2015, 04:10
@blabberer
I've now pause ollydbg (f12) and looked in call stack for return addresses, but there many - for me unkown - "calls".
Ok, it must be one of the USER32 because it's a Input(?).
Hitting enter to set a breakpoint doesn't work, pressing F2 works on "procedure".
After pause Olly, set breakpoint and hit f9, olly jumps to the breakpoints, but the program still in paused-mode.
I can't confirm my fake serial by pressing the ok-button in the program.
@Kayaker
That's a good idea too!
But can't find this to set breakpoints...
@all
I think it's not a program for a newbie like me!
What a pity...
Thanks for help!
If you have more ideas... your welcome!
Aimless
September 27th, 2015, 16:41
You must learn your tools before you even think of cracking.
IF, and when you DO learn your tools, start with OLDER versions of software. Winzip 5 (if you can find it) and MIRC 3 are good starting points.
Have Phun
blabberer
September 28th, 2015, 01:44
as aimless said in plain english and like i jested in slang you should first learn the tools you are going to use there is absolutely no alternative yes ABSOLUTELY no alternative
you replied you do not want me to teach logic but i suspect you have very weak logical understanding
a gui aka graphical user interface application has a pump that needs to operate continuously
a breakpoint or a pause or a single step is like switching the pump off
if you switch it off there is no pumping and thus no action possible (YES THAT MEANS YOU CANT HIT ENTER IN THE APP IN QUESTION ) your app needs to be running for the pump to be operating and processing messages
i think i posted search the memory for the fake string
i dont think i posted that settting a blind useless f2 breakpoint on an unknown and equally useless procedure on the return address of call stack
will yield you any magic potions
i think i posted to set an access (HARDWARE BREAKPOINT on the search result)
you should take a paper a pencil and sketch the flow
you should set several breakpoints that at some point lets you get past the system code that processes the input string and ends up in user code or
in the message pumping loop or hits the access breakpoint on the fake string
this message is getting too long to my liking so i am cutting it off here
start working on the stuff you dont get biceps if you dont lift the dumbell and going for bench press on the first day of gym is a surefire way to break bones not build body
owl
September 29th, 2015, 14:40
In short, try some tutorials like "lena's tutorials" for ollydbg and level1 crackmes from crackmes.de. Do the ones that have already being solved that way if you get stuck you can compare what you have with the solutions given. IDA has a free version that you can download. The free version is a previous version of the software (I think is 5.4 or 5.6) and does not support 64bit. However, that should be good enough to get you started. It does also help when posting a question to add a link to the binary if you downloaded from somewhere or post some images of the portion of the code you are looking at. Otherwise, people will give you generic answers.
C0d3r-F4N
October 2nd, 2015, 01:47
Quote:
[Originally Posted by owl;97190]It does also help when posting a question to add a link to the binary if you downloaded from somewhere... |
Like

i've wrote:
Quote:
[Originally Posted by C0d3r-F4N;97162]
Second i've read the FAQ so i think i know the rules... |
Quote:
FAQ:
Do not use direct links.
DO NOT EVER post anything like this: "Hi I have downloaded this program 12345.exe....
|
I'll try some tuts on lena's and on crackmes
but the the crackmes are not really at real life code
because they show only the easiest way.

And lena's tuts... the programs are very old and for old windows systems...
But you all right if you say i've to learn first the program olly

, but like i had wrote:
And like you can see what i've wrote about IDA.
If anybody will be my mentor

....
Thanks for help!

Powered by vBulletin® Version 4.2.2 Copyright © 2019 vBulletin Solutions, Inc. All rights reserved.