I worked on this 6 months ago, and gave up, but actually need it now and cannot shell out the $475,-.Tried again, but got halted @ the same place.
This thing has 3 limitations:
- cannot load more than 1000 frames.

fixed this.

- Open more than 3 windows simultaneous

fixed this.

- Cannot save.

This is the problem. I read some essays on how to ungray buttons and enable menu options, which is also ok, but then I don't seem to manage to link that function to the save functions, which are in there:

":0046D09D"

* Referenced by a (U)nconditional or (C)onditional Jump at Addresses:
|:0046D0E9(C), :0046D0F8(U), :0046D109(C)
|
:0046D12D A190F44A00 mov eax, dword ptr [004AF490]
:0046D132 8945EC mov dword ptr [ebp-14], eax
:0046D135 FF75F0 push [ebp-10]

* Possible Reference to String Resource ID=61699: "Save changes to %1?"

I spent too damn much time on this one and would appreciate some pointers or a tut about this specific one. - thanks!

Target: Mayah editpro 3.0 DEMO http://www.mayah.com/content/products/editpro/editpro.html
---
MS002 MAYAH® EditPro MPEG Audio Editor

Editor for MPEG Layer II and III files which have been created by using Mayah® SendIt, Flashman® or compatible codecs. Cut, copy and paste functions, handles different windows, cue in, cue out, fast 32 bit version, long names are allowed.

$475,-

Hi x!,

Man, dare I say thats quite a hefty price on that little app ;-)

Well, I downloaded it and had a quick look at it so I'll offer up my few cents (though quite possibly you will have already exhausted the options I'm going to mention).

1st...Does the code exist? I'm inclined to think that it does. Both the string reference you mentioned as well as the presence of the GetSaveFileNameA API in the imports makes it likely that the code exists.

2nd...How to attack it...
Well, Ungreying the items is pretty straight forward as you mentioned via the EnableMenuItem API. Unfortunately, linking the code is the hard part and here is my suggestion if you haven't tried it already.
Have you tried a back trace range? You can pull out all of the relevant menu imports from Wdasm...plop them in an API moniter...and find 2 suitable "traps" for a back trace. I was going to try this and let you know if it helped, but unfortunately SICE won't recognize the module name (EDIT PRO 32 DEMO) so I can't set the bprw "module name" T. I'm not sure why...Maybe too many letters?
Well, I thought I'd throw out the option anyway. If you haven't investigated it yet, it might be worthwhile.

Your other option will be via the WM_COMMAND message route. +Spath has a very good menus reversing essay on this approach. IMO, its a little advanced (if you're like me you'll have probably have to read it 4-5 times , but its a good essay nontheless and very informative on all aspects of menus creation / reversing. If you don't have it already, you can easily find it here on the local fravia search engine. Also, Kayaker has a good tut on menu reversing for Trace32 which you might want to look for as well.

And I wrote up a tut myself covering some basic menus reversing techniques in response to the menus reversing project we had here in the mini projects section of the newbies forum. I tried to keep it simple and explain some of the basic concepts as I went along. I'll be happy to send it over to you if you're interested.

Hope something of the above helps :-)

Regards,
Clandestiny

Hi x!,

Man, dare I say thats quite a hefty price on that little app ;-)

Well, I downloaded it and had a quick look at it so I'll offer up my few cents (though quite possibly you will have already exhausted the options I'm going to mention).

1st...Does the code exist? I'm inclined to think that it does. Both the string reference you mentioned as well as the presence of the GetSaveFileNameA API in the imports makes it likely that the code exists.

2nd...How to attack it...
Well, Ungreying the items is pretty straight forward as you mentioned via the EnableMenuItem API. Unfortunately, linking the code is the hard part and here is my suggestion if you haven't tried it already.
Have you tried a back trace range? You can pull out all of the relevant menu imports from Wdasm...plop them in an API moniter...and find 2 suitable "traps" for a back trace. I was going to try this and let you know if it helped, but unfortunately SICE won't recognize the module name (EDIT PRO 32 DEMO) so I can't set the bprw "module name" T. I'm not sure why...Maybe too many letters?
Well, I thought I'd throw out the option anyway. If you haven't investigated it yet, it might be worthwhile.

Your other option will be via the WM_COMMAND message route. +Spath has a very good menus reversing essay on this approach. IMO, its a little advanced (if you're like me you'll have probably have to read it 4-5 times , but its a good essay nontheless and very informative on all aspects of menus creation / reversing. If you don't have it already, you can easily find it here on the local fravia search engine. Also, Kayaker has a good tut on menu reversing for Trace32 which you might want to look for as well.

And I wrote up a tut myself covering some basic menus reversing techniques in response to the menus reversing project we had here in the mini projects section of the newbies forum. I tried to keep it simple and explain some of the basic concepts as I went along. I'll be happy to send it over to you if you're interested.

Hope something of the above helps :-)

