Svensk Myndighetskontroll: Behöver hjälp att granska ny teknisk bevisning för APB:s misstänkta datai

1. Stämmer absolut. Två favoriter. Kan närmast jämföras med bokmärken i en webbläsare där du kan ge dem en egen titel. Denna titel är vad som visas här. Tilläggas kan sägas att FlashFXP kräver att en titel anges (medan en webbläsare ofta använder webbsidans titel om du inte aktivt ändrar den)

2. CommView kan jag inte svara på. Dock stämmer uppskattningen vad gäller längden på ljudfilerna. 1MB per minut är väluppskattat som medel. Även uppgiften om att ljudböcker tar mindre plats (och datan ovan därmed är längre i tid). Någon exakt uppgift kan inte ges men ljudböcker är ofta i mono (då det är en röst inspelad på en mono-mikrofon) till skillnad från vanlig musik som är i stereo. Det innebär är ljudfilerna är markant mindre och närmar sig hälften av storleken för samma längd (dock inte exakt hälften, utan strax ovanför). Till det ska läggas att man ofta använder en lägre kvalitet för ljudböcker då det helt enkelt inte krävs mer.

3. Kan jag inte ge någon bra förklaring på. Däremot ett frö som någon annan kanske skulle kunna fortsätta på: Olika standarder för storleksenheter. En megabyte är exempelvis 1000 kilobyte enligt SI-systemet. Datorer har dock räknat en megabyte som 1024 kilobyte historiskt. Skulle det ena stället kunna vara räknat som 1024 och det andra som 1000?

Se följande Wikipedialänkar på mebibyte (1024) och megabyte (1000)

http://en.wikipedia.o...

http://en.wikipedia.o...

4. Yesbox. Däremot så vill jag inte dra på allt för stora växlar med att säga att en krypterad server inte är till för allmänheten. Visserligen skulle jag vilja påstå att absoluta majoriteten av alla ftp-servrar inte är publika och därav följer att större delen av alla krypterade servrar inte är publika. Flertalet serverprogramvaror idag tillåter anslutning såväl krypterat som okrypterat och det finns publika ftp-servrar där båda typerna av anslutningssätt är aktivt samtidigt beroende på hur anslutar vill göra.

5. Helt korrekt. I anslutningsmomentet så står IP-nummer på server och om användarnamn och lösenord efterfrågas. I klartext. Jag är högst tveksam till att det ens går att välja bort att visa det.

6. Ja. Det krävs att du aktivt stänger av den funktionen.

7. Här vill jag dock inte hålla med författaren ovan. Det _är inte_ en lokal dator som visas i högerdelen av fönstret. Det är en FTP-server. Skärmdumpen visar hur användaren har loggat in på en FTP-server på vänster sida och en (samma eller en annan) på höger sida. Detta ses tydligt t.ex. genom att det är en blixt-ikon i verktygsyraden. Bredvid den sitter ikonen för att koppla ifrån. Du kan inte koppla ifrån din egen dator. Här är en skärmbild där användaren i vänster del visar sin egen dator och där verktygsraden ser helt annorlunda ut: http://www.morenews.r... Dock skulle självklart en (eller båda) FTP-server/-rarna kuna finnas på användarens dator. Angående att det bara visas kataloger ("mappar" i författarens text) så stämmer det. De säger ingenting om innehåll.

8. Du kan skicka med flera paramterar ("verb") med ett LIST-kommando. LIST-kommandot skickas av ftp-klienten för att ftp-servern helt enkelt ska svara med en lista på kataloger och filer. I FlashFXP så kan du själv ställa in vilka paramterar som ska skickas med, sen är det upp till servern att bestämma om den vill förstå de parametrarna eller inte.

9. Korrekt

