Crypto or not?
 

it's the second time I see this sort of code and I don't know if this is a crypto algo or not. :(

It's always a function wich is call several times.
example :

0041901F |> 8B4C24 14 /MOV ECX,DWORD PTR SS:[ESP+14]
00419023 |> 8D441C 20 LEA EAX,DWORD PTR SS:[ESP+EBX+20]
00419027 |. 0FB63C08 |MOVZX EDI,BYTE PTR DS:[EAX+ECX]
0041902B |. 33D2 |XOR EDX,EDX
0041902D |. 8BF0 |MOV ESI,EAX
0041902F |. 90 |NOP
00419030 |> 8B4424 40 |/MOV EAX,DWORD PTR SS:[ESP+40]
00419034 |. 0FB60402 ||MOVZX EAX,BYTE PTR DS:[EDX+EAX]
00419038 0FAFC7 IMUL EAX,EDI
0041903B |. 85C0 ||TEST EAX,EAX
0041903D |. 74 13 ||JE SHORT 00419052
0041903F |. 8BCE ||MOV ECX,ESI
00419041 |> 0FB629 ||/MOVZX EBP,BYTE PTR DS:[ECX]
00419044 |. 03C5 |||ADD EAX,EBP
00419046 |. 8801 |||MOV BYTE PTR DS:[ECX],AL
00419048 |. C1E8 08 |||SHR EAX,8
0041904B |. 83C1 01 |||ADD ECX,1
0041904E |. 85C0 |||TEST EAX,EAX
00419050 |.^ 75 EF ||\JNZ SHORT 00419041
00419052 |> 83C2 01 ||ADD EDX,1
00419055 |. 83C6 01 ||ADD ESI,1
00419058 |. 83FA 08 ||CMP EDX,8
0041905B |.^ 7C D3 |\JL SHORT 00419030
0041905D |. 83C3 01 |ADD EBX,1
00419060 |. 83FB 08 |CMP EBX,8
00419063 |.^ 7C BA \JL SHORT 0041901F

Someone recognize this algo and it is possible to reverse it?

Thank you :)

lol, your post is crypto...

Based on this nobody can tell, use KANAL in PEID to see if it uses any crypto...

You can use Kanal, as MrAnonymous suggested, to find popular crypto scheme inside the code (unpacked code).

Anyway, for me the code looks as a kind of computation but it's far too easy to state as "crypto algorithm". The part you posted looks like single function but I don't know what's the function tree (upper and lower level). If it's a complete part of an algorithm then it's a great example to write a keygen (assuming it operates on an key data).

My suggestion for analysis: put a breakpoint on 0x419065, take ECX as the pointer and substract few bytes - you should see the result of discussed loop. I can't say how many bytes you should substract from ECX before taking the pointer because it's input value is determined by DWORD PTR SS:[ESP+14] so I can't know it's value.

Regards.

Thank you for your answers.

I'm going to add somethings.

0041901F |> 8B4C24 14 /MOV ECX,DWORD PTR SS:[ESP+14]
This line put 4Ch in ECX, it's a constant.

00419023 |> 8D441C 20 LEA EAX,DWORD PTR SS:[ESP+EBX+20]
00419027 |. 0FB63C08 |MOVZX EDI,BYTE PTR DS:[EAX+ECX]
This lines take a byte in list of 16 bytes which are used in this algo.

After this code there is others loops but for me, it's this algo the first problem.
I don't understand how to reverse it because it use bytes together.

P.S. Peid find CRC32b.