Regards,
Clandestiny

...Sorry guys,I hit post twice by accident.

--Clandestiny

Hi Guys,

I've been having a look at this one too. I tried a Trace between the GetMenuItemID call for the Save menu item and its EnableMenuItem call. Set a BPX GetMenuItemID, select the File menu item and watch the value in EAX, which shows the 2nd stack parameter of the call (position of menu item). When it reaches 3 (for the 4th item in the drop-down list which is Save), F11 return from the call and set the trace with BPRW [module-name] T. Then set a BPX EnableMenuItem and press F5. When it breaks again you've got a trace of all the code hit between the two. Compare this with a similar trace for an enabled menu item, such as Open, and you can find the difference lies here:

:00467622 CALL [EBP+14]

When the item is to be Enabled, [EBP+14] is 40CFA0, if Disabled it's 4106D0. Now there doesn't seem to be a simple flag determining this, but you could check further in the backtrace history and see what determines the address called. If you're *very* lucky there's a single memory flag somewhere that might also control enabling the Save functionality.

BTW Clandestiny, it seems Softice sometimes has problems with certain commands (BPRW, MAP32) using long or spaced MODule names such as this, so you can usually just rename the file to something short that shows completely when you type Task. Works for me anyway.


Anyway, I didn't get anywhere with this, did a bush patch so ALL menu items were enabled and tried manually tracing from selecting Save. You have seen the Mini Project forum thread right? ;-) Well, there's lots of places where the MenuID's of E103 (Save) or E104 (SaveAs) are pushed before indirect calls, but I got bored with the code. Er, I mean, lost in the code


So then I keyed in on GetSaveFileNameA and found 1 interesting thing out. The code you mention
* Possible Reference to String Resource ID=61699: "Save changes to %1?"
IS actually called when you modify an MP3 and then select Exit! It asks you if you want to save and if you say Yes, a SaveDialog box pops up! Whaddya know. The only problem is is that DeleteFileA is called and the file is never saved. If you fake it and force it to be saved, it's of zero size. Anyway, this is maybe another area you could check out. You do want to connect that GetSaveFileNameA routine (sans DeleteFileA) with selecting the Save menu item.

'bout all the help I can give right now.

Regards,
Kayaker

Clandestiny, Kayaker,

thanks both for the input! I think I see a light at the end of the tunnel now .

I am in the middle of some exams now, so I'll look into this again in 14 days or so...

Clandestiny, can you put that tut on a page or something? thanks! I can use ungray reading because IIRC the menu ungaying was no problem but the button ungray I couldn't get to work. (been a while, and I'm not really advanced, or "intermediate" )

thanks a lot guys! maybe I get to edit mp3's this year

greets, and I'll drop a line in 14 days or so..

The attual code that enables the save and save as button is simple:

:00467827 FF7608 push [esi+08]
:0046782A FF7004 push [eax+04]

* Reference To: USER32.EnableMenuItem, Ord:00B5h
|
:0046782D FF15D8644800 Call dword ptr [004864D8]
:00467833 EB55 jmp 0046788A


* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:00467833(U)
|
:0046788A C7461801000000 mov [esi+18], 00000001 <-- here

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:00467813(C)
|
:00467891 5E pop esi
:00467892 C20400 ret 0004


Very simple 1 = disabled | 0 = enabled. So do the apropiate changes and the menu items will be enabled.

If you check closer the developers havnt included the save function at all. Its disabled/raped. Missing critical code.
Kayaker's method of forcing it to be save is not going to work and looking at that code will make it quite clear why not. The program is a demo and its not full with code disabled. It doesnt have the needed code at all..

well, I can confirm what is said here. The save code is gone .

I knew I cracked an old '99 version once and after a bit of searching I found it.
It's called "Real Edit MP3 3.0", and more the little brother of this one. (only can cut
mp3 frames. no fading etc)

please download pack.rar from:
http://briefcase.yahoo.com/bc/melvin887vjy814?c&.flabel=fld3&.src=bc&start=1

the rar password is "rce.project"

the OLD little brother calls:
:0043CBD0 FF5078 call [eax+78]

which points to:



which is the SAVE routine...

the target we were working on:

:0046D017 FF5078 call [eax+78]

calls:

:0040E280 33C0 xor eax, eax
:0040E282 C20400 ret 0004

which doesn't do much of course ... Also no other locs found with save routine so I'm assuming it's not in there.

Is it do-able to graft the Code from little brother in the big one? (like that notepad essay?)

It's a bit above my capabilities, but it would be great if a "intermediate" or "expert" would have a go at this. (please)

I'd love to learn how, if feasible of course.

