Patching.the.WinLicense.Is_Registered.Dwords.in.v2.0.6.5__SND

jasonwjs

Finding the Winlicense Is_Registered dwords and patching them in Winlicense 2.0.6.5.
by quosego/snd
------------------------------------------

Intro;
Most Winlicense protected apps simply rely on Winlicense to check for registration.
They always do this using the WL API's and occasionally with some custom macro's.
You can easily modify the API to return eax=1 and be done with it, however this usually
does not fix the macro's/other custom checks or Trial checks. You can patch these as
well and this is what I usually did. However it seems Winlicense only has two dwords it
checks to see if it's registered, ** sure that these hold the correct dwords
registers the entire app with only a two dword patch.

Update Notes;
Oreans has updated the dwords, and to be honest not as lame as the other updates. This time
I'll have to guide you through the Virtual Machine to obtain the correct is_registered
dwords. Since they're now no longer fixed and available in normal code. But don't worry,
it'll be painless. :)

Finding the dwords;
Not much updates here, run the app and search for the following strings in the WL section.

1)
B8 01 00 00 00 89 85 ?? ?? ?? ?? C7 85

Finds the following code;
MOV EAX,1                                                                                                // Not important
MOV DWORD PTR SS:[EBP+xxxxxxxx],EAX                                                // Not important
MOV DWORD PTR SS:[EBP+xxxxxxxx], {Variable_1)                        // EBP+xxxxxxxx holds the dword
(The EBP+xxxxxxxx in the third line of the found code is the location of the first
is_registered dword)

{Variable_1} is a random value, which WL checks for to see if it's not registered, however
the correct value is not 2 here, but also random. If {Variable_1} equals the stored value then
WL accept the program as unregistered.

2)
00 00 00 00 00 00 00 00 81 BD

Finds the following code;
CMP DWORD PTR SS:[EBP+xxxxxxxx],{Variable_2)
(EBP+xxxxxxxx is the location of the second is_registered dword)

{Variable_2) is in this case, the value the second is_registered dword needs to be. If the
stored second is_registered dword equals {Variable_2) then WL accepts the program as
registered. (If of course the first dword is also valid.)

Put an hardware breakpoint on execute on the found addresses and restart the app. Next
when you stop on these instructions you can read the memory locations which they compare to
or write to. These are the locations were WL stores the is_registered dwords.

Patching the dwords;
In previous versions the correct values of the is_registered dwords were fixed (2 & 500),
however now they're randomly generated and using the information discussed in the previous
paragraph you only know the correct value of the second dword. As for the first dword you
only know the correct dword to make it unregistered. Which pretty much helps you nothing at
all.

I will now explain how you can trace the Oreans virtual machines to get the correct first
is_registered dword. As you might know there are two possible Virtual Machines, Risc and
Cisc. Since they differ in complexity and execution methods, I've made two tuts to find the
first is_registered dword. Use the correct one for the correct VM. A simple rule is if the
VM is located inside the WL section it's cisc, else it's risc.

Winlicense accesses and compares the correct first is_registered dword with the stored one
the second time it accesses it in the VM. So first HW bp on acces the location of the first
dword. Then restart and press shift-f9 until you hit the code were it writes the
{Variable_1). (See 1) in Finding the dwords.) Next press f9 and you'll be at the first access
in the VM, next press f9 and you're at the second access. Next it'll compare the stored first
is_registered dword with the correct one. Now you'll have to choose between the cisc or risc
tut.

Comparing in cisc Virtual machine;

- Press F7 to arrive at the main lods handler, you can see {Variable_1) in the stack.
- Put a breakpoint here and f9 until you see {Variable_1) in ecx
- eax now holds the correct is_registered dword. Store this at the first is_registered dword
  location and your app will be registered. (If you also fix the second of course.)

You'll now prolly think, well that's nice but since I'm in this screwy virtual machine you
better tell me why this actually works. Simple see the unobfuscated handler below which
compares values in the cisc VM;

POP EAX
POP ECX
CMP ECX,EAX
PUSHFD
JMP {Main_Handler)                                        // All handlers return to the main handler.

Since your {Variable_1) was pushed first it will be in ecx, and eax must hold whatever it is
compared to. Junk VM code never writes stack values to eax or ecx so {Variable_1) can never
get to ecx unless it's intended. (The above handler is unobfuscated, it can take extremely long
if you try to trace and find this handler yourself.)

Comparing in risc Virtual machine;

- Trace until {Variable_1) which is retreieved form its store location is located at second
  dword of the stack, should be a pretty short trace 20 instructions max.
  
00391FF8              7EAC5730                <-- pushed is_registered dword {Variable_1)
00391FFC              00000000                <-- begin of stack

- Hardware bp that stack address on access (here 391ff8), and run. When it breaks the correct
  is_registered dword is now located in the dword above the old one in the stack. Store this
  dword at the first is_registered dword location and your app will be registered. (If you also
  fix the second of course.)

Once again you might ask your self and why does this work?? And again once you know the
unobfuscated code all becomes clear;

MOV ECX,DWORD PTR DS:[ESI]                        <-- get {Variable_1)
MOV EBX,DWORD PTR DS:[ESI-4]                <-- get correct
PUSH DWORD PTR DS:[EDI+70]
POPFD
CMP ECX,EBX                                                        <-- compare
PUSHFD

Well that's all, after you've unpacked the app just set the first and second dwords correctly
and everything will once be registered. Or use an inline to fix these dwords after the app has
been unpacked in memory.

Final notes;
Once again Winlicense can crypt certain blocks of code using dwords written when an keyfile is
present, these will not be decrypted and can crash. Also the Get_name API will crash!
Since there's no name you can put a ret 0c in it's place which most apps will accept or
patch it to return a name.

Have fun,
q.

PS: @Oreans, Your VM are belong to us!! ;)

Thnx to a certain provider of executables.

------------------------------------------
实在是不解哦，高人来看一下啊