Hi !!

I have patched the nags of a Microsoft Visual C++ 6.0 program but it has hidden options, the software is mp3 trackmaker.

Anybody can give me some idea about how to attack this soft.

Thanks all!!

Sorry I am a newbie and my native is spanish. (bad enghish)

[This is not a crack request, is only a idea of attack request]

If what you are attempting to do is to activate (ungray) ceratain features in menus and buttons, check this out:
http://www.woodmann.net/fravia/Clandestinity_MixVibes.html

there are references to other tuts in there which may give you a starting point.
If that is not what you intend, please be more specific and explicit with what you have done so far and what you want to achieve.

Ok thanks for your answer.

I'll try to explain (my english is not so good)

When I open the demo version, I can see one botton named 'grab winamp position' and under this botton i can see "More options are available in the registered version, including splitting all tracks into equal parts, and importing and exporting your tracks to and from .CUE files in order to save time"

When I open the program into w32dasm i can see:
...
009 - ControlID:03ED, Control Class:"BUTTON" Control Text:"Add Time"
010 - ControlID:03FB, Control Class:"BUTTON" Control Text:"Grab Winamp Position"
011 - ControlID:03FC, Control Class:"BUTTON" Control Text:"Import Track Times From .CUE File"
012 - ControlID:03FD, Control Class:"BUTTON" Control Text:"Export Track Times To .CUE File"
013 - ControlID:0404, Control Class:"BUTTON" Control Text:"Track Naming"
014 - ControlID:0402, Control Class:"BUTTON" Control Text:"Remove Time"
015 - ControlID:0403, Control Class:"BUTTON" Control Text:"Clear List"
016 - ControlID:03FF, Control Class:"BUTTON" Control Text:"Create Tracks"
...

Because of that I think that this botton (avaliables in full version ) can be activated in demo version.

I'll try the link, thank.

Sorry again Im spanish.

Hi Gento,
Have you tried to spy the program with a resource editor (i.e. resource hacker)? Sometimes, these kinds of messages are placed over the hidden items and a simple manipulation of the resource might solve the problem.

Otherwise you can try to solve the problem in another way: these lines are from Windasm's 'Dialog Reference' so, it's possible for you to find the place where the hidden items are loaded. Load the file using windasm and then click on Refs-Dialog References. Here, you will find all (or only some) the references of the objects in the dialog. Look for one of the hidden references (for example: 'Track Naming') and then double click the item. Windasm will bring you directly on something like '*Possible Reference to ...blablabla..."Track Naming"'. From here, try to understand the lines above and, the reason for which the program does not load this item. Probably, you have to find a simple conditional jump that decides to (not) load the hidden items.

Good luck,
ZaiRoN

Ok lots of thanks, nice idea to attack the victim.....





Minutes later.....


..... I've used reshack. Under the message are placed the hidden items. I can see the buttons but if i execute the program I can see the only button i refer in my second post.