here's an idea, that I was planning on toying with a bit sometime, but I won't have time for awhile, so if you like, go for it....

If you have any programming knowledge, write a .dll that pops up a save window.....make the program load the .dll and the link a call to it when the save item is clicked......

you'll have to ad serialization code, play with the imports, PE etc, but it is an option ;-)

well, I actually started transplanting the code.

am about 70% though the 967 byte snippet for changing all the call locations (about 60 calls).

stumbled upon 3 calls which are slightly different, so potential problem here

stumbled upon the _real_ save function, also missing, which is about 400-500 bytes, but luckily mostly simple calls like "call ds:SetFilePointer" which are surely in the new exe already so good chances here.

found one small call + subcall (!!00408ACB call sub_4010BB) which is also missing in the new exe, but I'll get it in the new one also.

the datastrings (or how do you call those: "push offset a_tmp ; ".TMP"" I'll add last after all code is in.

all in all another 4-5 hours of work. I hope I can pull it off because this is totally new for me...

Can't code win32, nor know anything usefull of win32asm so I'm left to do this the brute-force way.

would be cool if someone else could look up the exact patches to get

- that save/save-as button and menuitems linked to the code?
- the 3 file limit, seems I lost the patch...

btw: 401C98 -> 1000 frames limit

ne-way I'm going to sleep. 6am and a lot of reversing tomorrow.

btw: would this make a good tut?

Hi

I had a closer look at this one too. That was an interesting observation x!. The code around the call [eax+78]in both versions is essentially identical, and the
:0040E280 33C0 xor eax, eax
:0040E282 C20400 ret 0004
that's pointed to in the Demo version is just plastered in the middle of a bunch of nops. Makes it pretty enticing to think you *could* graft the code from one to the other doesn't it?

As you've found out I see, unfortunately there's other areas that are just a "bunch of nops" too and a lot of Calls that need to be readdressed. Not only the WriteFile procedure but whatever processing happens to convert the memory image to an mp3 file, plus the graphics of the lame progress bar, plus Windoze code, plus...

I looked at this and then I thought that if it proved to be too difficult to "mesh" the new and old code bits together, might be to extract the entire extent of all code called from the Call [eax+78] in the good version, insert it in a new section at the end of the demo version and rereference the addresses. I tried a TRACE in SI to see how far this network would go, and by the time I had finished vacuuming the cat, went out and bought some iodine, and returned, it was still processing.

After rebooting both the cat and the computer I started thinkin' like ?ferret, except in a more inelegant way, about having the demo memory map the *entire* good version when [eax+78] is called, and access the working Save functionality from there, returning to the demo. Kind of clumsy, but I think it would work in theory.

One last thing you've probably noticed anyway. The call [eax+78] in the demo *is* called when you Exit with a changed file and elect to save it. The funny thing is, it doesn't actually exit after this. You might be able to use this to get the SaveDialog to open. As soon as you give it a name and say OK, *then* [eax+78] is reached to process the file, and all the code after the RET seems to be OK.

BTW, your question about whether this would make a good tut? It sure would! Get some sleep, finish it up and start writing ^_^

Regards,

Kayaker

hehe. lol.

after a day of reversing I'm stuck with

>5000 lines assembly sourcecode
>43 sub-calls
>11kB patched code
& added USER.DLL:GetCursor to import table

all nicely organized.

damn. why am I afraid to commit this patch? :-)

If I pull this off, I just got nominated for the 2001 Nobel prize, category "hardcore reversing". Slim chance though ...

my head hurts, I need to take a walk I think. :-)

I don't know that my way is elegant LOL....jus portable.....if you run across another save disabled scheme, the .dll is already wrote ;-)

Alrighty, then when can we see the whole thing ??
I haven't been following the message threads and it sure seems like an interesting project.

And ?ferret you little birdie, you smartass

LS

The code is in, but still need to adjust the calls. Everything went ok, but I 'topo' ( http://free.hosting.and.email.at.ebox.ru/~protools.fbi.ru/files/utilities/topo.zip ) to add a code section where I put most functions, and now I have problems calling these.

If I don't find a way, I'll need to start over and fill 11k of caves... (and more might follow).

example: in hiew

I get to my function-2-be-called by pressing F5 (goto) and then offset
1022bb gets me to .005492BB

however, when I call this address:
000851CB: E8EBD00700 call 0001022BB

it calls .0005022BB (???) (hey, I'm a newbie...)

first thought it was a hiew bug because biew shows ok, but now when I disassemble the exe, wdasm also gets the wrong address.

I don't have much time the next few days, but I'll see what I can do.

anyone can explain to me why hiew JUMPS ok with F5 but fails to get the right call?

thanks

I can't offer much insight into the prob, but when injecting code, I tend to use JMP's to get to the new function and back. Not as neat, but it seems easier to implement ;-)