MaxTV nastavak...

Dakle, opet sam došao u doticaj s MaxTV opremom (točnije, prijemnikom) i ovaj puta sam pripremio sve potrebno da se ubacim između prijemnika i ADSL rutera. Zvuči kao da sam povezao kamion opreme sa sobom, a u stvari sam samo ponio laptop s PCMCIA mrežnom karticom tako da je dotični imao dvije mrežne kartice. Taman ono što treba. Pri tome sam imao više sreće nego pameti, naime nisam ponio cross-over mrežni kabl ali je ispalo da su mrežne na laptopu (ili na nekom od uređaja) to prepoznale i promijenile smjer kontakata.

Prikupljanje informacija

Uglavnom, ono što sam napravio je da sam isključio MaxTV prijemnik iz rutera te ga potom spojio na laptop, a laptop (koristeći drugu mrežnu utičnicu) spojio na ruter gdje je prije bio spojen prijemnik. Dodatno, kao root korisnik izvršio sam sljedeće naredbe:

# brctl addbr br0
# brctl addif br0 eth0
# brctl addif br0 eth1
# ip link set br0 up
# /etc/init.d/iptables stop

Te naredbe podrazumijevaju nekoliko stvari. Prvo, instaliran je paket bridge-utils u kojemu se nalazi naredba brctl. Konačno, mrežna sučelja na koja su spojeni prijenik i ADSL ruter zovu se eth0 i eth1. Zadnja naredba isključuje firewall, iako u načelu to ne bi trebalo, al' sigurno je sigurno. Ovo sam radio na CentOS 6 distribuciji i ako je neka druga u pitanju, treba napraviti odgovarajuće modifikacije.

Nakon toga sam isključio MaxTV prijemnik te sam pokrenuo snimanje prometa na laptopu:

# tcpdump -s0 -i br0 -w boot.pcap

i uključio MaxTV prijemnik. Promet je sniman u datoteku boot.pcap te sam ga puštao da snima promet dok god nije s ekrana televizora nestala oznaka Učitavam....

Dodatno, ispostavilo se da je komunikacija koja me zanima bila isprepletena s video zapisom zbog čega je datoteka bila vrlo velika. S obzirom da tako velika datoteka jako usporava rad prilikom njena anliziranja, odlučio sam izeliminirati video promet korištenjem tcpdump naredbe. U mom slučaju radilo se o video i audio podacima koji se šalju na adrese 224.1.2.81 i 224.1.1.1 (History i HTV1 kanali). Dakle, eliminacija je jednostavna:

# tcpdump -r boot.pcap -w boot1.pcap not host 224.1.2.81 and not host 224.1.1.1

Navedena naredba čita datoteku boot.pcap primjenjuje filter (not host 224.1.2.81 and not host 224.1.1.1) i zapisuje rezultat u datoteku boot1.pcap u kojoj više nema video (i audio) podataka. Nego, jesam li spomenuo da obožavam naredbu tcpdump? :)

Koliko god tcpdump naredba bila dobra, u određenim situacijama wireshark je ipak zakon. I sada dolazimo u baš takvu situaciju, analiza snimljenog mrežnog prometa.

Analiza snimljenog mrežnog prometa

Snimljeni mrežni promet učitao sam u wireshark korištenjem sljedeće naredbe:

wireshark boot1.pcap

Ovdje sada neću pričati o tehnikalijama kako sam nešto točno napravio već ću se prvenstveno zadržati na onome što sam uspio pronaći.

Slijed događaja odmah nakon uključenja samog uređaja je sljedeći:

