How to sniff data stream that updates a flash aplication?

What makes you believe that the flash application, once running, fetches the scores data from the same server from which it has been loaded? I.e. to see the scores data coming, you should first close all browser windows, start capturing without any capture filter, and then go to the site running the flash application. You'll probably find that the application opens another tcp session to some other server (and maybe tens of other tcp sessions to fetch advertisements, so you'll have to sort out).

Also, what makes you believe that the data are not encrypted, i.e. that you'll be able to reverse-engineer them and get access to the contents?

So As you say I have to see if the application opens another tcp sessions. I don´t know how to do this. If someone could guide me a little bit in that it would be great. I really don´t know if the data will be encrypted this is a personal challenge and I want to make all to achieve it.

First of all you'll have to restart the machine in order to clear the DNS cache. After that, don't open any web browser (and, if possible, no other application either) until you complete the capture. If you cannot restart the machine, you'll have to use other means to obtain hostnames from IP addresses, which would be lengthy and annoying.

Start the capture as described above, wait until the flash application downloads and starts, and then updates the scores, say, twice. Then stop the capture and save it to a file. While capturing, watch for the update times and note them down.

In the capture, look to statistics to see how many tcp sessions have been open during the capture time, and if there are just units (not tens or hundreds), take them one by one and try to find out where they went. The tcp sessions are open towards ip addresses but DNS answers right before should contain these ip addresses as responses to queries for names. So a display filter (not capture filter) like dns or tcp.flags.syn == 1 should show you only packets relevant for such pairing (the DNS query for an fqdn, the DNS response providing a list of IP addresses, and the subsequent TCP SYN packet towards one of the IPs on the list).

By the fqdns, you should be able to tell advertisements from the rest. By comparing the times of score data updates and timestamps of TCP packets carrying payload, and possibly also by the fqdns, you might be able to identify the TCP session used to update the scores. Wireshark assigns each TCP session a number which you can use as a display filter; by choosing the SYN (or any other) packet of a TCP session and using Analyze -> Follow -> TCP stream, you can see the data contents of that session in a separate window, and simultaneously apply the tcp.stream == N display filter so that you could compare the packet timestamps. I'd recommend to switch time display mode to "time of day" as by default it is "seconds since beginning of capture".

I think I am on the way. I found the rigth tcp session, I am trying to make a java code to read the tcp header that I exported into a binary file. But I am having the next problem: in tcp header specifications I saw that the length of the header is stored in a 4 bit number. In my file that size is represented by the hex byte 80 in wireshark if I select the headerlength it signs me the hex byte 80 and tells me that the header length is 32. I don´t know to read in java that byte to extract the header length

Please note that this is not the right place to ask questions regarding java programming.

But have you noticed that Wireshark can export the tcp payload for you as a byte stream? I mean, if I were you, I would first make sure that I can decode/decrypt the payload of the tcp session, and only then I would start developing an application which would receive and decode it in real time.

To answer what you literally asked, the upper (most significant) 4 bits of that byte express the length of the headers in 4-byte words, so a 0x80 value of the byte means 8 4-byte words which is 32 bytes, which is what the Wireshark dissector shows you. So (that_byte & 0xf0)/4 is the way to get the header length in bytes.