10. Stämmer förvisso. Dock ska tilläggas att om bilderna manipulerades i Paint så ska den personen ha en eloge för bra arbete. Det är något otroligt svårt att manipulera en bild trovärdigt i det programmet. Snarare skulle t.ex. Adobe Photoshop eller GIMP använts. (Med det inte sagt att man inte skulle kunna öppna bilden i t.ex. Photoshop, spara den, för att sedan öppna den i Paint, och ta en skärmdump.

Angående Emils svar:

7. Helt rätt, det är en ansluten FTP-server i högerdelen. Det framgår inte hur det verkligen ligger till så jag drog till med en kvalificerad gissning.

Trafiken har hanterats av ServUDaemon och inte av FlashFXP (enligt process-infon i CommView-loggen). Det betyder antingen att utredaren körde en egen server eller att bilagorna med loggar är helt irrelevanta. Förmodligen är det det tidigare som gäller, och att det är den servern som är ansluten på högersidan.

Varför han gjorde sig det besväret vet jag inte. Kanske för att dölja riktiga sökvägar i skärmdumparna (där det bara står \1340\ nu).

Trots en enkel förklaring (med reservation för att det bara är en gissning) är det en svag punkt i bevisningen - det står en sak i klartext och sen visar bilderna att något helt annat KAN ha hänt. ePhone borde ta alla chanser de kan att påpeka för tingsrätten hur oklar bevisningen är.

3. Om vi säger att FlashFXP räknar om bytes med SI-metoden skulle skillnaden bli ännu större (ca 68 MB istället för 40 MB). I CommView-loggen står storleken i bytes så där är det jag själv som räknat om till megabytes (på gamla sättet med 1024 bytes per kilobyte).

Det är ett så stort fel att antingen har utredaren slarvat rejält, eller så är loggen från något helt annat än överföringen av det verk de påstår att den är. Bakläxa.

10. Håller med och jag tror inte eventuell manipulation skedde i Paint. Klockan mitt på bilderna visar i bästa fall bara vad klockan var när utredaren tryckte på Print Screen. Det finns dock inget som bevisar att de skrevs ut vid samma tidpunkt...

Skärmdumpar saknar i min meningen bevisvärde helt och hållet men vi får väl leka lobbyns lek tills domstolarna också insett det.

Tack för det Emil o Daniel! Allt mer tycks alltså tala för att ephone blivit utsatta för brott och som en effekt av det brottet har nu Antipiratbyrån tänkt sko sig och ev. några klienter. Undrar om det inte kan sluta med att ephone kan stämma Svenska Antipiratbyrån......?

En fråga till er båda. Jobbar ni med den här typen av frågor inom den digitala världen? När jag kompletterar så är världen tyvärr fortfarande så beskaffad att i dom sammanhangen så är titlar och formell utbildning viktigt. Tacksam därför om ni kan addera era analyser med det.

Här var det rena inlärningsbloggen:) Helt plötsligt förstod jag lite mer också trots den sena timmen:) Längre leve kunskapen"!...

Får läsa om i mer vaken tillstånd.

Ha en fin fortsatt Påsk. Har gett solen min odelade uppmärksamhet och varit frånvarande sedan våren kom.....Äntligen SOL...:)

Kram

Finns inte så mycket mer att lägga till, det ser ut som fabricerade bevis. För att komma längre, krävs en utredning av APB:s egen utrustning.

Hej!

Redan den 2 april kommenterades (och analyserades)på Rick F. blogg (bl.a.) APB´s bevis!

http://rickfalkvinge....

I länken nedan analyseras ett av bevisen, "tidsangivelsen":

http://news-jesus.blo...

Om punkt 8: Jag dubbelkollade hur det ligger till och det stämmer, som Emil säger, att det är upp till servern om storleken på kataloger visas.

Storleken på kataloger är däremot inget som är inbyggt i filsystem, utan applikationer som vill veta måste själva (rekursivt) räkna storleken på alla filer i katalogen och alla underkataloger. Det är inga problem att göra med en mindre mängd filer, med betoning på 'mindre'. Att räkna de 90 TB som siffrorna på sida 26 påstår finns på servern skulle ta betydande tid. Det är ganska opraktiskt att behöva göra det varje gång någon loggar in på servern.

Notera även att hela Attrib-kolumnen är tom på alla skärmdumpar. Den innehåller vanligtvis info om läs-/skrivrättigheter och serveras även de av servern efter ett LIST-kommando. Jag är tveksam till att personen i fråga skulle konfigurera servern att räkna ut filstorlekarna och samtidigt strunta i attributen (som knappt tar tid alls så länge det inte är väldigt många filer i samma katalog).

Slutsats? Vet inte riktigt. Får en känsla av att något inte riktigt stämmer. Kan däremot inte bevisa det...