1. Dohvat mrežnih podataka korištenjem protokola DHCP. Pri tome DHCP poslužitelj koristi ARP kako bi provjerio da adresa nije korištena, te kako bi nakon dodjele adrese provjerio da ju je uređaj doista i prihvatio. U DHCP podacima nalazi se informacija o DHCP poslužitelju (172.29.162.9, 172.29.162.12), DNS poslužitelju 172.27.130.4 i domeni nat.myrio.net, NTP poslužiteljima 172.27.130.21 i 172.27.130.24. Zanimljivo da je tu i opcija DOCSIS full security server IP s vrijednošću 31 kraj koje stoji oznaka "[TODO]". Čini se da to nije podatak s poslužitelja već da Wireshark trenutno ne dekodira tu informaciju.
2. DHCP poslužitelj s IP adresom 172.29.162.9 provjerava korištenjem ICMP echo request/response proba (efektivno, ping naredba) da li je klijent dostupan.
3. Slijedi sinkronizacija vremena korištenjem NTP protokola.
4. Ponovo DHCP upit, pri čemu se ovaj puta traži niz privatnih opcija, ali niti jedna nije pružena u odgovoru!
5. Upit za ime sap.nat.myrio.net. Odgovor je višeodredišna adresa 224.1.3.207.
6. SRV upit DNS poslužitelju za _vqe_channel_cfg._tcp.nat.myrio.net. Ovo je standardizirani upit kojim se traži informacija o usluzi _vqe_channel_cfg putem TCP protokola. Odgovor su poslužitelji vqe2.nat.myrio.net. (IP adresa 172.26.246.3) i port 8554 te vqe.nat.myrio.net (IP adresa 172.26.246.2) i port 8554.
7. Pristup na poslužitelj vqe.nat.myrio.net korištenjem protokola RSTP. Rezultat je popis svih raspoloživih kanala u SDP formatu. O njoj ću malo kasnije.
8. Spajanje na grupu 224.1.3.207 (IP adresa dobijena u 5. koraku). S te adrese stalno se prihvaćaju podaci u SDP obliku. Primjer podataka koji se razmjenjuju.
9. Upit za ime vss.verimatrix.com (IP adresa je 172.27.131.194) i spajanje na port 12697 tog poslužitelja. Koliko sam vidio, dohvaćaju se certifikati. Tvrtka verimatrix izgleda da se bavi metodama naplate TV sadržaja.
10. Dva puta se spaja na port 12698 poslužitelja vss.verimatrix.com i dohvaća nešto nepoznato.
11. Spajanje na vks.verimatrix.com (IP adresa je 172.27.131.194) port 12700 i dohvat nekakvih binarnih podataka.
12. Dohvat podataka poslanih na adresu 224.1.3.213. Podatke šalje poslužitelj 172.27.130.21 (to je NTP poslužitelj ali očito ima još neku funkciju).
13. Pokušaj spajanja na adresu 172.27.130.2 i po port 8443, međutim došlo je do isteka vremenskog ograničenja (timeout). Kasnije je došao ICMP odgovor Destination unreachable (Communication administratively prohibited).
14. Upit za imenom avr.nat.myrio.net (IP adresa 172.27.131.164) i potom slanje UDP paketa na port 2498. Odgovora na taj paket nije bilo.
15. Upit za imenima mds.nat.myrio.net (IP adresa 172.27.130.107) i webapp.nat.myrio.net (IP adresa 172.27.130.2).
16. Spajanje na webapp.nat.myrio.net port 8085. U ovom slučaju radi se o autentifikacijskom zahtjevu koji je uspješno obavljen. Zahtjev se šalje korištenjem metode GET protokola HTTP. Rezultat se vraća u XML obliku.
17. Potom ponovno spajanje na webapp.nat.myrio.net port 8085 rezultat je bio "Success".
18. Potom ponovno spajanje na webapp.nat.myrio.net port 8085. Ovaj puta se traže podaci o pretplatniku koji su dobijeni u XML obliku unutar tijela odgovora.
19. Potom ponovno spajanje na webapp.nat.myrio.net port 8085. Prijenos nepoznatih podataka.
20. Spajanje i dohvat podataka s grupa 224.1.3.209, 224.1.3.219, 224.1.3.216, 224.1.3.211 i 224.1.3.212.
21. Spajanje na webapp.nat.myrio.net port 8085.
22. Spajanje na grupu 224.1.3.208.
23. Pet spajanja na webapp.nat.myrio.net port 8085. Prijenos nepoznatih podataka.

Nakon ovoga izgleda da dalje idu samo video i audio podaci između prijemnika i T-Com-a. U nastavku su produbljeni neki dijelovi gornjih koraka

Popis kanala

Popis kanala dohvaća se korištenje protokola RTSP. Datoteka se sastoji od dva dijela, upita i odgovora. Upit čine prve tri linije:

DESCRIBE rtsp://172.26.246.2/vqe-channels RTSP/1.0
CSeq: 1
Accept: application/sdp