Again lots of thanks to both from spain. (tomorrow i'll try with exescope, pexplorer, restor25)

Gento, use the second way: windasm approach...

ZaiRoN

Hiya,

...Had to break this up into 2 posts (darn 10,000 char limit)...

---BEGIN PART 1---

Well I had a look at your target and I can certainly give you some pointers on how to attack this type of target... The bad news is that I believe the code for those hidden functions does not exist in this DEMO version. Feel free to prove me wrong though

First off, the easy part is making the hidden features visible. If you go into a resource editor and delete the static text "More options are available in the registered version, including splitting all tracks into equal parts, and importing and exporting your tracks to and from .CUE files in order to save time" you will discover that those hidden items magically appear. Yeah, the static resource was just covering them up. Nevertheless, if you run the app you still won't see the hidden items. Looking at a windows message spy, you can see that those hidden buttons have been assigned window handles and therefore you can conclude that they have been created and rendered invisible at runtime. Realizing that a tabbed view of this sort consists of multiple dialog boxes (1 dialog template for each tab), I located the creation code for each of these dialogs in IDA.

text:00401320 sub_0_401320 proc near ; CODE XREF: .text:004012DCp
.text:00401320
.text:00401320 hWndParent = dword ptr 0Ch
.text:00401320 hWnd = dword ptr 10h
.text:00401320
.text:00401320 push ebx
.text:00401321 push ebp
.text:00401322 mov ebx, ds:GetModuleHandleA
.text:00401328 push esi
.text:00401329 mov esi, [esp+4+hWnd]
.text:0040132D push edi
.text:0040132E mov edi, [esp+8+hWndParent]
.text:00401332 push esi ; dwInitParam
.text:00401333 push offset sub_0_401650 ; lpDialogFunc
.text:00401338 push edi ; hWndParent
.text:00401339 push 6Fh ; lpTemplateName
.text:0040133B push 0 ; lpModuleName
.text:0040133D call ebx ; GetModuleHandleA
.text:0040133F mov ebp, ds:CreateDialogParamA ; Create a modeless dialog box from
.text:0040133F ; a dialog box template resource
.text:00401345 push eax ; hInstance
.text:00401346 call ebp ; CreateDialogParamA ; Create a modeless dialog box from
.text:00401346

From here, you can extract the address of the DlgProc for this dialog. Its almost certain that those hidden buttons are being rendered invisible in the DlgProc when it processes WM_INITDIALOG before drawing the controls on the screen. Sure enough, this proves to be correct. The prog calls ShowWindow for each control by specifying SW_HIDE which renders them non visible on the screen.

SPLIT TAB DIALOG PROCEDURE

.text:00401650 String = byte ptr -0Ch
.text:00401650 hWnd = dword ptr 4
.text:00401650 arg_4 = dword ptr 8
.text:00401650 arg_8 = dword ptr 0Ch
.text:00401650
.text:00401650 sub esp, 0Ch
.text:00401653 push ebx
.text:00401654 push esi
.text:00401655 mov esi, [esp+14h+hWnd]
.text:00401659 push edi
.text:0040165A push 0FFFFFFEBh ; nIndex
.text:0040165C push esi ; hWnd
.text:0040165D call ds:GetWindowLongA
.text:00401663 mov eax, [esp+18h+arg_4]
.text:00401667 sub eax, 110h ;is this the WM_INITDIALOG message?
.text:0040166C jz loc_0_401895 ; disable controls in response to wm_initdialog


CASE uMsg == WM_INITDIALOG

.text:00401895 loc_0_401895: ; CODE XREF: sub_0_401650+1Cj
.text:00401895 mov edi, ds:GetDlgItem
.text:0040189B push 0 ; nCmdShow == SW_HIDE
.text:0040189D push 3F6h ; nIDDlgItem == Split Into Equal Tracks (Button)
.text:004018A2 push esi ; hDlg
.text:004018A3 call edi ; GetDlgItem
.text:004018A5 mov ebx, ds:ShowWindow
.text:004018AB push eax ; hWnd
.text:004018AC call ebx ; ShowWindow
.text:004018AE push 0 ; nCmdShow == SW_HIDE
.text:004018B0 push 3FCh ; nIDDlgItem == Import .CUE file (Button)
.text:004018B5 push esi ; hDlg
.text:004018B6 call edi ; GetDlgItem
.text:004018B8 push eax ; hWnd
.text:004018B9 call ebx ; ShowWindow
.text:004018BB push 0 ; nCmdShow == SW_HIDE
.text:004018BD push 3FDh ; nIDDlgItem == Export .CUE file (Button)
.text:004018C2 push esi ; hDlg
.text:004018C3 call edi ; GetDlgItem
.text:004018C5 push eax ; hWnd
.text:004018C6 call ebx ; ShowWindow
.text:004018C8 push 0 ; lParam
.text:004018CA push 100h ; wParam
.text:004018CF push 0C5h ; Msg
.text:004018D4 push 3E9h ; nIDDlgItem
.text:004018D9 push esi ; hDlg
.text:004018DA call ds:SendDlgItemMessageA
.text:004018E0 push offset aFileTrack ; lpString
.text:004018E5 push 3E9h ; nIDDlgItem
.text:004018EA push esi ; hDlg
.text:004018EB call ds:SetDlgItemTextA
.text:004018F1 pop edi
.text:004018F2 pop esi
.text:004018F3 mov eax, 1
.text:004018F8 pop ebx
.text:004018F9 add esp, 0Ch
.text:004018FC retn 10h

These controls can all be easily made visible by patching in a SW_SHOW (05) for the push nCmdShow parameter for each control. At this point, the controls are visible but they lack functionality. The task now becomes to find out *if* the handler code for each of these buttons exists in the DEMO. In order to determine this, I had a look at the WM_COMMAND message routing code in the dialog procedure. You'll notice that it uses a table to index the different procedures for each button and control.

SPLIT TAB DIALOG PROCEDURE

.text:00401672 dec eax
.text:00401673 push ebp
.text:00401674 jnz loc_0_401889 ; exit DlgProc
.text:0040167A mov ecx, [esp+1Ch+arg_8]
.text:0040167E mov eax, ecx
.text:00401680 and eax, 0FFFFh
.text:00401685 add eax, 0FFFFFC16h
.text:0040168A cmp eax, 1Ah
.text:0040168D ja loc_0_401889 ; exit DlgProc
.text:00401693 xor edx, edx
.text:00401695 mov dl, ds:byte_0_401928[eax]
.text:0040169B jmp ds : off_0_401900[edx*4] ; Look up handler in table

WM_COMMAND HANDLER JUMP TABLE

.text:00401900 off_0_401900 dd offset loc_0_4016B4 ; DATA XREF: sub_0_401650+4Br
.text:00401900 ; Browse
.text:00401904 dd offset loc_0_4016D8 ; Add Time
.text:00401908 dd offset loc_0_40183A ; Track Name
.text:0040190C dd offset loc_0_401722 ; Field Info
.text:00401910 dd offset loc_0_4016C6 ; Destination Folder
.text:00401914 dd offset loc_0_4016A2 ; Grab Winamp Position
.text:00401918 dd offset loc_0_401741 ; Create Tracks
.text:0040191C dd offset loc_0_401753 ; Remove Time
.text:00401920 dd offset loc_0_4017E0 ; Clear List
.text:00401924 dd offset loc_0_401889 ; Import and Export from CUE & split into equal segments (all disabled items)
.text:00401928 byte_0_401928 db 0, 2 dup(9), 1, 9, 2, 3, 9 dup(9), 4, 5, 3 dup(9), 6
.text:00401928 ; DATA XREF: sub_0_401650+45r
.text:00401928 db 2 dup(9), 7, 8, 2, 0Dh dup(90h)

From this you'll note that all 3 of our disabled functions are routed to a "do nothing" handler routine...

DO NOTHING ROUTINE FOR DISABLED FUNCTIONS

.text:00401889 pop ebp
.text:0040188A pop edi
.text:0040188B pop esi
.text:0040188C xor eax, eax
.text:0040188E pop ebx
.text:0040188F add esp, 0Ch
.text:00401892 retn 10h


--END PART 1---

---BEGIN PART 2---

This does not necessarily mean that the code for the missing functions does not exist, but the fact that there are no additional unused table entries seems a little suspicious to me. Also consider that there is no alternate route of processing the WM_INITDIALOG message (ie. those controls are *always*disabled during the initialization and there is no apparent flag or other check which might prevent them from being hidden). In order to further make a resonable determination of weather this code could exist in the DEMO version, I considered that in order to import / export .cue files, the app would almost certainly have to use the common dialog functions GetOpenFileName and GetSaveFileName. Looking in IDA, there are only 2 instances of GetOpenFileName and 1 instance of GetSaveFileName and these are strictly related to loading the source / destination .mp3 files. As far as I know, these are the only functions that allow a user to easily navigate directories to choose a specific file type from their HD so the fact that the only instances of these functions refer to loading the source / destination files makes it seem highly improbable that the code for these hidden functions is present in the DEMO version. I'm sure this isn't what you wanted to hear, but I thought I'd share my experiences with the thought process involved in working on a functionally disabled target . Of course, you could add this functionality in yourself. If you knew the structure of a .cue file, it probably wouldn't be that difficult

---END PART 2---

Regards,
Clandestiny

Hello and thanks Clandestiny for your posts.

Il'll try it.

Buttons and something like this is more dificult to me because I've patched some software changing jmp, jnz and jz.....

Again thanks from spain.