-----------------------------------------------------+
These informations are for educational purposes only!|
-----------------------------------------------------+

NewsGrabber version 2.1.14 crack by Lord Soth
=-------------------------------------------=
Hello peeps, its ME again!! muahahaha! 
:)
In this crack I bring to you the cool proggy by (forgot the name hehe). Anyway, this little proggy is making it quite hard to break, and it has a very nicely done protection scheme.
In fact, its so nice, that I included a little tutorial on how to actually make this program register.
If you wanna learn, do not apply the patch yet, because you'll need the original EXE file.
If you're not interested, just put the patch in the directory you installed NewsGrabber, and run it. Then enter your registration information in the register box. Remember to enter a number in the serial Num field.

Happy Grabbing!!! 


Tutorial on how to crack NewsGrabber 2.1.14
=-----------------------------------------=
Ok, first of all, get your hands on your favourite version of WinIce, and then we'll begin.
Load up the Exe file into the symbol loader, and then SI pops.
We'll start with the usual stuff.
In order for the program to get the input we give it, it needs to call special API's in the Windows USER32.DLL module (most of the times the programmers will use these API's, how UN-imaginative!!!!).
So we'll set a breakpoint (BP) on GetWindowText.
Some use GetDlgItemText, but I'll save you the extra trouble of figuring this out.
This program uses GetWindowText.

So in SI, type : bpx getwindowtext
walla.
Press CTRL+D to return to the program, and woa!!! we're back in SI, but we didn't enter any kind of information!! what in the name of ???
Don't worry about this for now, we'll understand this later.
In the meantime, when SI pops, just disable the BP untill we'll need it. The command for this is BD 0 (breakpoint disable , in this case, we want BP 0).
Press CTRL+D again to return to the prog.
Now we are at the annoying shareware nag screen, as the programmers called it. Lets click on 'Register' and see what happens. Nothing, except we are now supposed to enter our info.
(please enter your legitimate sucker code now.... blahblah).
Press CTRL+D and into SI we go. Re-enable the BP with BE 0.
Press CTRL+D to exit back to the program.
Now we're ready to do some major damage :-)

Enter your favourite name, I used LordSoth. Enter a nice string of numbers, I used 12345.
At this time, SI pops and we are at the beginning of GetWindowTextA. We can do 2 things here.
Either we go back to the caller routine and see what happens there (probly will have to do it), or just fetch the pointers of where the string will be put in memory, from our beloved stack.
I'll choose curtain number 1 :-)
Press F12 (which is the shortcut key for the command G RET, which executes code untill a RET instruction), untill you go back to GRABBER memory section. You can see in which code section you are by looking at the bottom of the code window.
Now we see the following piece of code :

Note: The addresses might be different than the ones I got, so plz, don't sue me just yet hehe)


00467631	PUSH 	ESI
00467632	CALL	[USER32!GETWINDOWTEXTLENGTHA]	This 1 fetches the string length...
00467638	LEA		ECX,[EAX+1]
0046763B	PUSH	ECX
0046763C	MOV		ECX,[EBP+10]
0046763F	PUSH	EAX
00467640	CALL	00462830
00467645	PUSH	EAX					****	Pointer to where string will be stored	
00467646	PUSH	ESI					****	Pointer to a pointer to where string blahblah
00467647	CALL	[USER32!GETWINDOWTEXTA]		This 1 fetches the String from the dialog
0046764D	MOV		ECX,[EBP+10]				>>>> We are here!
00467650	PUSH	FF
00467652	CALL	00462808					Hmm, what's this??
00467657	JMP		00467664
00467659	MOV		EAX,[EBP+10]
0046765C	PUSH 	DWORD PTR [EAX]
0046765E	PUSH	ESI
0046765F	CALL	00466746					Hmm, what's this??
00467664	POP		EDI
00467665	POP		ESI
00467666	POP		EBP
00467667	RET		000C