Nakon upita slijedi prazna linija te odgovor. Odgovor je dalje sačinjen od dva dijela, zaglavlja i tijela. Zaglavlje čini pet linija:

RTSP/1.0 200 OK
CSeq: 1
Date: 2 Nov 2012 22:16:49
Content-Type: application/sdp
Content-Length: 152588

Nakon toga dolazi prazna linija i tijelo. Tijelo se sastoji od opisa programa u SDP obliku. Po jedan blok za svaki program. Ovdje je primjer jednog bloka:

v=0
o=- 1350979665943 1350979665943 IN IP4 vcpt2
s=DiscWild HD
i=Channel configuration for DiscWild HD ( Unicast Retransmission Only )
t=0 0
a=rtcp-unicast:rsi
a=group:FID 1 3
m=video 3058 RTP/AVPF 96
i=Original Source Stream
c=IN IP4 224.1.2.58/255
b=AS:9000
b=RS:13
b=RR:130000
a=fmtp:96 rtcp-per-rcvr-bw=13
a=recvonly
a=source-filter: incl IN IP4 224.1.2.58 172.29.162.99
a=rtpmap:96 MP2T/90000
a=rtcp:3059 IN IP4 172.26.245.206
a=rtcp-fb:96 nack
a=mid:1
m=video 3058 RTP/AVPF 98
i=Re-sourced Stream
c=IN IP4 224.1.2.58/255
a=inactive
a=source-filter: incl IN IP4 224.1.2.58 172.26.245.206
a=rtpmap:98 MP2T/90000
a=rtcp:3059 IN IP4 172.26.245.206
a=mid:2
m=video 50206 RTP/AVPF 99
i=Unicast Retransmission Stream
c=IN IP4 172.26.245.206
b=RS:13
b=RR:13
a=recvonly
a=rtpmap:99 rtx/90000
a=rtcp:50207
a=fmtp:99 apt=96
a=fmtp:99 rtx-time=3000
a=mid:3

Ovdje se može razaznati četiri bloka: globani dio od početka do prve linije m=, i potom po jedan blok od kojih svaki započinje s linijom m=. Globalni blok daje informacije o kojem programu se radi. U ovom slučaju u pitanju je Discovery Wild HD. Od preostala tri bloka, zanimljiv nam je (za sada) samo prvi. Ovi ostali su retransmisija, nagađam u slučaju da se može naknadno gledati. U prethodnom ispisu masnim slovima sam označio što pripada prvom bloku. Iz toga se mogu iščitati sljedeće informacije:

1. Radio se o RTP/AVPF video podacima koji se šalju na port 3058 (linija m=).
2. Za primanje tih video podataka koristi se adresa 224.1.2.58 (linija c=).
3. Format u kojemu se prenosi video i audio je MP2T.

Web aplikacija

Web aplikacija nalazi se na IP adresi 172.27.130.2, port 8085. Poslužitelj je JBoss/Apache, a pristupa se sljedećim URL-ovima:

• /broker/fcs/authenticate?
• /broker/fcs/stbProperties?
• /broker/fcs/subscriberInfo?
• /broker/fcs/reminder?
• /broker/fcs/rentedItems?
• /broker/fcs/customCallerIDList?
• /broker/fcs/favorite?
• /broker/fcs/ContactManagement?
• /broker/fcs/playList?

Tijekom autentikacije šalju se podaci o modelu prijemnika, programskoj podršci koja se izvršava i slično. Ne vidim nikakve tajne informacije u tom URL-u pa mi se čini da je autentikacija samo prijava pri čemu se MAC adresa koristi kao identifikator (jer se u svim ostalim URL-ovima javlja MAC adresa).

Analiza video i audio podataka

Ovo mi se čini kao put da se otkrije iz kojeg razloga nije moguće dekodirati strane kanale. Naime, iz snimljenog prometa izdvojio sam pojedini kanal i potom ga učitao u Wireshark. Izdvajanje kanala obavlja se po IP adresi. Primjerice, kako bi se izdvojio kanal 224.1.2.81 može se koristiti sljedeća tcpdump naredba:

tcpdump -r boot.pcap -w stream1.pcap host 224.1.2.81