The fragment you posted doesn't calculate CRC32. If PEID has detected its signature then it should give you the reference offset (address) too. Compare the referenced address with the listing area and if it doesn't mach (it shouldn't indeed) then just disassemble the referenced pointer and verify if it's not a mistake or fake signature.

I will repeat the following suggestion: put a breakpoint on 0x419065, take ECX as the late data pointer and substract few bytes (76 decimal? strange value... or maybe its multiplicity? that would give you at least even value) - you should see the result of discussed loop and then I suggest to put a memory access breakpoint on the first byte of the result. You should be a step ahead from revealing the "secret" (or maybe am I dreaming? :confused: ).

If you won't try - you don't win.

Good luck and regards.

I don't understand what you want I do.
I know what the algo do but I don't know how to reverse it.

I converted it in pseudo code, if it can help someone.

byte origine array [8];
byte final array [17];
int cpt1,cpt2,cpt3,cpt4;

for (cpt1=0;cpt1<8;cpt1++)
{
carac = origine[cpt1];
cpt4 = 0 ;
for (cpt2=0;cpt2<8;cpt2++)
{
carac2 = origine[cpt2];
carac2 = carac * carac2;
cpt3 = cpt4;
while(carac2!=0)
{
carac2 = carac2 + resultat[cpt3] ;
resultat[cpt3] = carac2 % 100 ;
carac2 = carac2 div 100 ;
cpt3++ ;
}
cpt4++;
}
}

"I know what the algo do"
That's strange because in the first post you have written:

"Someone recognize this algo and it is possible to reverse it?"
So it looks you don't know (at least for me).

I suggested you to recognize it first, but now you amazed me totally by writting the pseudo code + claiming you "recognize this algo" and at the same time.... asking for help. I'm a little bit lost. You know what does the algorithm do and you don't know how to "reverse it"?

Regards.

Ok, I will try to clear up my problem.
I know what the algo do since that I succeeded in transcribing it in pseudo code. But I do not see how to reverse it.
How to recover the bytes of "origine" starting from the bytes of "resultat".
Do you inderstand what I say?
Sorry not to be very clear. :rolleyes:

carac2 = carac2 + resultat[cpt3] ;
????
the original value of resultat[cpt3] is...?
You can try with simple values to test how it works.

Don't you think the while-loop may become infinite ?

Nevertheless I sujest you, if you want reverse only few values, to write a bruteforce loop comparing the result with the value you want to reverse.

while(carac2!=0)
{
carac2 = carac2 + resultat[cpt3] ;
resultat[cpt3] = carac2 % 100 ;
carac2 = carac2 div 100 ;
cpt3++ ;
}


Are you sure you did it well?
carac2 = carac2 div 100 - I'm assuming I see the division, rigth? Then go study math - the division will never give you 0 (in the integers ring) - and you check for 0 in while loop - endless cycle.

Probably Djneo posted a strict PDL description than a real pseudo code logic (sorry, but the posted idea itsn't logic for me).

Personally I think the problem is not only in the last condition (while loop) but whole presented code. What about cpt3 and cpt4 values? They are actually doing nothing.

That's all from me in this thread since Startrek related problems are far too much for my poor brain :).

cpt3 and cpt4 are pointers.
cpt4 has no problems, but cpt3 well because of the while loop.
What's the upper limit of cpt3 ?

cpt3 and cpt3 don't play any role because cpt2 won't reach 0 value. If you ask what is the limit of cpt3 then it doesn't have any. It should be set to 0 on each "while" condition execution but the code is a little bit strange and it goes into endless loop.

There's something here I don't understand...
Let's assume carac2 enters the loop with 1000.
After line 1, let's say 1050.
Line 2 will produce 50, line 3 will produce 10.
In the second iteration, line 1 might give 67 (added 57 this time), line 2 = 57, line 3 = ..... 0.

Each iteration adds a (small) amount to carac2, then shifts it right by 2 decimal places, eventually resulting in 0. Does it not?
:confused:

In the second iteration, line 1 might give 67 (added 57 this time), line 2 = 57, line 3 = ..... 0.

DAMN... DAMN... DAMN ONE MORE TIME. It is me who should go and study comp.sci. This is the integer arithmetic... Fuck.

OK,
carac2 = carac2 + resultat[cpt3] ; (1) - you say, for example, carac2 will be 67. OK. Fine.
Then:
resultat[cpt3] = carac2 % 100 ; (2)
the operation "%" in C/C++ is the same as mod in number theory.
So, 67 mod 100 = 67 - not 57 as you are trying to say if I understood you properly, of course...
Then:
carac2 = carac2 div 100 -> carac2 = 67/100 - this is normally not 0, of course, BUT this is computer arithmetic and the result is rounded up, so it will be floor(67/100) which is 0 indeed. So you are partially right and I'm wrong. My bad.

Of course line (2) will result in 67, my mistake :D
67 % 100 -> 67
67 / 100 -> 0 (integer)

Now one other strange thing in the algo - where do the "resultat[cpt3]" values come from?