Register

Welcome to the RDI-Board Community.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed.


Donate Now Goal amount for this month: 100 EUR, Received: 100 EUR (100%)
Donate to support this site...

Results 1 to 8 of 8
  1. #1
    Junior Member Friend
    RDI - Board Default Avatar

    Join Date
    Jun 2008
    Posts
    29
    Posts Thanks / Likes

    Default emulator - Linksat & Max


    Just to get out of a long thread (1000+ posts) on the LinkSat Info needed. This thread is to discuss technical issues and ideas to emulate the servers so we can try to prevent the two weeks long down time everyone experienced. This thread is not to solve people problems of not able to view $ channels.

    Here is a summary of what I have found so far.

    LinkSat and MAX and other clones basically keep the key file stored within the box itself. In theory, it should not need constant internet connection as the keys already in the box. In reality, it does need the net and it will freeze in few seconds if you remove the LAN cable, this is because the box sends requests to a server somewhere every 10 seconds or so.

    I have connected my STB to go to the net via the PC, placed packet tracer and other tools on the PC to trap the network card, I can now see all data coming in and out of the box. The STB sends 67 bytes UDP packet to the server IP, the server responds back with UDP reply, the STB sends another message with different data, the server responds back with a reply, then the box works. 10 or so seconds later the same thing happens, the bytes in and out are very similar except for some reference numbers. I believe it is possible that we can emulate this setup. It seems these requests are just authorization from the server to continue working, and possibly to collect data on the server such as statistics on the channels people viewing. I need more time to study and analyze the packet, but help is needed.

    I believe if some more technical based members here that are interested and have knowledge in TCP packets, all of us can continue work on this to really discover if it is really just an authorization or these bytes are truly needed for operation. From what I saw so far, it seems they are not. And as what happened before, once the UDP server sending this authorization came back online, everyone was able to see N*Sat, as seems these N*Sat do not change their codes very often to a point that even after two weeks of down time, the old key file K86 was working again. It does not make sense that the UDP packets are sending keys on every connection every 10 seconds for each channel as then there will be no need for the key file to be downloaded anyway. If this is the case, then we can write simple software setting on PC at home, give this PC the IP that STB is looking for, and have this software reply back with the UDP needed. In theory, this should work and will prevent down time of the server, and the keys can be downloaded manually from web sites on the internet.

    This is of course not to underestimate what the server guys been doing to fix there problems, they have done great job to come back online, but as all of paid $$ for these boxes, we don’t want to end up with a dead box. If I can update the keys manually, I should not need a server connected all the time.

    If anyone is interested to help out in decoding this behavior and at least understand how and why the STB keep sending UDP requests every 10 seconds, please do reply here or PM and we can build a technical team to follow up on this issue. PC software is almost complete, just bending the UDP analysis.



  2. #2
    Byte Stalker Mentor
    Join Date
    Feb 2004
    Location
    Planet Earth in Universe
    Posts
    939
    Posts Thanks / Likes

    Default

    Good work m8, that's seems logical! The network connections have two purposes not only to get keys if needed(should not be in regular interval) & to get data(how many are using the rcv & what particular channels they are always viewing). Some members who are expert on this things can patch the software itself so the receiver will function without network connections.

    The firmware is like a built-in spyware taking data(as mentioned above) to be transmitted to the server. And its easy for them to identify you since you got a fix ip address when using adsl/dsl.
    ************************************
    The more we learn things the more we hunger for more! That's human nature I guess!

  3. #3
    Junior Member Friend
    RDI - Board Default Avatar

    Join Date
    Jun 2008
    Posts
    29
    Posts Thanks / Likes

    Default

    That could be another approach: patch up the firmware so it does not sends or expect UDP packet to operate. Unfortunately, I don’t have much experience with this, my field is TCP/IP analysis and tracking and software programming. I can emulate their server once I complete the analysis of the packets being sent and received every 10 seconds and I can write the PC software to receive and send back the packets.

    I don’t mind the server people collecting data of which channels being viewed, it does not affect us really, the problem is that the STB must be able to receive back a reply otherwise it wont use the key stored to open the channel. Basically, at any time if these guys got stopped or they decided to stop their operations/servers, the box is dead even if it has a good key file.

  4. #4
    ahmed_r
    Guest
    RDI - Board Default Avatar

    Default

    I think if we just could open the bin file and change the IP address of the server and make it to any local computer on the network and install a small program that simulate the action on the server.

    I mean this program will send the same packages even if we do not understand what are those packages are.

    What do u think about that?

  5. #5
    Junior Member Friend
    RDI - Board Default Avatar

    Join Date
    Jun 2008
    Posts
    29
    Posts Thanks / Likes

    Default

    Quote Originally Posted by ahmed_r View Post
    I think if we just could open the bin file and change the IP address of the server and make it to any local computer on the network and install a small program that simulate the action on the server.

    I mean this program will send the same packages even if we do not understand what are those packages are.

    What do u think about that?

    The packets are not exactly the same. Could be time stamped and this causes the bytes to be slightly different on each session. I think understanding and breaking down the bytes being sent and recv will help a lot. Though it can tested before even changing the bin file itself to make sure it will work by setting up two loal network, one being the STB while the other is the PC with the real IP the STB is looking for and router in between to route the packets, then copy exactly the UDP being sent from the server and keep sending it back and check if the box will accept it.

  6. #6
    Junior Member Junior
    RDI - Board Default Avatar

    Join Date
    Jul 2008
    Posts
    3
    Posts Thanks / Likes

    Default

    Dear All,
    I do agree that the keys are not need to decode the channels. I did lots of invesigation to understand the communication between receiver and the server. What I found is the following. Basically there are three types of messages; two of them are UDP (ECM (67 bytes) and EMM (47 bytes)messages from port 1313 to port 80) and one is TCP (For software updates and keys download TCP port 3470 to 3470). ECM are used to decode DVB stream and EMM are used to control SIM cards:-

    ECM messages are 67 bytes UDP from 1313 to port 80
    struct OpenSatCommandTag{
    uchar Command; // Always 0x47
    ushort PID; /* MNET 0x0223 547
    SHOWCimena 0x021D 541
    SHOWTime 0x0208 520
    ART 0x020A 522

    uchar Reserved1[5]; // 0x00 0x00 0x00 0x00 0x00
    ushort SID;
    ushort CRC;
    uchar Reserved2[3]; // Always 0x36 0x35 0X00
    uchar ECM[52]; // Full ECM message starting with either 0x80 or 0x81
    }__attribute__((packed)) ;
    typedef struct OpenSatCommandTag OPENSATCOMMAND;

    The server replies:-
    struct OpenSatReplyTag{
    uchar Command; // Always 0x47
    ushort PID; // Most BIT=1
    uchar Reserved1[2]; // 0x00 0x00
    uchar Status; // unknown
    uchar Reserved2[2]; // 0x00 0x00
    ushort SID;
    ushort CRC;
    uchar DCW[16];
    } __attribute__((packed)) ;
    typedef struct OpenSatReplyTag OPENSATREPLY;

    The DCW used to decode the channel.

    EMM messages are 47 bytes UDP from 1313 to port 80 to different server IP with similiar outgoing request. These UDP message doesnot have a reply from the server. According to the specs these messages are used to update SIM card with new keys and are encrypt.


    I managed to build my own Newcamd server to NanoXX server. It is not 100% working now. I still have to figure some unknow bytes and encryptions. I am trying to figure out what are the keys are used for and the greeting messages. Also the greeting messages to the server, which is also used to updated both software and keys.

    The messages are TCP to port TCP 3470 from 3470:-
    Receiver sends:
    Recevier: 47 03 02 00 00 00 00 00 00 00 5a 82 01 00 xx xx xx xx xx xx xx xx xx xx xx xx xx xx which is always constant for one receiver. It seems like serial number or MAC address of the receiver.
    Then the server replies with a message:-
    Server: 47 83 02 00 00 00 00 00 00 00 0a 28 01 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
    which might be CAMkey or encryption key of some sort
    Then another messages for software versions and keys:-
    Server:
    0030 45 55 20 76 31 2e 33 30 20 6b ..s...EU v1.30 k
    0040 35 30 20 2f 20 31 36 20 4a 61 6e 20 30 38 0a 0a 50 / 16 Jan 08..
    0050 31 2e 20 4f 6e 6c 79 20 4b 65 79 73 20 61 72 65 1. Only Keys are
    0060 20 75 70 64 61 74 65 64 0a updated.


    I am still struggling to figure out these messages. I donot have the same free time anymore. Hopefully someone will continue this. If anyone got more info please share.

    My newcamd code is ready and whats left is only to decode the DCW field on the ECM reply message and to supply to the newcamd client.

    Regards


    Toure Kunda

  7. #7
    Junior Member Friend
    RDI - Board Default Avatar

    Join Date
    Jun 2008
    Posts
    29
    Posts Thanks / Likes

    Default

    Quote Originally Posted by tourekunda View Post

    ECM messages are 67 bytes UDP from 1313 to port 80
    struct OpenSatCommandTag{
    uchar Command; // Always 0x47
    ushort PID; /* MNET 0x0223 547
    SHOWCimena 0x021D 541
    SHOWTime 0x0208 520
    ART 0x020A 522

    uchar Reserved1[5]; // 0x00 0x00 0x00 0x00 0x00
    ushort SID;
    ushort CRC;
    uchar Reserved2[3]; // Always 0x36 0x35 0X00
    uchar ECM[52]; // Full ECM message starting with either 0x80 or 0x81
    }__attribute__((packed)) ;
    typedef struct OpenSatCommandTag OPENSATCOMMAND;

    The server replies:-
    struct OpenSatReplyTag{
    uchar Command; // Always 0x47
    ushort PID; // Most BIT=1
    uchar Reserved1[2]; // 0x00 0x00
    uchar Status; // unknown
    uchar Reserved2[2]; // 0x00 0x00
    ushort SID;
    ushort CRC;
    uchar DCW[16];
    } __attribute__((packed)) ;
    typedef struct OpenSatReplyTag OPENSATREPLY;

    The DCW used to decode the channel.
    Hi Toure

    Thanx for sharing this.

    I am assuming you got these C functions from the source of the ot the box engine itself.

    From this data, it seems the DCW is needed and is variable, which means that we MUST have a reply and even if we did an emulator from a PC then the reply must include this DCW, and correct data. is this DCW matching the keys inside the key bin file?

  8. #8
    Junior Member Junior
    RDI - Board Default Avatar

    Join Date
    Dec 2009
    Posts
    1
    Posts Thanks / Likes

    Default Great effort - why to decode.....? Just cache it as a first step


    Quote Originally Posted by tourekunda View Post
    Dear All,
    I do agree that the keys are not need to decode the channels. I did lots of invesigation to understand the communication between receiver and the server. What I found is the following. Basically there are three types of messages; two of them are UDP (ECM (67 bytes) and EMM (47 bytes)messages from port 1313 to port 80) and one is TCP (For software updates and keys download TCP port 3470 to 3470). ECM are used to decode DVB stream and EMM are used to control SIM cards:-

    ECM messages are 67 bytes UDP from 1313 to port 80
    struct OpenSatCommandTag{
    uchar Command; // Always 0x47
    ushort PID; /* MNET 0x0223 547
    SHOWCimena 0x021D 541
    SHOWTime 0x0208 520
    ART 0x020A 522

    uchar Reserved1[5]; // 0x00 0x00 0x00 0x00 0x00
    ushort SID;
    ushort CRC;
    uchar Reserved2[3]; // Always 0x36 0x35 0X00
    uchar ECM[52]; // Full ECM message starting with either 0x80 or 0x81
    }__attribute__((packed)) ;
    typedef struct OpenSatCommandTag OPENSATCOMMAND;

    The server replies:-
    struct OpenSatReplyTag{
    uchar Command; // Always 0x47
    ushort PID; // Most BIT=1
    uchar Reserved1[2]; // 0x00 0x00
    uchar Status; // unknown
    uchar Reserved2[2]; // 0x00 0x00
    ushort SID;
    ushort CRC;
    uchar DCW[16];
    } __attribute__((packed)) ;
    typedef struct OpenSatReplyTag OPENSATREPLY;

    The DCW used to decode the channel.

    EMM messages are 47 bytes UDP from 1313 to port 80 to different server IP with similiar outgoing request. These UDP message doesnot have a reply from the server. According to the specs these messages are used to update SIM card with new keys and are encrypt.


    I managed to build my own Newcamd server to NanoXX server. It is not 100% working now. I still have to figure some unknow bytes and encryptions. I am trying to figure out what are the keys are used for and the greeting messages. Also the greeting messages to the server, which is also used to updated both software and keys.

    The messages are TCP to port TCP 3470 from 3470:-
    Receiver sends:
    Recevier: 47 03 02 00 00 00 00 00 00 00 5a 82 01 00 xx xx xx xx xx xx xx xx xx xx xx xx xx xx which is always constant for one receiver. It seems like serial number or MAC address of the receiver.
    Then the server replies with a message:-
    Server: 47 83 02 00 00 00 00 00 00 00 0a 28 01 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
    which might be CAMkey or encryption key of some sort
    Then another messages for software versions and keys:-
    Server:
    0030 45 55 20 76 31 2e 33 30 20 6b ..s...EU v1.30 k
    0040 35 30 20 2f 20 31 36 20 4a 61 6e 20 30 38 0a 0a 50 / 16 Jan 08..
    0050 31 2e 20 4f 6e 6c 79 20 4b 65 79 73 20 61 72 65 1. Only Keys are
    0060 20 75 70 64 61 74 65 64 0a updated.


    I am still struggling to figure out these messages. I donot have the same free time anymore. Hopefully someone will continue this. If anyone got more info please share.

    My newcamd code is ready and whats left is only to decode the DCW field on the ECM reply message and to supply to the newcamd client.

    Regards


    Toure Kunda

    I wonder if you have done all of this effort... If you can make the software emulator to cache the packets (without any decoding) of all types locally, and make it to reply the STB receiver with the suitable (non decoded packet) insteade of the remote sharing server, this will accelerate the STB work and make it work more better. The emulator can also simulate sending packets to the remote share server and update its own cache frequently when the Internet is available.

    Try to think about this approach and let us know !

 

 

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Back to Top