Na temelju popisa kanala, radi se o History kanalu. U toj naredbi pretpostavljam da je prilikom nastajanja datoteke boot.pcap bio odabran taj program na prijemniku. Nakon što se naredba izvrši, rezultat će biti pohranjen u datoteku stream1.pcap. Kada se ta datoteka učita u Wireshark on će analizirati promet samo do protokola UDP. Kako bi nastavio dalje treba mu reći da se radi o RTP prometu, što se postiže klikom na desnu tipku na nekom paketu, odabirom opcije Decode As... i potom se u listi protokola pronađe RTP. Nakon toga on će ispravno dekodirati i MP2T.

Međutim, za sada nisam uspio otkriti u tim podacima kako je video točno kodiran i u čemu je problem. Ako netko želi pogledati izdvojio sam taj promet u dvije pcap datoteke koje se mogu učitati direktno u Wireshark. Obje su veličine oko 1M. Prva sadrži HTV1, dakle ono što se može bez problema gledati. Druga sadrži History kanal s kojim je problem u dekodiranju. Obje datoteke možete direktno podmetnuti nekom programu za prikaz videa (kao što je primjerice mplayer) i primjetit ćete kako HTV1 prikazuje, History ne. Dodatno, mogu se datoteke učitati u Wireshark te potom ekstrahirati video pa pokušati, iako, rezultati će biti gotovo isti.

Podaci na kanalu 224.1.3.207

Podaci s ovog kanala se stalno prihvaćaju SDP opisi nekakvih binarnih podataka. Ovo su podaci (sadržaj linije s=):

• 7710.HE.30.14.0000.00.reno.rel6-myrioi-71
• 7710.HE.32.14.0000.00.reno.rel6-myrioi-110
• 8000.HE.30.14.0000.00.reno.rel6-myrioi-71
• 8000.HE.32.14.0000.00.reno.rel6-myrioi-110
• DTVLINEUP
• DTVLINEUP_v.3.0
• DTVLINEUP_v.3.1
• GLOBALINSTALL
• GLOBALLYFEATURED
• GROUPS
• MESSAGES
• NPVRUPDATEDRECORDINGS
• PIPEDSCHEDULE
• PIPEDSCHEDULE_small
• sw_update.SAIPP330HD.SCIATL
• sw_update.SAIPP330HD.SCIATL.reno.rel6-myrioi-110
• sw_update.SAIPP330HD.SCIATL.reno.rel6-myrioi-71
• ui_default
• ui_reno.rel6-46_tcom
• WEBACCESS
• WEBACCESS_en
• WEBACCESS_hr

Interesantno da sam pretražujući Internet za ključnom riječju "x-carousel" naišao na ovaj forum. Međutim, radi se o postu na Francuskom jeziku koji baš ne razumijem. :)

Linije koje su istaknute masnim slovima označavaju datoteke koje je moguće dohvatiti korištenjem HTTP protokola. Za dohvat treba koristiti sljedeći URL:

http://webapp.nat.myrio.net/broker/documentName=GLOBALINSTALL.xml.gz

Kao što primjećujete, datotekama treba dodati ektenziju .xml.gz.

Pristup Internetu

Putem MaxTV mreže moguće je pristupiti Internetu ali se za to mora koristiti proxy. Proxy je na adresi 172.27.131.173, port 3128. Primjerice, putem njega moguće je na Facebook ali uglavnom je pristup ograničen, odnosno, nije moguće posjetiti bilo koje Web stranice. Inače, zanimljivo je da port 3128 po "defaultu" koristi Squid pa se vjerojatno radi o toj poslužiteljskoj aplikaciji.

Zaključak

Dakle, očito je jasno kako još nisam uspio odrediti zašto se ne vide pojedini kanali i trebat će na tome još poraditi. S obzirom da mi audio/video nije baš jača strana trebat će vremena. Međutim, ako netko drugi želi istražiti što je problem u tekstu sam stavio linkove na snimljen promet dva programa, jednog koji se ispravno prikazuje (HTV1) i jednog koji se ne prikazuje ispravno (History Channel).

Za kraj, ovdje je link na raspravu na Bugovom forumu u kojemu se raspravlja o STB-u i njegovoj prenamjeni. Čini se interesantno, ali još nisam stigao detaljno pročitati post.

What is Routing architecture...

