View Full Version : Magic File Renamer Patching tips and solutions
RalDnoR
November 7th, 2000, 17:01
Please post all you experiences on patching MFR into this area...
Thanks!
Raven58
November 8th, 2000, 16:02
Looked to patch at 004a8170, 742b, JE, 004a819d, offset a7570. Changed to JNE 752b with no effect, than nopped with same result. Working above string ref. "Thank You for registering Magic". Ran filemon and regmon before opening , found nothing. also looked at a .ini file in the MFR folder. So now I will look again. As you can tell I am a real newbie and somewhat embarrased by this post. But then again I am here to learn.
hz
November 8th, 2000, 16:48
hi,
don't really know if I should be saying this but you are off track with the .ini and registry.
regards
hz
Timmy
November 8th, 2000, 17:54
The procedure you're looking for starts at cs:004a8378. Trace this with F10 (you don't really have to step into any of the calls in this subroutine until you are ready to work out how the code is generated) when there is a call instruction, look at the register values before the call and also what is being pushed onto the stack. - ie. if the value in eax is pushed before a call do a d eax and see what it points to. Also after the call see what values are returned (eg. d(bp+?) might point to something, if it doesn't the (bp+?) address might contain another address that contains relevant data).
ThRaX
November 8th, 2000, 21:37
see my problem here is i can't seem to break to the code in any way at all...i've tried all the breakpoints I know of, but nothin works...I've gotten a dead listing and gotten *somewhere* using only string data references and back tracing from there...
any tips on how to go about getting a break on the code somehow?
?ferret
November 8th, 2000, 22:08
well, one way, since you're having a bit of trouble finding the right API, would be to break on a suspicious address from your dead listing (bpx CS:Address)
Kayaker
November 8th, 2000, 22:33
Thrax,
If you can't find any suspicious addresses, HMEMCPY always works (MEMCPY I think for NT, but I wouldn't know anything about that).
Just keep hitting F12 until you return to program code. Remember that this app does its reg check realtime, so to speak, as you are entering your s/n, so HMEMCPY, or whatever good BP you set, will keep breaking until the proper conditions are met.
?ferret has the better idea though, you should be able to use Dede to scope out a good address breakpoint at the start of the reg routine.
Go with his suggestion, ignore almost all of what I've just said unless you're desperate
Kayaker
ThRaX
November 8th, 2000, 23:06
heh...i guess i'll just have to take your word for it...I'm on NT, and hmemcpy doesnt work...(and contrary to popular belief, based on my own observations, memcpy is *rarely* a replacement for it)...oh well i believe that i found another way ... i used dede and viewed the "SetRegisetered" function and it pointd me to that address anyway, lol...
thanks anyway
Timmy
November 9th, 2000, 16:28
Can't understand why hmemcpy doesn't work for you, it did on my machine. I just clicked on file then register (the registration box appears), ctrl d into sice then bpx hmemcpy, F5 then when I enter a character in any of the edit boxes sice breaks. The same route but slight ly easier is to get the registration box on the screen and enter a name, company and a dummy code (enter 4 or 5 digits for the code), enter sice, bpx hmemcpy, F5 then enter 1 more digit in the code edit box and sice breaks. This way gives you longer strings to do a search on. Make sure the appropriate entry in winice.dat hasn't got a ";" in front of it.
ThRaX
November 9th, 2000, 16:46
Hmemcpy is not GOING to work for me in any way---I'm on windows NT as I said, and hmemcpy doesnt work on NT....doesnt have anything to do with how im trying to use it...(hmemcpy isnt a valid function, its coded into the 16 bit part of the win9x operating system, and winnt is totlaly 32bit, therefor no hmemcpy...or something like that, i'mnot really sure about the details)...
cya
Timmy
November 9th, 2000, 17:49
Try this then ...
get the registration box up and enter name company and code, ctrl d then bpx callwindowproca, an F11 or 2 later you should be at c:00434e57 (this is where bpx hmemcpy returns you to in win98). I think this should work because the a at the end of callwindowproca means it is 32 bit.
Clandestiny
November 9th, 2000, 21:00
Hi guys,
I have registered Magic File Renamer. I found both the valid # and the place to patch (which I have tested in SICE). I'll admit, I was a little perplexed on how to break into the code at first. Finally, I used ?ferrets suggestion of breaking on a suspicious address from my dead listing which landed me right smack in the middle of the protection.
It's the first time I have ever used Dede and the layout is really quite...I mean you really can't give the cracker any more hints than a nice procedure labled 'register' and references to 'name'and 'code'...hehe.
Cheers,
Clandestiny
mersenne
November 10th, 2000, 01:52
Hi Clandestiny,
Did you make the patch with a hexeditor and then check you've got it right? I also have found the place where the valid serial is calculated and where the comparison between that and the entered serial is made. I too can make the program become registered using SIce at this point, HOWEVER, when I make the patch permanent it doesn't work.
I think I'm slowly zeroing in on it. So will keep at it.
Later
Mersenne
Raven58
November 10th, 2000, 10:37
Wow, I must be out in left field here. Everyone using sice and me trying to patch with wdasm and hiew as I thought that was the first part of this project. Anyway, still playing above Strg ref. "Thank you for reistering" i wdasm. It appears that if 004a8170 is changed to JNE we get to 004a819d. There are than around 5 calls before we drop below and into the good boy routine. I thought I might nop these 5 calls, but haven't got to it as yet. Am I on the right track here using wdasm? Suggestions appreciated.
goatass
November 10th, 2000, 11:23
Hi everybody, I'm happy to see people are enjoying this new project.
From what I've read on previous posts, people are setting BPX HMEMCPY when they are entering the serial to see what happens well that's good too but here something else to try.
First of all this is a delphi program so I used DeDe to decompile it, Clicking on the "Procedures" tab we see some names and the last one is Register...ummm interesting. We click it to see it's events, now look carefully, don't just to conclusions right away, do you see something interesting in there ? NO NO NO I'm not talking about SerRegistered, I'm talking about ebNameChange what this tells us is that something is gonna happen to our name as we enter characters in to the program. That is interesting so we double click on ebNameChange and we see the disassembly we start looking at 4A83A8.
The first call gets our name, the second moves it to another location and checks to see if there is anything in that location (was the move successful), the third call gets the length of our name and check that it's no longer than 60 characters.
Now comes the really fun part, see all those characters MOVed to EDX before the CALL at 4A83DA what do you suppose it's gonna do with that. Well it does something I didn't look at it yet, but after that call there is another one and when that one returns from whatever it does (you have to figure that one out, I won't tell u everything) you will see your real serial in EAX. Than in the CALL at 4A83FD is where your serial gets compared with the real one.
I'm gonna write a keygen in a few minutes so I'll have that posted when I'm done.
goatass
Timmy
November 10th, 2000, 12:32
Well here is my 2 pence worth. A unit written in er.. Delphi. Enjoy.
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
StdCtrls;
type
TForm1 = class(TForm)
Edit1: TEdit;
Edit2: TEdit;
Edit3: TEdit;
Label1: TLabel;
Label2: TLabel;
Label3: TLabel;
Label4: TLabel;
procedure Edit1Change(Sender: TObject);
procedure Edit2Change(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
EncStr : string[$46] = 'lcjfvibb22vg45hdfk6456gff767hu56jjjjhjhu76574fgdjgfzhdfh67hjghfdh6667h';
implementation
{$R *.DFM}
procedure GenerateCode(Name,Company:string);
var
NandC : string;
PosNandC,
PosEncStr : byte;
Count,
Code : integer;
begin
NandC := Name + Company;
if (Name <> '') and (Company <> '') and (length(NandC) <= $46) then
begin
PosNandC := 1;
PosEncStr := 1;
Count := $46;
Code := 0;
While Count > 0 do
begin
Code := Code + ord(NandC[PosNandC]);
Code := Code xor (ord(EncStr[PosEncStr]) * $83);
Code := Code + PosEncStr;
Code := Code + PosNandC;
PosEncStr := PosEncStr + 1;
PosNandC := PosNandC + 1;
Count := Count - 1;
if PosNandC > length(NandC) then PosNandC := 1;
end;
Count := Code shl 4;
Code := Code + Count;
Form1.Edit3.text := inttostr(Code);
end;
end;
procedure TForm1.Edit1Change(Sender: TObject);
begin
GenerateCode(edit1.text,edit2.text);
end;
procedure TForm1.Edit2Change(Sender: TObject);
begin
GenerateCode(edit1.text,edit2.text);
end;
end.
stanks
November 10th, 2000, 14:08
Hi!
This is our routine:
00491ABC 33D2 xor edx, edx
00491ABE 8AD3 mov dl, bl
00491AC0 0FB65417FF movzx edx, byte ptr [edi+edx-01] ; 1st char. of name+company
00491AC5 03F2 add esi, edx
00491AC7 33C0 xor eax, eax
00491AC9 8A442404 mov al, byte ptr [esp+04]
00491ACD 8B1424 mov edx, dword ptr [esp]
00491AD0 0FB65402FF movzx edx, byte ptr[edx+eax01] ;lcjfvibb22vg45hdfk6456gff767hu56jjjjhjhu76574fgdjgfzhdfh67hjghfdh6667h
00491AD5 69D283000000 imul edx, 00000083
00491ADB 33F2 xor esi, edx
00491ADD 03F0 add esi, eax
00491ADF 33C0 xor eax, eax
00491AE1 8AC3 mov al, bl
00491AE3 03F0 add esi, eax
00491AE5 43 inc ebx
00491AE6 8BC7 mov eax, edi
00491AE8 E8A324F7FF call 00403F90
00491AED 33D2 xor edx, edx
00491AEF 8AD3 mov dl, bl
00491AF1 3BC2 cmp eax, edx
00491AF3 7D02 jge 00491AF7
00491AF5 B301 mov bl, 01
00491AF7 FE442404 inc [esp+04]
00491AFB FE4C2405 dec [esp+05]
00491AFF 75BB jne 00491ABC
I will try to write this keygen in C.
greetz
pm
November 10th, 2000, 18:09
Quote:
Raven58 (11-09-2000 23:37):
Wow, I must be out in left field here. Everyone using sice and me trying to patch with wdasm and hiew as I thought that was the first part of this project. Anyway, still playing above Strg ref. "Thank you for reistering" i wdasm. It appears that if 004a8170 is changed to JNE we get to 004a819d. There are than around 5 calls before we drop below and into the good boy routine. I thought I might nop these 5 calls, but haven't got to it as yet. Am I on the right track here using wdasm? Suggestions appreciated. |
Hi Raven58,
For the patching part is enough to use w32dasm, but is always better (at least for me is) to use Sice to understand whats going on, for example with the jumps. You can try to nop all that calls you mentioned, but it wont work. My tip is look a little further (backtrace)
and try to see the referenced call at 4a8406. Hope it helps.
pm
JaneK
November 10th, 2000, 18:24
Hi,
How can I unregister the prog?
Thanks
JaneK
ThRaX
November 10th, 2000, 20:56
Whoops, double post again lol...sorry
hz
November 10th, 2000, 20:57
hi,
writes the registration to mfrdat.dat in the
system folder, just remove it.
regards
hz
hz
November 10th, 2000, 21:02
hi,
writes the registration to mfrdat.dat in
the system folder, just remove it.
regards
hz
ThRaX
November 10th, 2000, 21:07
Hey, stanks I seem to have found one small problem with the code segement you just gave...You're missing a small part that was on the end of the loop. (after it actualy)
I have posted what I believe to be the correct code snippet on the 'keygenning' thread, as I think we are getting a bit off the "patching" subject here, and this stuff is more keygen related...Please check it out I think the file i attached there is worht looking at for other newbies who need some help understanding the calc routine.
cya later
Timmy
November 10th, 2000, 21:19
delete or rename the mfrdat.dat in windows\system
Timmy
November 10th, 2000, 21:32
Forgive me if this gets posted twice (I have had a wet), just delete or rename MFRDAT.DAT in c:\widows\system\ and there you go.
hz
November 10th, 2000, 22:59
hi,
remove the mfrdat.dat file from the system
folder.
regards
hz
goatass
November 11th, 2000, 00:29
to unregister, just edit the mfr.INI file (it's the only INI file, don't remember the name) and find UserName= and delete your name from there leaving the UserName= in place also delete the Company value.
goatass
stanks
November 11th, 2000, 04:09
Hi!
You only have to delete mfr.ini (it is in dir. where is exe file)
greetz
stanks
November 11th, 2000, 04:12
Hi!
You only have to delete file called mfr.ini from directory where is our exe file.
Greetz
Lord Rhesus
November 11th, 2000, 06:52
Quote:
JaneK (11-10-2000 07:24):
Hi,
How can I unregister the prog?
Thanks
JaneK |
Delete the file mfr.ini
JaneK
November 11th, 2000, 08:39
Pls ignore above post
JaneK
JaneK
November 11th, 2000, 08:42
Pls ignore above post
JaneK
goatass
November 11th, 2000, 10:08
To unregister, edit the INI file in that same directory and delete your name and company from there.
goatass
RalDnoR
November 11th, 2000, 16:38
Hi all!
It's great to see all the effort people are putting in this project so far!
The last question about the unregistering of the software is an important one, because it isn't mentioned by anyone...
There is a file in your <windows>-directory called 'MFR.DAT' which contains the registration info.
This is also where the difficulty in patching shows up... It is easy to patch the program in such a way that it says 'thank you for registering' (or something like that), but afterwards you'll notice that the serial check is done at many, many points in the program (check it in W32Dasm and see from which locations the serial-routine is called). The trick is to modify the code in such a way that when the MFR.DAT-file is empty it will ask for registration, and once it is full (by registering it with a fake serial) it will return the 'good guy' number (can't remember if it's 1 or 0, I don't have the disassembly at hand right now).
I really appreciate all the info given by people here, though sometimes I miss some more background. Maybe it's nice for newbies to show some more detail. I think in the patching issue this isn't really necessary, but with keygenning newbies also need to have some assembly experience. Maybe it's nice to show more comments in the source-code. It's difficult to make it easy to understand for everyone though I think with this many posts we're definately in the good direction.
I will compile the threads concerning this project in a file and post it on my website soon.
Keep up the good work!
B.t.w. I also want to say it's nice to meet such a lot of people with the same interests
Yours sincerely,
RalDnoR.
hz
November 11th, 2000, 17:24
hi,
look up the page and you will see I posted the mfrdat mesage and on my computer its
in the windows/system folder. Not trying to be a smart ar*e just mentioning it.
regards
hz
hz
November 11th, 2000, 17:39
hi,
forgot to mention, if you follow from where
it reads the mfrdat file you will very quickly
find where to patch so its regged at startup.
regards
hz
Timmy
November 11th, 2000, 20:46
Doh ... Homer ...
hz
November 11th, 2000, 22:34
that all you have to contibute apart from a half finished keygen?, yawn.
hz
RalDnoR
November 12th, 2000, 06:53
Sorry, I only read the first page and posted a reply on it...

Timmy
November 12th, 2000, 09:00
The Doh Homer was a reference to myself for posting a message twice, clicking the next page button illuded me for a while - obviously I was not alone in that. Anyway, back to more serious matters.
ThRaX
November 13th, 2000, 17:24
Hey, looking at the website for MFR, and reading it I found that the guy who wrote this thing seems like hes a cool guy. After this is all done, I think we should contact the author and tell him all about this project, and point him to this site...(I'm assuming that after cracking this program you all unregistered it) He seems like the type of author who would even appreciate something like this in fact, and it would be cool if we contacted him...laterz
hz
November 13th, 2000, 20:54
hi timmy,
fair enough mate, I jumped the gun, I apologise.
hz
November 13th, 2000, 21:05
hi ThRaX,
I'm against that idea, for the same reasons as BlackB in his "ASProtect and we, reverse engineers" thread on the other forum and maybe he's not as "cool" as you think, we have been shut down too many times already. Just my opinion buddy, you are entitled to yours.
regards
hz
ThRaX
November 16th, 2000, 22:29
Ehh, whats goin on now? It seems most of us are basically done with both of the tasks (or at least one)...And no one has posted in a while...Does this mean we're moving on?
paularis1
December 10th, 2000, 17:22
Hi,
To unregister the prog just delete the file C:\windows\system\MFRDAT.DAT
Have a Nice Day !
Paularis1 [/QUOTE]
Powered by vBulletin® Version 4.2.2 Copyright © 2018 vBulletin Solutions, Inc. All rights reserved.