Hi Folks,

iam targeting a vb3 app and already disassembled it with dodi-disassembler. i found the following code:

[...]
Dim l0070 As New Field
On Error GoTo LE038
If gv01EE = 2 Then
Panel3D1.Visible = True
Exit Sub
End If
[...]

These are the corresponding bytes:

45 49 B6 7E 38 05 32 49 86 2A 34 00 F8 37 6D 39
00 35 2C 00 35 49 3D 38 B0 0E 6E 4A 38 00 72 4C
09 C0 35 49...

I already figuered out, that
494B- No Spaces
4948 = 1 Space
4945 = 2 Spaces
4942= 3 Spaces
4935 = 4 Spaces
4932 = 5 Spaces (thanks to _duke_)

but, hrmm, i thought the compare (the one i want to kill) with
the 2 would have some corresponding byte-code, like 02h.
But its not there. could someone help me by decoding the bytes?

ah i forgot:
EC 35 = End if

Regards!
vbdisease

Are you sure thats thats the right code for that pcode area? Haha VB3 newline tokens are quite funny. I am surprised Microsoft got away as much as they did with those little bastard tokens!

Snatch

jo snatch,

its the right bytecode, for sure! But i missed some bytes, sorry.
here they are:

45 49 B6 7E 38 05 32 49 86 2A 34 00 F8 37 6D 39
00 35 2C 00 35 49 3D 38 B0 0E 6E 4A 38 00 72 4C
09 C0 35 49 4A 1F F8 05 45 49 EC 35 ...

so, 4A 1F F8 05 = Exit Sub, nice to know..hehehe.
I also found, that 34 00 = variable gv01EE.

but where the hell hides the compare with 02h??

vbdisease

------
i prefer tolkien, not tokens )

vbdisease

Best bet is what i do with Java .class files i want to modify.

I Change a byte in the token area and then run it throught the decompiler. Then Compare the decompiled version against the original decompiler version with a text comparer (the one with xtgold is fine).

In this manner i can find the spot to change. I would change the bytes that are 3X to one up or one down. i.e. 37 to 36.

Then run it through the decompiler and check the change in the code.

Note some of the changes will cause the decompiler to crash or stop decoding. Still look at the decompiled file to examine where it got up to.

Hope this helps.
Peterg70

45 49 B6 7E 38 05 32 49 | 86 2A 34 00 F8 37 6D 39
00 35 2C 00 | 35 49 3D 38 B0 0E 6E 4A 38 00 72 4C
09 C0 35 49 4A 1F F8 05 45 49 EC 35 ...

Clearly the bytes between the |'s are your compare bytes. I am guessing that it points to constant data elsewhere and that is where the decompiler gets the 2 from. Maybe try to figure out how those could be possible address references? That is the only thing I can think of because as far as I know VB does not do weird things with immediate data. So 0x02 should be 0x02.

Snatch

I did this a long time ago. (A VERY long time ago). As I remember, the 02 is not kept as 02, but as a memory address, in which the 02 is stored.

More importantly, I never needed to worry about it. The point of attack I used was the "gv01ee =". I know for sure it is a one byte change to make the "=" into a "<>"; what I don't remember is what the byte change is. If this is a sufficient method for you, I could possibly (emphesis on possibly) look it up, but no guarantees that I even still have my notes.

Also, you could easily make two programs, one with a line:
"x=y", and one with a line "x<>y", then compile both. The one byte difference should be obvious.

If I'm off base with this, then...."NEVER MIND!"

Good luck,

SargeG

thanks ppl,

finally i found the b*tch.

as snatch mentioned its between these bytes:

| 86 2A 34 00 F8 37 6D 39 00 35 2C 00 |

The first four bytes refer to the variable used,
the next byte is the smelly one:

F8 = 2

I played a bit with the byte (sounds funny ) and found the following:

F8 = 2
ED = 1
E5 = 0

with this my app died..hehehe...
it would be great to have more token revealed..how knows...maybe sometime YOU have to crack a vb3 app!
SargeG, if it takes not to much time, i would be interested in that =/<> change thingie, sorry dont have vb3 to compile.

regards
vbdisease