I decided to write a post about Nimrod routing architecture but then I realized that I first have to define, or at least describe, what is meant by routing architecture. I searched a bit for a definition, and to my surprise, I wasn't able to find one. So, I decided to give my own view, and possibly definition. But when I started to write it, it turned out that the substantial part of the post about Nimrod will be about routing architecture. After a bit of thinking, I decided to split the text into two posts and the goal of this new post is to define routing architecture. I'll start by dissecting both words, routing and architecture, separately and then I'll combine them.

One note before proceeding. You have to keep one thing in mind when reading this post. My primarily viewpoint is from data networks, and I don't know much about voice, a.k.a. telephone, networks. So I don't claim, nor do I believe, this will be valid for them. In any case, I would gladly hear comments you might have about my view, or, you own views about this particular topic.

Routing

The term routing denotes a process who's purpose is to determine path, or route, through the network between two users, obeying some (possibly more that one) constraints and optimality requirements. This process, in essence, enables any two users to communicate. User might be on any node in the network, as is in the Internet, or only on a certain subset of nodes, as is in telephone network where only telephones can communicate and not telephone with some internal network switch. The example with a telephone isn't actually very good, since we are confined in the network layer (as per OSI RM) and telephone network doesn't have concept of a layer but instead uses interfaces! Anyway, users of routing are entities within a network layer, which in turn allow their users (transport layer) to communicate.

Closely related to routing, and frequently mixed with routing, is forwarding, but forwarding is actually concerned with moving data packets through the network, in contrast to routing that only determines where packets should go. In other words, forwarding is on data path, while routing is in control path. Note that users of routing are performing forwarding! There are two additional differences between forwarding and routing. First, routing, in order to work, needs a certain data about the network, and of course, decisions have to be taken somewhere. On the other hand, forwarding needs only a subset of that data to perform its function. In general this is so, but there are some cases it might not be a true subset. For example, RIP protocol has only data about destination, next hop and distance, and that data is passed to forwarding process. On the other hand OSPF routing process knows the complete topology of the network, and it passes only a subset of this data to forwarding process. The second difference is that routing is a global process, i.e. it needs a coordination throughout the whole network, while forwarding is a local process with no explicit coordination with other nodes.

Note that inseparable part of routing is addressing, i.e. how to identify nodes for the purposes of routing. There is also a concept of a name, but it is not directly related to routing. For an early discussion on distinction between names, addresses and routing take a look at Shoch's note from 1978.

So, strictly speaking we have two different things, routing and forwarding. But those two are inseparable, meaning that when you define a new routing it has an impact on forwarding too. After all, routing process has to give instructions to forwarding process what it has to do and also, when routing process tells forwarding process for nodes it has to do so via addresses, so, they have to agree about address structure and whatever information is embedded in them. In any case, by only finding routes, without being able to deliver data because you don't communicate with forwarding process, you didn't achieved much. So, I'll use the term routing  with two different meanings, routing in a strict sense, and routing in general. Routing in general will include also forwarding process and from now on I'll use this meaning of the word routing, unless specifically told otherwise.

For the end of this section let me just note that the routing process can have different characteristics:

• centralized vs. distributed,
• static vs. dynamic

Architecture

Architecture is nowadays very heavily (mis)used word in computer science and related disciplines. Traditional architecture is a very old discipline and different fields of computer science borrow a lot of ideas from it. Probably the first use of word architecture in computer science was in relationship with computer organization, or more precisely, computer architecture and it appeared during the development of IBM's 7030 computer. Here is a definition, given by Frederic P. Brooks, Jr., of the purpose of computer architecture taken from the document Planning a Computer System - Project Stretch:

Computer architecture, like other architecture, is the art of  determining the needs of  the user of  a structure and then designing to meet those needs as effectively as possible  within economic and technological  constraints. Architecture must include engineering  considerations, so that the design will be economical and feasible; but the emphasis in architecture is upon the needs of  the user, whereas in engineering the emphasis is upon  the needs of  the fabricator.

Later, the term architecture spread in use for different levels of abstraction and different domains. For example, there is CPU architecture, as opposed to computer architecture, and just to mention few from software domain: software architecture, service oriented architecture (SOA), client server architecture, and many many others.