Ok, so now we are right after the GetWindowTextA call. Good. See above it there are 2 push instructions. Those are the parameters that the program passes to the API. In this case the pointer to the address in memory where the string will be stored is in EAX.
Now , one thing is not right. We type in SI 'd eax' which is supposed to display the area starting with EAX. However!!!!!!!, notice that EAX and its value in the register window is highlighted, which means it has CHANGED because of the call, so lets do the following.
We'll set a BPX (BP on execution), on the call itself, so we'll see what's the value of EAX before the call to the windows API.
So type away: bpx 467647
This highlights that line of code. Good. Lets go on. Disable BP 0 (getwindowtexta), because we don't need it anymore, we have a BP on the call itself.
CTRL+D and we're back into the program, then instantly into SI. Now see the value that EAX is holding? isn't it better??
Type : d eax. This will display the area in memory starting with EAX. Use ALT+arrows to scroll up a bit, and you'll see that the name we entered is there.
Now we are standing over the Call, lets do a procedure step over it and see what happens.
A procedure step for all of you guys who does'nt know , executes the procedure and returns, it DOES'NT go into the proc!
Now, like magic, the number we entered appreas just below. How cool we think.
Now we have several ways to go. We can check those 2 following calls to see whats in them, or we can try to BP on that area in memory where the strings dwell.
I'll choose the 2nd option. No point in digging into routines without knowing anything yet.
Just because I already did it, I will save you the trouble. The following call right after the GetWindowTextA is a call which makes lots of checks, and makes several instances of our name in the memory. Absolutely does'nt concern us. If you don't believe, see for yourself :)
After that 1, there is a JMP that skips the 2nd call, then if you follow the code long enough, without intefering, you will see that the program KNOWS that the info is bogus. So that rules out the 2nd call. So lets try the BPR option.

Set up a BP on the name, even the 1st char is enough. 
So therefore , bpm 00E41BBC r 			(your value will be different probably)

This sets our beloved BP on the 1st letter of the name, which will be all we need, you'll see.
So, we're pressing CTRL+D again, and we're back in the program, then back to SI.
We have stopped onto this:

REPZ SCASB

