• Welcome to Valhalla Legends Archive.
 

[VB6] Reverse Engineering Attempt

Started by Don Cullen, November 19, 2005, 11:59 PM

Previous topic - Next topic

Don Cullen

Basically, I'm trying to reverse engineer my Sorenson Videophone with extremely limited experience in reverse engineering.

I'm deaf, and I got a videophone for free from www.sorenson.com. Before ya'all jump at it thinking you can get free videophones, they tend to screen people by sending people fluent in ASL (American Sign Language) over to install the videophone for you- if they discover the applicant had lied about being deaf upon attempting to converse with them via ASL, they pretty much revoke the application, and leave. Just FYI, so unless you're fluent enough in ASL to make them think you're deaf, save ur time.

Anyway, back to the issue. The videophone is very limited in functionality- it cannot take messages, it cannot broadcast anything other than what it gets via its built in cam.

So what I want to do is code a program that will be able to take calls from Sorenson videophones, take messages, record who called via obtaining their name and number (which is included in the very first packet recieved), etc, etc, etc.

I've coded a battle.net binary bot, so I have some basic knowledge. But I'm not sure how they figured out all this reversal stuff for BNET. Hence my coming here.

Here's the packet:

Dumping packet...
StrToHex Dump:
03 00 01 30 08 02 36 F1 05 04 04 88 18 88 A5 28 0A 44 6F 6E 20 43 75 6C 6C 65 6E 7E 01 12 05 20 A8 06 00 08 91 4A 00 04 01 40 09 00 44 00 6F 00 6E 00 20 00 43 00 75 00 6C 00 6C 00 65 00 6E 22 C0 B5 00 53 56 12 53 6F 72 65 6E 73 6F 6E 20 56 69 64 65 6F 70 68 6F 6E 65 0A 31 2E 36 2E 38 30 30 2E 38 30 30 50 B5 00 53 56 7E 53 49 6E 66 6F 3A 30 30 30 34 44 6F 6E 20 43 75 6C 6C 65 6E 7C 30 30 30 37 2B 31 20 28 32 30 39 29 20 34 37 37 2D 32 30 32 34 7C 30 30 32 30 30 30 30 30 30 30 30 30 7C 30 30 30 38 36 39 2E 32 32 35 2E 39 31 2E 32 31 35 7C 30 30 31 38 30 30 3A 30 66 3A 33 64 3A 66 66 3A 35 38 3A 34 61 7C 30 32 36 30 53 6F 72 65 6E 73 6F 6E 20 56 50 31 30 30 20 2D 20 41 52 4D 39 54 44 4D 49 7C 00 C0 A8 00 65 06 B8 00 02 B2 1E 1E 8C 44 A9 12 15 C4 6B C8 61 86 47 75 00 CD 0D 98 00 07 00 45 E1 5B D7 3B E3 11 00 02 B2 1E 1E 8C 44 A9 12 15 C3 6B C8 61 86 47 75 01 00 01 00 01 00 01 00 01 00 01 40 10 80 01 00
ASCII Dump:
.06ñˆˆ¥(.Don Cullen~ ¨.'J.@ .D.o.n. .C.u.l.l.e.n"Àµ.SVSorenson Videophone.1.6.800.800Pµ.SV~SInfo:0004Don Cullen|0007+1 (209) 478-2024|002000000000|000869.225.91.211|001800:0f:3d:ff:58:4a|0260Sorenson VP100 - ARM9TDMI|.À¨.e¸.²ŒD©ÄkÈa†Gu.Í.˜..Eá[×;ã.²ŒD©ÃkÈa†Gu.....@€.
End of packet dump.
Dumping packet...
StrToHex Dump:
03 00 00 36 08 02 36 F1 5A 08 02 80 90 7E 00 26 05 25 80 06 00 08 91 4A 00 04 11 18 11 00 02 B2 1E 1E 8C 44 A9 12 15 C3 6B C8 61 86 47 75 01 00 01 40 10 80 01 00
ASCII Dump:
..66ñZ€?~.&%€.'J..²ŒD©ÃkÈa†Gu.@€.
End of packet dump.


The stuff I recognize in the ASCII dump are:

Don Cullen (Name of the person who is calling)
Sorenson Videophone.1.6.800.800 (Caller's videophone software) (and version I think)
1 (209) 478-2024  (That's the phone number of the Caller. If a non-sorenson videophone model is calling, it'll be an IP address)
69.225.91.211 (Caller's Videophone's IP address)
Sorenson VP100 (That's the videophone name/Model #)

I don't recognize anything else... How would I go about in reverse engineering this?

Oh yes, before I forget to mention this... You'll see two data dumps. The first packet is the connection packet when I tell my videophone to call my laptop, the second one is the disconnection packet when I tell my videophone to hang up.

Thanks for any advice, suggestions, help, tips, etc in advance!

[Edit]
After staring at the dumps for a while, I noticed both packets start with 03 00 so I would assume all packets have 0x03 headers...  and have 0x00 null terminators... I'm not sure where the packet length byte would be though.
[/Edit]
Regards,
Don
-------

Don't wonder why people suddenly are hostile when you treat them the way they shouldn't be- it's called 'Mutual Respect'.

dxoigmn

#1
Hmm looks like everything is in network byte order/big endian (opposite of what battle.net uses). The format looks to be:

(WORD) Id or Magic or ?
(WORD) Length (full length including header)
(VOID) Data

Don Cullen

#2
In that case, to process DataArrival would be done by this:

Private Sub ws_DataArrival(ByVal bytesTotal As Long)
    Static PktBuff As String 'Packet Buffer
    Dim Incoming As String
    ws.GetData Incoming, vbString, bytesTotal
    PktBuff = PktBuff & Incoming
    Dim Pkt As BNCSPKT
    While Len(PktBuff) > 3
        Pkt.intPktLen = GetWord(Mid$(PktBuff, 3, 2))
        If Len(PktBuff) < Pkt.intPktLen Then Exit Sub
        ParsePacket (Left(PktBuff, Pkt.intPktLen))
        PktBuff = Mid(PktBuff, Pkt.intPktLen + 1)
    Wend
End Sub


Which is pretty much what I do for my bnet bot, and to obtain the header, I just do:

    PktDeBuf.SetData (PacketData)
    PacketID = PktDeBuf.StripHeader


PktDeBuf is a class, the respective subs' code is:


Public Function StripHeader() As Byte
    StripHeader = Asc(Mid(strBuffer, 2, 1))
    strBuffer = Mid(strBuffer, 5)
End Function

Option Explicit
Private strBuffer As String

Public Sub SetData(Data As String)
    strBuffer = Data
End Sub


To give proper credit where due, the Packet Debuffering class was coded by HdxBmx27.

Also, would I be correct in thinking all packets would begin with 0x03 since both packets start with 0x03? And would I be mistaken to assume that the WORD following 0x03 is the ID you're referring to?

What do you think? Also, thanks for responding. It's most certainly appreciated! :)
Regards,
Don
-------

Don't wonder why people suddenly are hostile when you treat them the way they shouldn't be- it's called 'Mutual Respect'.

dxoigmn

#3
The first WORD is probably just "magic" (always 0x3000). The WORD after that is the length of the entire packet. What is interesting is that the next couple of bytes are the same for both packets (08 02 36 F1). There are a lot of strings in there with a length byte before them (these are usually called pascal strings). Namely these strings:


  • Don Cullen
  • SInfo:0004Don Cullen|0007+1 (209) 477-2024|002000000000|000869.225.91.215|001800:0f:3d:ff:58:4a|0260Sorenson VP100 - ARM9TDMI|

The byte sequence 45 E1 5B D7 is the ip (69.225.91.215) in the above text. I'm sure you can figure more just by staring at it and looking at lengths of strings and information about the phone and such.

Don Cullen

#4
I just saw another string I recognized while staring at that:

00:0f:3d:ff:58:4a

That's the MAC of the caller's videophone... You recognize anything else?

I did some coding to attempt to extract the data inside the packet, as as my first step, I'm trying to extract the header.

I got this:

Dumping packet...
StrToHex Dump:
20 33
ASCII Dump:
3
End of packet dump.


When I did:

Public Sub ParsePacket(ByVal PacketData As String)
    PktDeBuf.SetData (PacketData)
    PacketHeader = PktDeBuf.rWORD
    DumpPacket Str(PacketHeader)
    DumpPacket PacketData
    PktDeBuf.ClearData
End Sub


It doesn't make sense, the WORD it gets should be 03 00, not 20 33...

Here's the rWORD function:

Public Function rWORD() As Long
    Dim lReturn As Long, strTMP As String
    strTMP = Left(strBuffer, 2)
    Call CopyMemory(lReturn, ByVal strTMP, 2)
    rWORD = lReturn
    strBuffer = Mid(strBuffer, 3)
End Function
Regards,
Don
-------

Don't wonder why people suddenly are hostile when you treat them the way they shouldn't be- it's called 'Mutual Respect'.

dxoigmn

Note that you have to beware of endianess. Since you're using VB, you're probably on a little-endian system. Therefore, you need to convert everything to big-endian.

Don Cullen

Regards,
Don
-------

Don't wonder why people suddenly are hostile when you treat them the way they shouldn't be- it's called 'Mutual Respect'.

dxoigmn


Don Cullen

I'm lost... I think I'm way out of my depth.

[flattery]Compared to you, I am but a mere mortal, and people like you laugh at our puny attempts to dabble in arcane manipuliations only masters like you can comphrend[/flattery]

That was a compliment by the way.

To sum it up, thanks for helping. Can you elaborate on that, if its not too much trouble? I'm trying my best to understand.

Thanks!
Regards,
Don
-------

Don't wonder why people suddenly are hostile when you treat them the way they shouldn't be- it's called 'Mutual Respect'.

dxoigmn

Well you know how when you're looking at a packet log of battle.net traffic you need to look at everything backwards:


FF 25 08 00 78 56 34 12

Magic: FF
Id: 25
Length: 08 00 => 00 08
Data: 78 56 34 12 => 12 34 56 78


However, this protocol is big-endian (opposite of what battle.net uses), so we don't have to look at everything backwards:


03 00 01 30

Id(?): 03 00
Length: 01 30


Since you're using a buffer that expects everything to be little-endian, then you're going to be reading everything backwards. So GetWord(Mid$(PktBuff, 3, 2)) will probably return 0x3001, when what you really want it to return is 0x0130. If you do htons(GetWord(Mid$(PktBuff, 3, 2))), then this will convert the word from little-endian to big-endian, thus giving you a value of 0x0130.

Don Cullen

Public Sub ParsePacket(ByVal PacketData As String)
    PktDeBuf.SetData (PacketData)
    PacketHeader = htons(PktDeBuf.rWORD)
    DumpPacket Str(PacketHeader)
    DumpPacket PacketData
    PktDeBuf.ClearData
End Sub

I'm trying to get PacketHeader to contain 0x3000 but it keeps not returning that, I keep seeing:

20 37 36 38

When I want:

StrToHex Dump:
03 00

Advice?
Regards,
Don
-------

Don't wonder why people suddenly are hostile when you treat them the way they shouldn't be- it's called 'Mutual Respect'.

LivedKrad

Why would your dump output a four byte value when requesting to extract a two byte value? Code bug or something that we can't see?