I don't think it's necessary to enumerate all the possible uses of this word and their definitions, since it seems to me that it is clear from the original definition what an architecture is and what its purpose is. So, the term architecture denotes a result of a design process, that takes the requirements from the users and outputs definition a system in terms of components, their behavior and interactions that fulfils the initial requirements. Architecture by itself is stripped from unnecessary technical details and from implementation details. It is also a work of art, but I can state that sentence in a more technical terms: it is a search process of a huge space of different possibilities which can not be automated, by current methods, and thus has to rely on experience (which, I believe, is a cause of intuition) of the architect.

Finally, two things have to be noted. First, there could be multiple views of the architecture (thus of a resulting system definition) each of which can represent architecture from different angle. Secondly, architecture is not absolute. As we move through the layers of abstractions, each layer has its architecture and associate implementation!

Routing architecture

So, finally we came to describing what routing architecture is. Routing architecture is

... a system, that consists of components with specified behavior and mutual interaction, built according to some requirements whose purpose is to find a path to a given destination and to allow communication between two users.

This definition is, of course, valid within the networking context. I'm emphasizing this because there is no single word about networks in the previous definition so if it is taken out of the context, it might sound meaningless. Note that by "to allowing communication" I'm also referring to a forwarding process, that is tightly bound to a routing process, as I already explained.

One of the key requirements of routing architecture, at least when Internet-like networks are in question, is scalability.

For additional discussion about routing architecture see this Nimrod presentation that, in the first part, discusses what is routing architecture. Note that this "presentation" is actually text document with titles and bullets, not exactly what should be called presentation.

Examples of routing architectures

There are a dozen of RFCs that deal with different aspect of routing architectures for the Internet. The oldest one I managed to find is The NSFNET Routing Architecture, defined in RFC1093 that was published in 1989. It got addition in 1991 in a form of RFC1222, Advancing the NSFNET Routing Architecture. Also, in 1991. IETF published RFC1287, Towards the Future Internet Architecture. This RFC gives possible directions for the future Internet Architecture, and as such, is much broader than routing architecture we are discussing here. Still, it has a section about future routing architecture. Then, in 1993. ipngwg working group published RFC1550, Next Generation (IPng) White Paper Solicitation, which solicited input on requirements for next generation IP. Noel Chiappa was developing Nimrod at that time and he submitted white paper published as RFC1753, IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture. Basically, he published requirements on Nimrod that he believed will be put on whatever solution will be selected. Nimrod routing architecture was described in RFC1992, Nimrod routing architecture. It was published in 1995 as a possible replacement for IPv4. I'm going to write about that proposal in a separate post.

Lately, IAB recognized that there are serious problems with current routing on the Internet (which are not solved with IPv6). This is documented in report published as RFC4948, Report from the IAB Workshop on Routing and Addressing. To address problems identified in the workshop,  Routing Research Group was established with a goal of evaluating different proposed solutions. This group produced several RFCs related to routing architecture. First, there is RFC5772, A Set of Possible Requirements for a Future Routing Architecture. Because, as we already saw, defining architecture requires some requirements, RRG group produced RFC6227, Design Goals for Scalable Internet Routing, which sets requirements for routing architecture. The requirements defined in this RFC are also used to evaluate different proposals. There are more than dozen proposals. They are listed and shortly surveyed in RFC6115, Recommendation for a Routing Architecture.

For the end I'll mention RFC1958, Architectural Principles of the Internet, and its update RFC3439, Some Internet Architectural Guidelines and Philosophy. While more broader that routing architectures, still apply to them and are very interesting by themselves.

CFP: MIPRO ISS

Starting from this year I'm going to be a vice chair of Information Systems Security event that is a part of a larger MIPRO conference. The reason I took this role is that I believe that relevant security event is missing in this region and that this conference (I'll say conference not event from now on and by that I'll refer to ISS event) can fill the void. Furthermore, I believe there is lot of a room for improvements, which is of course mandatory if this conference is to become regional, and I have some ideas what and how to do it. But it will take me some time until I articulate what I intend to do. In the meantime, CFP was published [PDF].

I don't find conferences appropriate for publishing finished work, journals a better for that purpose. Conferences are, on the other hand, ideal for presenting your work in progress in order to solicit feedback so that, in the end, you improve quality of your research. I especially invite students, undergraduate, graduate and postgraduate, so submit their work for diploma thesis or PhDs. Also of great interest are findings of weakness (vulnerabilities) somewhere, I invite you to present your finding on the conference. Of course, in that case you should be careful first to notify those you found a vulnerability so that they have time to react.