which we all know is a repeat of a scan string byte-by-byte. Press F12 and return to the caller routine, you'll see it checks the length, so leave it, it does'nt concern us.
CTRL+D, back to proggy, then back to SI.
Now, we have stumbled on the following piece of code (the protection you'll see...)
Before I write the code down, just type in SI : rs
This will restore the program's screen untill a key is pressed. Notice that we're back in the Nag screen. Since the location we are breaking on is the only 1 that interests us, we must assume that the check is made AFTER we have gone back.
In fact, soon you'll see this proc is called a lot of time during the program.

Here is the magic code:


00448957	MOV		ESI,[ESP+10]			;Pointer for taking the correct data
0044895B	MOV		EDI,[ESP+18]			;Pointer for taking our data
0044895F	ADD		ESP,04					;free stack
00448962	MOV		DL,04
00448964	MOVZX	CX,BYTE PTR [EDI]		;We are here!!! taking a byte from the string
00448968	MOV		EAX,ECX					;Also in EAX
0044896A	INC		EDI						;Increase the pointer by 1 = next char
0044896B	AND		EAX,000000FF			;Zero out the ext. part of EAX, to not page fault
00448970	MOV		[ESP+18],ECX			;Store out byte on the stack, irrelevant
00448974	TEST	[EAX+0049E269],DL		;Test on DL, but DL is set to 4, always 0...
0044897A	JZ		00448997				;this jump ALWAYS happens
0044897C	MOV		AL,[EDI]
0044897E	TEST	AL,AL
00448980	JNZ		00448988
00448982	MOV		[ESP+18],EBP
00448986	JMP		00448993
00448988	MOV		EBX,EDX
0044898A	INC		EDI
0044898B	MOV		BH,CL
0044898D	MOV		BL,AL
0044898F	MOV		[ESP+18],EBX
00448993	MOV		ECX,[ESP+18]
00448997	MOVZX	BX,BYTE PTR [ESI]		;Take a byte from the correct data string
0044899B	MOV		EAX,EBX					;store in EAX
0044899D	INC		ESI						;increase pointer by 1 = next char
0044899E	AND		EAX,000000FF			;zero out ext. part of eax, to not page fault
004489A3	TEST	[EAX+0049E269],DL		;test, see as above, will always be 0
004489A9	JZ		004489C0				;jump, always happens, as above
004489AB	MOV		AL,[ESI]				
004489AD	TEST	AL,AL
004489AF	JNZ		004489B5
004489B1	XOR		EBX,EBX
004489B3	JMP		004489C0
004489B5	XOR		EDX,EDX
004489B7	INC		ESI
004489B8	MOV		DH,BL
004489BA	MOV		DL,AL
004489BC	MOV		EBX,EDX
004489BE	MOV		DL,04
004489C0	CMP		CX,BX					;interesting, this compares the chars, and more..
004489C3	JNZ		004489CC				;if not the same, branch outa here
004489C5	CMP		CX,BP					;check if char 0, to know if it's the end of str
004489C8	JZ		004489E6				;if so, and char is good, branch
004489CA	JMP		00448964				;Go back and loop this whole shit again
004489CC	PUSH	19						;irrelevant to us

		
So, now we have broken in on the MOVZX instruction. It take the byte from our name string, and puts it in CX, and zeros the high order byte of CX, meaning CH.
It then stores this byte in EAX as well, and increases the pointer. The byte is stored on the stack for whatever malicious purpose, but will not affect our protection. The comes an interesting part. Seeing the TEST on DL there, I checked that memory portion. It is either 0 or 1, depends on the letter (higher case is a 1). So, this test (which is an AND instruction without storing the result), will always set the zero flag, hence the JZ afterwards will always take us to the next MOVZX instruction, at 00448997.
This is all very interesting, but as far as we can determine, the next piece of code, up untill the 2nd MOVZX will not be executed by the CPU. So we'll leave it, and even if it will be executed, it does'nt concern us.
So now we're at the 2nd MOVZX. This is the same as the 1 before, only that it takes the actual CORRECT byte. Then it is stored in EAX, and the pointer increases. So far so good.
The same check on DL, the same JZ always happens, which brings us immediately to the CMP at 00489C0. This is the workings of the protection.
The programmers have made a clever check per byte. Why clever? read on and find out...
Before we start tampering with the code, lets find out what happens here.
After the Check on the L of the string (first char), the JNZ jumps us to 004489CC.
Press CTRL+D, and puff, we're back at SI on the 1st MOVZX, remember it ?? :-) 
good.
Now, what is it doing? the same. Continue executing this code till u see that the byte that CX is getting is 31h. This is the ASCII value of the number '1'. Remember, we put a 12345 as our reg number. So, now we are taking a number. Continue tracing over the code, and when you jump on the CMP instruction, plz put a BP on it, for ease purposes.
Now the fun part begins. Notice that when the CMP checked our letters, the JNZ after the CMP was always true, meaning, a jump occured. Now notice how when we check a number (if it is indeed the correct 1), the JNZ is false, which means, NO jump. Keep that in mind for future notice.By the way, the correct number's ASCII value is in BX.
Now, since the username is flexible, the check has to be done on the serial number itself. This means, that the jump when we compared letters is a good thing.
Notice the CMP CX,BP afterwards. It checks if the char is 0. This is done to check for the end of the string of numbers. If its true, the program jumps to a different location, the 'GOOD' location. If not the end, the JMP 00448964 leads us to the first MOVZX instruction, to take the next char.
So what can we do basically?
We need to make it so that the JNZ after the CMP CX,BX will always be true for letters, and always false for numbers, and not just numbers, ANY numbers. This is kinda clever, but not that much. You will see the real cleverness of this protection soon enough.
Now, we can start by changing the JZ at 004489C8 to always be true, meaning, after we check 1 number, it will go off its merry way and will register the program for us. Why do we need to do that ? why not make the JNZ always false?
Because if we do, the protection will always go on , and then it will branch in that JZ that we are gonna make a JMP, at 004489C8. So you say, whats the harm in that?
Well, here comes the real icky part. This procedure is being used in the middle of the main program to check a few bytes of data. Those bytes are fixed, but there are multiple checks, and each is a different one, and the program needs to go on in its course the way it was MEANT to go, so if you try this, you will have weird 'bugs' in the middle of using your program.
So we can't tamper with the CMP itself, that we know. What else?
Why not stop the INC instructions used to increase the pointer?
Those are located at 0044896A and 0044898A. Nope, as you suspected, this will not do the trick.
It will only mean that the program will read the same bytes all over, and will loop endlessly in the protection scheme, clearly not a good idea. hehe
Ok, now we think, since the ASCII values of letters are 30h to 39h, and letters in uppercase are 41h to 5Ah (correct me if I'm wrong hehe), and uppercase letters are 61h to 7Ah (again, I might be wrong hehe), why not set the CMP to be :

CMP CX,40h
JG  normal position...
.
.
JMP good position...

Well, I'll tell you what the problem with this type of 'fix'. If you BPX on the CMP CX,BX and disable all others, you will enter the program and see all kinds of values being checked.
Some are 49h, 53h, 98h, 23h (bad for our CMP, look!), and 0 , which is also bad for us.
Then that leaves this theory out.
What next?
We can try substituting the CMP with a TEST or an AND instruction, so that we check only the upper 4 bits of CH? to remind you, CX looks like this:

003? , where the ? might be a number between 0 to 9. So can we do a TEST CL,30?
this will mean that only if 1 of the bits that make the 3 is enabled, the test would not set the carry flag.

I mean: if CX is 0035 for example , in binary it will look like : 00000000 00110101.
The right 8 bits are CL, and of those, the left 4 bits are the number 3.
So if we test it (TEST is like a logical AND, but without storing the results, only affecting the flags), with say 30, which looks like this : 00110000, we will do it, right?
well, NO!!!
What happens if 1 of the values CX gets is say.. umm... that nice 53h I told you about?
Then it will look like this: 00000000 01010011.
Notice that the left portion of CL, which is the 5, will set a bit to 1 , and will result in the carry flag cleared, which will result in a jump, what we wanted.
However, as you will soon find out, if it is a number, the those bits will set a bit as well, during the test, and will clear the carry flag as well, but we were checking a number!!!, and we don't wanna jump if we're checking a number!!!
Not good.
So what else is left?
Well, another bad way, but an interesting 1 arrises. When you BP on the CMP, take a look at AX.
It generally holds the value of BX, except for certain situations. In fact, it will only be equal to BX if we are checking a number (or a 38, in certain parts of the program, thats why its bad).
So we think, in the check for the letters, great, CMP CX,AX will mean they are different, and will jump. With numbers, they are the same, which will NOT jump.
In the checks for certain bytes in the code, They will be different as well, so it seems we got our solution. Now lemme explain why it won't work. Some of the byte checks inside the program are supposed to jump. Now in that case, they will actually be the same, resulting in a NO jump. However, if you let the program run by itself (after registering it), you will see that what it should be doing is JUMP, so this is out of the question.
Now you ask, how did you even register it?
Well as I said, you can completely skip the letter checking, but when u check for a number, and it does'nt approve of it, change the status of the zero flag to make the JNZ not true.
And then, be sure that you do jump at the check of the end of the string.

So, now we are almost lost. What else can be done?
Well, behold!
Lets do a little 'fix' to the values being compared here.
After all, we do know that we wanna check for a number, and we do know that all numbers have a 3 in their upper bits. So lets do this.
So we're gonna insert a few of our own instructions in there.Since the CMP is 3 bytes, and the JNZ is 2, and the next CMP and JZ are another 5 and the last JMP is 2, that makes a total of 12 bytes for us to work with. Now, the CMP CX,BP which is used to check for the end of the string we don't need anymore, because we're gonna change the JZ right after it to a JMP, which always happens, and the JMP at the end, which will return us to get another number, meaning, the JMP that moves us back to the 1st MOVZX instruction will never be used, either the proggy skips it in 1 way, or the other way. So lets rewrite those 12 bytes of memory.
 
In SI type:
a 004489C0
It will enter assembly mode.
Now type the following instructions.

SHR CL,4		;shifts CL 4 places to the right
SHR BL,4		;the same for BL
CMP CL,BL		;compares them both, after all, the values are in the lower parts of CX and BX
JNZ	004489CC	;if not the same jump and continue (jumps when letters and other data checked)
JMP 004489E6	;jump to registering after end of str,will always happen after 1 char is good 

Why those you ask?
The shift right will move CL and BL 4 places to the right.
To remind you, when we check for a number, CH and BH looks something like this:

0011???? , when the ???? are the number, and the upper part is the 3, as I said.
If we SHR them 4 places, the exact number is tossed aside, and the 0011 takes its place.
Then we get 00000011, which is just 3.
But thats what differs from the rest of the bytes being checked by this proc.
Since the numbers take 30 to 39, and all the others are NOT numbers, then the SHR will make them be different from 3!!!
Example: the first letter for LordSoth is L, which is 4C, which looks like this:
01001100
Shift it 4 places to the right, and you get a 00000100, which is NOT a 3!!
How cool!!!!
This will make a no jump only if we check a number (don't matter which because they all have a 3 hehe), and will generate a NO jump in the case the program checks for 0s, as we saw it does.
So, this is what we should do.
And with the unconditionaled jump at the 'end' of the string, we effectively crack this baby up, because it will check for only 1 number, and no matter what number it is, it will jump to register our proggy.

So, now we are left to crack it.
Copy the op-codes for the instructions, and a few more, so you can search them with a hexeditor, and change them.
These are the originals:


Here it is with all its glory:

46
8AF3
8AD0
8BDA
B204
663BCB		CMP CX,BX
7507		JNZ ..... good location if not a number
663BCD		CMP CX,BP
741C		JZ .... good location if a number
EB98 		JMP... to the first MOVZX, to take another char

I deliberately took a long hex string, so I will surely land on the correct piece of code, and as you will soon see, there is only 1 instance of this in the EXE file.

Search for: 468AF38AD08BDAB204663BCB7507663BCD741CEB98

ok, all good so far.

Lets change those op-codes to our new SHR instructions, and our new 'check':

C0E904	==> SHR CL,04
C0EB04	==> SHR BL,04
3ACB	==> CMP CL,BL
7502	==> JNZ 004489CC
EB1A	==> JMP 004489E6

where did I get those op-codes? well, if you have code on in you debugger, then alongside each instruction is its codes, and we did assemble those into our code, right?
goody

So, the 663BCB7507663BCD741CEB98 changes to C0E904C0EB043ACB7502EB1A, and that will do it.

This will behave as follows:
This code will SHR both BL and CL 4 places, and will compare them. If they were numbers or 0s, then the result would be the same, and that JNZ will not occur, and then the JMP will continue execution as was MEANT to be.
If they were anything else, either letters, or other types of data, that JNZ will happen, and the program again will continue as it was supposed to.
No need to check for the end of the string when checkig the serial num, because we check only once, and it will always be true because of those SHRs, and after 1 true check we use that JMP to register the proggy.

That's it!!! we did it!!
save our work, and exit.

Use your favourite patch generator to make this patch, and have a ball with it!
I personally still use eGIS's MKPATCH, which is fast and efficient!!!
Thanks eGIS!!

Now, I hate piracy, so this was done for EDUCATIONAL purposes only. I thank those programmers for this nicely done protection, but assembler ALWAYS wins hehehehe
1 more thing, if you like making key generators, you'll notice that somewhere around the strings we found earlier the protection (it's MATH part), makes the correct code, and puts it there as a STRING for you to see!!
You can try BPing on it to find out who wrote it there and find out what calculations are made.
Now go ahead and see how it works, remember, only numbers will register it in the serial num field, so act accordingly.
Another note, the program stores all kinds of shit into the registry. Search the program's name, and you'll see several interesting stuff, which I'll let you find out for yourself.
Happy day!!! hehe
Cya


PS, would like to thank eGIS again for his patch gen, and +ORC for his great tutorial which helped me a LOT in learing how to crack.

Cya boys and girls , be cool.


Lord Soth --- ICQ # 5178515 (DO NOT HARRAS ME!!)