Vinnaren i pepparkakshustävlingen!
Det var tråkigt att höra, men jag måste fråga såklart det som jag skrev i inlägg #16, är det fel menar du?
Förklara på ett seriöst sätt så det blir en diskussion kring ämnet varför det inte stämmer så kan jag ju lära mig av den som kan bättre så kan diskussionen komma vidare så jag ser jätte gärna att du skriver seriösa inlägg och tar diskussion vidare kring denna topic eftersom du menar på att jag skriver oseriösa inlägg.
Vill du förklara på ett seriöst sätt så att det blir seriöst och mer on topic och ett bättre diskussionsunderlag i helhet?
Hur skickas en request från bankid till en telefon? Jag har bara skrivit hur det görs via en dator eftersom jag förmodar att Skatteverket gjorde just det i detta fall.
Gnälla går bra, men komma med något vettigt det går fan inte.
Vill du visa hur en broadcast skickas med token? EXAKT som bankid gör det för att kommunicera med just en speciell enhet med eller utan brandvägg. Gör det seriöst så lovar jag att skall absolut ta steget tillbaka! Annars visar jag gärna, om du inte vet?
Vi kan ta hur bankid funkar på en Telefon istället EXAKT hur det triggas jag visar eftersom du inte kom med något och vill hålla mig till topic, i detta exemplet är det en android android som anropas av bankid, det går tillsåhär via en broadcast:
Först så startas en aktivitet:
Sen så skickas en intent enligt nedan:
Sen pushas datan med:
tcp 0 0 10.207.251.187:34334 185.198.4.19:80 ESTABLISHED 29807/com.bankid.bus
tcp6 0 0 ::ffff:10.207.251:53688 ::ffff:13.33.141.91:443 ESTABLISHED 29807/com.bankid.bus
tcp6 0 0 ::ffff:10.207.251:33994 ::ffff:185.198.4.18:443 ESTABLISHED 29807/com.bankid.bus
Sedan används, nedan för att starta aktivitetet i din telefon:
Lägger vi ihop allt detta, och du provar på din egen telefon, så blir det:
Bankid startas, på din telefon! Men eftersom det inte är från deras server så har vi inget att ansluta till men i teorin är detta EXAKTTTTTTTTTTTTTTT vad bankid gör och kommandona är LEGIT så prova själv?
Nu återstår bara EN ändast fråga, det är hur är det möjligt och svare
t på detta är det som sker precis innan denna broadcast hanteras, vill du besvara detta med ett seriöst inlägg? Nu har jag ju visat dig EXAKT vad som sker och EXAKT vad som triggar appen att starta och EXAKT vart tokens skrrivs in och exakt hur bankid ropar på ens enhet, men hur går det till? Det tänkte jag låta digt få diskutera dig fram på ett seriöst vis sedan är frågan besvarad. Eller detta kanske är fel och oseriöst också? GoCry! Du hade mycket att bidra med.
Du får gärna förkalra vad följande gör och varför i helvete bankid rör dessa saker:
Du får gärna svara på varför dom använder http också när man authar sig på telefon, någon tidigare skrev att man inte gör det via nätet så det spelar ingen roll? Men nedan beivsar motsatsen mot det som någon skrev så jag undrar fortfarande
Så kan du ju joina diskussionen istället för sprida ditt hat mot enskilda användare, jag känner mig kränkt av ditt inlägg.
NU försöker jag diskutera området igen som ingen kunnat diskutera sig fram till varför det är så, vill du diskutera seriöst med mig?
Det absolut första som sker via en auth med bankid, det är att man får en inkommande anslutning från:
185.198.4.19
Fråga inte mig varför folk säger fel? Det är inte emot reglerna att ha fel men det dödar absolut diskussioner
Medans vi har identifieringen öppen, så dyker även deta upp under netstat:
Sluta grina, sluta ljug, sluta sprida skit sluta förök sprida skit, sluta försök leka seriös, sluta försök hitta på, sluta försök verka bäst! Diskutera istället.
PORT 80!!!! Skyller du på mig men inte dom spider dynga? Vet du vad ESTABLISHED betyder?
Nog om detta, nu får fan bidra med något.
// wuseman
Problemet är inte huruvida du kan något - det kan du säkert.
Problemet är att det är helt omöjligt att förstå vad fan du skriver. Det är som att du mitt under pågående psykos dragit ladd och sen satt dig ner bakom tangentbordet.
Jag förstår jag förstår, hur skall jag förklara så du förstår då? Skall jag förklara så som det INTE är? Det gör ju så många andra så bra redan, om ingen bevisar motsatsen. Skall man då sitta här och skriva saker som inte stämmer så borde ju tråden flytta plats till konspirationsteorier.
Men nog om det, förstår du någonting här: https://developer.android.com/traini...h/authenticate ?
Det som står inom text boxarna där, det är samma sak som jag visat ovan fast jag visade med exakta exempel med appen som diskuteras här dvs com.bankid och hur man kan skicka en signal till bankid via en broadcast, en broadcast. En broadcast är en term inom datorkommunikation som innebär att paket som skickas mottages av alla på nätverket. I motsats till enkelsändning är som sagts informationen som skickas adresserad till alla noderna i nätverket, vilket även namnet tyder på. Inte alla former av nätverk stödjer broadcastning.
Detta betyder att den kan få tillgång till internet och även få tillgång statusen på nätverket. Den har även tillgång till write settings vilket betyder att den får modifiera systemet och dina internet inställningar för in och utgåend etrafik från enheten vilket jag visar ovan med IN= och OUT= trafik från en servers ip address.
<uses-permission android:name="android.permission.INTERNET" />
Eftrersom jag inte kan förklara närmare i detalj så får något annan göra det, men både DATORN och TELEFONEN samtalar med en ip address, så får någon an nan göra det. Men att säga att den inte samtalar med något och sådant här trams, är bara sjukt. Först får man kolla vad för behörigheter den har, sedan får man kolla vad dom behörigheterna har rätt att göra, sedan får man ta det eftersom.
Jag skrev även tidigare i tråden att den har tillåtelse att styra din enhet, dvs ändr ainställningar men det rätta ordet är antagligen "modiifiera" vilet förändrar ett värde på telefonen. Det stämde inte heller tydligen men så är det iaf.
Du får hoppas någonmed pedagogisk utveckling och interaktivt lärande kan komma in och förkalra SAMT förstå vad som sker, det är ju kruxxet uppenbarligen för många..
Nåväl, bra att du sa till. Jag återgår till psykos världen och lämnar härmed tråden för dom som kan förklara bättre, det vore ju förjävligt att slösa sin dyrbara tid på något som man inte förstår ändå.
// wuseman
Jag skrev i ett tidigare inlägg kortfattat hur en förfrågan går till och inkluderade då en länk till BankID's egen guide för hur man hanterar BankID-inloggning i sin egen app.
https://www.bankid.com/en/utvecklare...egrationsguide
Lite rörig och väl sparsmakad guide kan jag tycka, men det mesta står där. Om jag har kunnat fixa BankID-inloggning till en app så kan "vemsomhelst".
Jo det är klart, men hur kan servern kontakta appen när/om telefonen har en brandvägg vilket den har per default? Den kommunicerar på port 80 och även 443 och då behövs det dom verktygen bl.a för att kunna ta del av den informationen och se det.
Om man går in till valfri site, skickar en förfrågan om login och så poppar bankid upp och sedan kollar man på enheten oavsett om det är en telefon eller dator via netstat. Så kommer det att bli etablerad anslutning mellan din ip address och en av dom två ip addresserna som leder till bankids server. Då har man ju direkt kontakt med servern?
Kollar man även med lsof, som visar vilka filer som ens app använder så ser man flera processer som har en socket anslutning och det är direkt mot deras ip också.
INTERNET.PERMISSION som är en behörighet man måste ge tillgång till bankid har/får rättigheter att modifiera internet inställningarna på enheten de är vad behörigheten gör så det är inget konstigt egentligen.
Om man sniffar trafiken, det spelar nog ingen roll vilken enhet på mobil det gäller men den jag har här iaf med bankid på använder "rmnet4" interfacet för internet för mobilnätverk, det kan jämföras med te.x är wlan0 eller eth0 på en dator men men på telefoner heter dom oftast rmnet, "r" iom roaming och "m" för mobil och "net" för nätverk så detta är helt enkelt nätverksenheten för mobilt nätverk.
Listar man enhetens brandvägg regler med "iptables -L" som betyder list ip tables helt enkelt så ser man: "bw_costly_rmnet4 all -- anywhere anywhere " det betyder att all trafik överallt är tillåten och då behöver appen aldrig kringå en brandvägg för trafiken är alltid tillåten på rmnet4
på det viset dom kommunicerar med ens enhet och android permissions ger man tilltåelse till när man installerar appen annars kan man inte använda appen och kommunicera med servern så det är ett måste och denna inställningen har tillåtelse att modifiera ens nätverks inställningar och kan om det behövs te.x lägga till en regel så att vi får kommunicera med deras server in/ut om det krävs så man behöver inte kringå någon brandvägg.
Det är det jag menade, inte något annat med det jag sdkrev tidigare, nästa steg i proceduren är det som du berättar med ditt inlägg hur man loggar in och det blir verifierat. Så det är två olika saker vi skirver om men dom båda berör ändå hur det går till och det senare altenativet vet du bättre än mig men för att ens komma hit till den steg i processen så måste det ske allt annat före så att säga och det är där jag är och det är det jag skriver om även om det går på microsekunder. Hurvida man signar med eller utan ssl eller skickar någon data har jag ingten aning om men den lyssnar iaf på http och port 80 OCH ssl men när förfrågan kommer in så kommer den på port 80, därefter har jag inte fortsatt följa trafiken för det är jku själva bankid det diskuteras så det kan mycket väl ske med ssl därefter det vet inte jag vad som händer sen eller nu vet jag nu när du berättat.
Nu är bankid en rätt tråkig app för den gör inget som den inte borde den tar emot och skickar authen sen raderar den all info precis som den skall så det är inte ultimat att ta det som exempel som jag visat kanske men det är mer intressant att följa andra appar för att kunna se mer detaljerat för det händer mycket skumt på en telefon men bankid är ett dåligt exempel om man vill förstå processen och kanske är nyfiken på området om man själv vill kolla och lära sig så jag förstår det inte gav mycket kanske nu i efterhand det jag skrev, men oavsett vad iaf så är det inte något behov av att kringå någon brandvägg .
Vill man veta exakt vad bankid använder för tokens/gps/behörigheter m.m så kan man om man har lust och vill se under skalet om man är nyfiken kanske inte vet jag iaf låsa filerna som skapas precis under sekunden den authar för att veta vad det är den skapar och raderar under en auth på den korta stunden för man hinner inte kopiera manuellt eftersom det går så fort tills att den raderar temp filerna som skapas under authen.
den sparar exit reason te..x för att logga och veta om ens gps location är fine eller wrong:
Därför vet appen te.x ifall om man använder den på en emulator och därför går det inte använda den på en emulator te.x då det inte finns en riktig sensor fölr location i en dator oftast.
Topic handlade om hur den kringår så därför tog jag upp detta för den som är nyfiken och inte vet och vad allt betyder finns i manifeset
Det sker en hel del kontroller innan man kommer till tokens överhuvud taget, den kollar framförallt CAMERA och LOCATION sedan kommer INTERNET permission
Själva tokens finns i nedan och id:it finns i 0.ngp filen som jag skrivit om tidigare den innehåller även personnummret, banken och för/efternamn för att kunna skapa idit.
com.google.android.gms.appid.xml
com.google.firebase.messaging.xml
FirebaseAppHeartBeat.xml
com.bankid.bus_preferences.xml
pp_shared_prefs.xml
Det är ju inte bara bara så att säga så "enkelt" det är en jävla process innan den ens kommit till signeringen, nu skriver jag om det som sker från att första paketet in i telefonen tas emot till man skall skriva in koden i appen, sedan börjar det du skrev om som sagt detta är hur en telefon fungferar inte bankid i sig så det är inte bankid som kringår brandväggen det är en funktion i telefonen kan man säga.
Nu försökte jag berätta på ett annat sätt, är det fortfarande oförståeligt hur jag menade så kan jag inte bättre förklarat.
Grejen är att det följer client/server-modellen, så det behövs ingen inkommande anslutning. Klienten gör en reach out till servern och push/pullar informationen. Utgående anslutningar släpper 99% av alla brandväggar igenom per default pga UPnP.
Inga vidare undersökningar är nödvändiga. Alla utvecklare eller forensiker värda sin vikt i salt bör kunna dra den slutsatsen omedelbart bara genom att läsa problembeskrivningen.
IN=wlan0 OUT= SRC=185.198.4.19 DST=192.168.1.231 LEN=210 TOS=0x00 PREC=0x00 TTL=52 ID=37793 DF PROTO=TCP SPT=80 DPT=56592 WINDOW=59 RES=0x00 ACK PSH URGP=0 UID=10375 GID=10375 MARK=0x3008d
https://apps.db.ripe.net/db-web-ui/q...t=185.198.4.19
Säger det motsatta? Gissar du eller? Uppenbarligen behövs det kollas upp för du har fel. Socke processerna talar för sig själv, varenda forensiker vet att man kollar upp saker innan man påstår sig veta någonting, eller vad vet jag vad dom gör detta är exakt vad som sker, iptables är en del av linux kärnan som hanterar inkommande och utgående trafik som samtalar med hårdvaran. Den skriver ut fel menar du?
"IN"
Slutsatsen du drar är felaktig. HTTP över TCP fungerar som så att servern skapar en socket där den lyssnar efter en request. När den mortality en request öppnar klienten en socket där den kan ta emot responsen.
Anledningen till att detta inte kräver en egen brandväggsregel är för att paketet tillhör en redan accepterad och etablerad utgående anslutning (på port 80). Hade detta inte varit fallet hade du inte kunnat komma åt någonting alls. Därav att du ser att source porten är 80 och desinationsporten en hög port I den dynamiska rangen.
Du har analyserat problemet så till den förbannelse att du ser red herrings där inget fuffens försigår.
Rekommenderar att du läser "TCP/IP Illustrated" av W. Richard Stevens för att lära dig mer om hur nätverkskommunikation fungerar fundamentalt.
Stöd Flashback
Svara
- Ämnesverktyg
- Hitta inlägg efter datum
Alltså, varför får wuseman hållas utan att bli avstängd? Varenda tråd han dyker upp i blir direkt förpassad till sandlådenivå..
Helt meningslöst att ens försöka diskutera eller förklara något på ett seriöst sätt.
Helt meningslöst att ens försöka diskutera eller förklara något på ett seriöst sätt.
Citat:
Det var tråkigt att höra, men jag måste fråga såklart det som jag skrev i inlägg #16, är det fel menar du?
Förklara på ett seriöst sätt så det blir en diskussion kring ämnet varför det inte stämmer så kan jag ju lära mig av den som kan bättre så kan diskussionen komma vidare så jag ser jätte gärna att du skriver seriösa inlägg och tar diskussion vidare kring denna topic eftersom du menar på att jag skriver oseriösa inlägg.
Vill du förklara på ett seriöst sätt så att det blir seriöst och mer on topic och ett bättre diskussionsunderlag i helhet?
Hur skickas en request från bankid till en telefon? Jag har bara skrivit hur det görs via en dator eftersom jag förmodar att Skatteverket gjorde just det i detta fall.
Gnälla går bra, men komma med något vettigt det går fan inte.
Vill du visa hur en broadcast skickas med token? EXAKT som bankid gör det för att kommunicera med just en speciell enhet med eller utan brandvägg. Gör det seriöst så lovar jag att skall absolut ta steget tillbaka! Annars visar jag gärna, om du inte vet?
Vi kan ta hur bankid funkar på en Telefon istället EXAKT hur det triggas jag visar eftersom du inte kom med något och vill hålla mig till topic, i detta exemplet är det en android android som anropas av bankid, det går tillsåhär via en broadcast:
Först så startas en aktivitet:
Kod:
android.intent.action.VIEW
Sen så skickas en intent enligt nedan:
Kod:
"android.intent.category.BROWSABLE
Sen pushas datan med:
Kod:
bankid:///?autostarttoken=x1111xxx-xaxx-xaxa-xxxx0-xxxxxx?=redirect=null"
tcp 0 0 10.207.251.187:34334 185.198.4.19:80 ESTABLISHED 29807/com.bankid.bus
tcp6 0 0 ::ffff:10.207.251:53688 ::ffff:13.33.141.91:443 ESTABLISHED 29807/com.bankid.bus
tcp6 0 0 ::ffff:10.207.251:33994 ::ffff:185.198.4.18:443 ESTABLISHED 29807/com.bankid.bus
Sedan används, nedan för att starta aktivitetet i din telefon:
Kod:
"com.bankid.bus/.activities.StartupActivity"
Lägger vi ihop allt detta, och du provar på din egen telefon, så blir det:
Kod:
am start -a "android.intent.action.VIEW" --es "android.intent.category.BROWSABLE" -d "bankid:///?autostarttoken=x1111xxx-xaxx-xaxa-xxxx0-xxxxxx?=redirect=null" -n "com.bankid.bus/.activities.StartupActivity"
Bankid startas, på din telefon! Men eftersom det inte är från deras server så har vi inget att ansluta till men i teorin är detta EXAKTTTTTTTTTTTTTTT vad bankid gör och kommandona är LEGIT så prova själv?
Nu återstår bara EN ändast fråga, det är hur är det möjligt och svare
t på detta är det som sker precis innan denna broadcast hanteras, vill du besvara detta med ett seriöst inlägg? Nu har jag ju visat dig EXAKT vad som sker och EXAKT vad som triggar appen att starta och EXAKT vart tokens skrrivs in och exakt hur bankid ropar på ens enhet, men hur går det till? Det tänkte jag låta digt få diskutera dig fram på ett seriöst vis sedan är frågan besvarad. Eller detta kanske är fel och oseriöst också? GoCry! Du hade mycket att bidra med.
Du får gärna förkalra vad följande gör och varför i helvete bankid rör dessa saker:
Kod:
08-17 20:58:41.836 6835 7079 D SGM:GameManager: onLooperPrepared(), msg: MSG_APP_CREATE, pkgName: com.bankid.bus, userId: 0 08-17 20:58:41.837 6835 9577 D SGM:GameManager: sendRunningComponentFocus(), pkgName: com.bankid.bus, userId: 0 08-17 20:58:41.837 6835 7079 D SGM:GameManager: onLooperPrepared(), msg: MSG_TASK_FOCUSED, pkgName: com.bankid.bus, userId: 0 08-17 20:58:41.837 6835 7079 D SGM:GameManager: handleTaskFocused(), pkgName: com.bankid.bus, userID:0 08-17 20:58:41.837 6835 7079 D SGM:GameManager: handleResume(). pkgName: com.bankid.bus, userId: 0, isTunableApp: null 08-17 20:58:41.936 6835 7079 D SGM:GameManager: onLooperPrepared(), msg: MSG_APP_RESUME, pkgName: com.bankid.bus, userid: 0 08-17 20:58:41.936 6835 7079 D SGM:GameManager: handleResume(). pkgName: com.bankid.bus, userId: 0, isTunableApp: null 08-17 20:58:41.936 6835 7079 D SGM:GameManager: notifyFocusInOut(). of pkg: com.bankid.bus, type: 4, isMinimized: false, isTunableApp: false, userId: 0 08-17 21:01:56.821 6835 6897 W UsageStatsService: Unexpected activity event reported! (com.bankid.bus/com.bankid.bus.activities.SignIdleActivity event : 23 instanceId : xxxxx)
Du får gärna svara på varför dom använder http också när man authar sig på telefon, någon tidigare skrev att man inte gör det via nätet så det spelar ingen roll? Men nedan beivsar motsatsen mot det som någon skrev så jag undrar fortfarande
Kod:
i.Q..POST /cava/ HTTP/1.1 Host: cavanotification.bankid.com Content-Length: 12 Cache-Control: no-cache ............ POST /cava/ HTTP/1.1 Host: cavanotification.bankid.com Content-Length: 12 Cache-Control: no-cache ............HTTP/1.1 200 OK Connection: Keep-Alive185.198.4.19 Pragma: no-cache Cache-Control: private, no-store, no-cache, must-revalidate Content-Length: 16 ................
Så kan du ju joina diskussionen istället för sprida ditt hat mot enskilda användare, jag känner mig kränkt av ditt inlägg.
NU försöker jag diskutera området igen som ingen kunnat diskutera sig fram till varför det är så, vill du diskutera seriöst med mig?
Det absolut första som sker via en auth med bankid, det är att man får en inkommande anslutning från:
185.198.4.19
inetnum: 185.198.4.0 - 185.198.4.255
netname: BANKID-NET
descr: Finansiell ID-Teknik BID AB
country: SE
admin-c: TF3806-RIPE:
tech-c: TF3806-RIPE
status: ASSIGNED PA
mnt-by: RESILANS-MNT
mnt-routes: RESILANS-MNTtcp 0 0 10.207.251.187:34334 185.198.4.19:80 ESTABLISHED 29807/com.bankid.bus
tcp6 0 0 ::ffff:10.207.251:53688 ::ffff:13.33.141.91:443 ESTABLISHED 29807/com.bankid.bus
tcp6 0 0 ::ffff:10.207.251:33994 ::ffff:185.198.4.18:443 ESTABLISHED 29807/com.bankid.bus
created: 2018-10-18T09:19:40Z
last-modified: 2019-05-22T16:29:02Z
source: RIPE
person: Torbjorn Friberg
address: Kungsgatan 33
address: SE-111 56 Stockholm
address: Sweden
phone: +46 84118150
nic-hdl: TF3806-RIPE
mnt-by: RESILANS-MNT
created: 2017-04-04T07:34:33Z
last-modified: 2017-04-07T08:57:35Z
source: RIPE # Filtered
% Information related to '185.198.4.0/24AS198949'
route: 185.198.4.0/24
descr: Finansiell ID-Teknik BID AB
origin: AS198949
mnt-by: RESILANS-MNT
created: 2020-05-18T07:25:48Z
last-modified: 2020-05-18T07:25:48Z
source: RIPE
% Information related to '185.198.4.0/24AS202837'
route: 185.198.4.0/24
descr: Finansiell ID-Teknik BID AB
origin: AS202837
mnt-by: RESILANS-MNT
created: 2018-11-22T08:46:25Z
last-modified: 2018-11-22T08:46:25Z
source: RIPE
netname: BANKID-NET
descr: Finansiell ID-Teknik BID AB
country: SE
admin-c: TF3806-RIPE:
tech-c: TF3806-RIPE
status: ASSIGNED PA
mnt-by: RESILANS-MNT
mnt-routes: RESILANS-MNTtcp 0 0 10.207.251.187:34334 185.198.4.19:80 ESTABLISHED 29807/com.bankid.bus
tcp6 0 0 ::ffff:10.207.251:53688 ::ffff:13.33.141.91:443 ESTABLISHED 29807/com.bankid.bus
tcp6 0 0 ::ffff:10.207.251:33994 ::ffff:185.198.4.18:443 ESTABLISHED 29807/com.bankid.bus
created: 2018-10-18T09:19:40Z
last-modified: 2019-05-22T16:29:02Z
source: RIPE
person: Torbjorn Friberg
address: Kungsgatan 33
address: SE-111 56 Stockholm
address: Sweden
phone: +46 84118150
nic-hdl: TF3806-RIPE
mnt-by: RESILANS-MNT
created: 2017-04-04T07:34:33Z
last-modified: 2017-04-07T08:57:35Z
source: RIPE # Filtered
% Information related to '185.198.4.0/24AS198949'
route: 185.198.4.0/24
descr: Finansiell ID-Teknik BID AB
origin: AS198949
mnt-by: RESILANS-MNT
created: 2020-05-18T07:25:48Z
last-modified: 2020-05-18T07:25:48Z
source: RIPE
% Information related to '185.198.4.0/24AS202837'
route: 185.198.4.0/24
descr: Finansiell ID-Teknik BID AB
origin: AS202837
mnt-by: RESILANS-MNT
created: 2018-11-22T08:46:25Z
last-modified: 2018-11-22T08:46:25Z
source: RIPE
Medans vi har identifieringen öppen, så dyker även deta upp under netstat:
tcp 0 0 xxxxxxx:xxxxx 185.198.4.19:80 ESTABLISHED 29807/com.bankid.bus
tcp6 0 0 ::ffff:xxxxxxx:xxxxx:53688 ::ffff:13.33.141.91:443 ESTABLISHED 29807/com.bankid.bus
tcp6 0 0 ::ffff:xxxxxxx:xxxxx:33994 ::ffff:185.198.4.18:443 ESTABLISHED 29807/com.bankid.bus
tcp6 0 0 ::ffff:xxxxxxx:xxxxx:53688 ::ffff:13.33.141.91:443 ESTABLISHED 29807/com.bankid.bus
tcp6 0 0 ::ffff:xxxxxxx:xxxxx:33994 ::ffff:185.198.4.18:443 ESTABLISHED 29807/com.bankid.bus
Sluta grina, sluta ljug, sluta sprida skit sluta förök sprida skit, sluta försök leka seriös, sluta försök hitta på, sluta försök verka bäst! Diskutera istället.
PORT 80!!!! Skyller du på mig men inte dom spider dynga? Vet du vad ESTABLISHED betyder?
Nog om detta, nu får fan bidra med något.
// wuseman
__________________
Senast redigerad av wuseman 2022-08-17 kl. 21:34.
Senast redigerad av wuseman 2022-08-17 kl. 21:34.
Nu hade jag inte kollat så jävla noga tidigare, men nu tog jag tag i saken och kollade upp det ena och andra jävla hotten tottare:
1. Först så kollade jag i process mapp dvs /proc/pid/net/...
2. Sedan sniffade jag trafiken med iptables på följande vis:
- Först måste vi veta vilken uid som våran app använder, de får vi tag på med:
Vi lägger till ovan i nedan:
Nu kan använda oss av iptables:
Till
Vi måste köra root, vi sniffar all trafik med maximal verbose output:
Vi kollar, ACCEPT, DROP, OUTPUT, FORWARD och REJECT som har med våran uid att göra för applikationen eftersom vi inte kan använda com.bankid.bus så använder oss av appUID och gör exakt som nedan:
KOLLA VAD SOM DÖK UPP!!!
https://i.imgur.com/kI1lpdi.png
Både in och ut trafik, och nf_tables har förändrats i processen för våran applikation mappen för net. Hur gick det till teknisk? Det skall jag inte diskutera, det får personen ovan göra och alla andra som bara skriver hur lätt allting är utan att skriva ut en ändaste detalj.
Vill du använda dig av grafiskt istället OM du är intresserad på riktigt och vill prova själv vilket jag antar det finns många som vill, jag förstår dock vcarför så skriver men isåfall se här för exempel på hur man kan göra: https://developer.android.com/studio...twork-profiler
För att sniffa trafiken med wireshark te.x i grafisk miljö, använd tcpdump och använd wireshark för att läsa stdin, det kräver root så använd emulator om ni ej har rootat luren.tcpdump är med från stock rom:
Altenativt ssh om du använder dig openssh: byt ut adb shell till ssh istället.
Använder du wireshark i Windows så funkar det lika fint naturligtvis för att motbevisa alla inlägg från dom som kan bäst, något liklnande nedan:
Ändra wireshark till rätt mapp och adb.exe också "C:\Program....\Wireshark\Wireshark.exe" så funkar det lika bra som ovan i linux och osx, ingen skall INTE få vara med och se verkligheten här om man vill
För att kolla vad som sker exakt, kolla i /proc/pid...
- Hur fungerar det egentligen, tekniskt inte i fantasin med dessa applikationer egentligen med tokens och speciellt bankid som topic handlar om?
Hint:
skuid - UID associated with originating socket
Netfilter dokumentation: https://www.netfilter.org/projects/n...s/manpage.html
// wueseman
1. Först så kollade jag i process mapp dvs /proc/pid/net/...
2. Sedan sniffade jag trafiken med iptables på följande vis:
- Först måste vi veta vilken uid som våran app använder, de får vi tag på med:
Kod:
cmd package list packages -U|awk -F: '/com.bankid.bus/{print $3}'
10375
Vi lägger till ovan i nedan:
Kod:
appUID=$(cmd package list packages -U|awk -F: '/com.bankid.bus/{print $3}')
Nu kan använda oss av iptables:
Kod:
iptables -I OUTPUT -m owner --uid-owner ${appUID} -j LOG --log-level 7 --log-prefix 'SNIFFING_TO_EXPOSE_NOOBS_THAT_CRY: ' --log-uid
Till
Kod:
owner: Could not determine whether revision 1 is supported, assuming it is. iptables v1.8.7 (legacy): can't initialize iptables table `filter': Permission denied (you must be root) Perhaps iptables or your kernel needs to be upgraded.
Vi måste köra root, vi sniffar all trafik med maximal verbose output:
Vi kollar, ACCEPT, DROP, OUTPUT, FORWARD och REJECT som har med våran uid att göra för applikationen eftersom vi inte kan använda com.bankid.bus så använder oss av appUID och gör exakt som nedan:
Kod:
su -c iptables -I DROP -m owner --uid-owner ${appUID} -j LOG --log-level 7 --log-prefix 'DROP--SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG: ' --log-uid
su -c iptables -I OUTPUT -m owner --uid-owner ${appUID} -j LOG --log-level 7 --log-prefix 'OUTPUT--SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG: ' --log-uid
su -c iptables -I INPUT -m owner --uid-owner ${appUID} -j LOG --log-level 7 --log-prefix 'INPUT--SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG: ' --log-uid
su -c iptables -I FORWARD -m owner --uid-owner ${appUID} -j LOG --log-level 7 --log-prefix 'FORWARD--SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG: ' --log-uid
su -c iptables -I REJECT -m owner --uid-owner ${appUID} -j LOG --log-level 7 --log-prefix '-REJECT--SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG: ' --log-uid
KOLLA VAD SOM DÖK UPP!!!
Kod:
SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG: IN=wlan0 OUT= SRC=185.198.4.19 DST=192.168.1.231 LEN=210 TOS=0x00 PREC=0x00 TTL=52 ID=37793 DF PROTO=TCP SPT=80 DPT=56592 WINDOW=59 RES=0x00 ACK PSH URGP=0 UID=10375 GID=10375 MARK=0x3008d SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG= OUT=wlan0 SRC=192.168.1.231 DST=185.198.4.19 LEN=168 TOS=0x00 PREC=0x00 TTL=64 ID=21921 DF PROTO=TCP SPT=56592 DPT=80 WINDOW=67 RES=0x00 ACK PSH URGP=0 UID=10375 GID=10375 MARK=0x8d SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG: IN= OUT=wlan0 SRC=192.168.1.231 DST=185.198.4.19 LEN=168 TOS=0x00 PREC=0x00 TTL=64 ID=21921 DF PROTO=TCP SPT=56592 DPT=80 WINDOW=67 RES=0x00 ACK PSH URGP=0 UID=10375 GID=10375 MARK=0x8d SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG: IN=wlan0 OUT= SRC=185.198.4.19 DST=192.168.1.231 LEN=52 TOS=0x00 PREC=0x00 TTL=52 ID=37794 DF PROTO=TCP SPT=80 DPT=56592 WINDOW=59 RES=0x00 ACK URGP=0 UID=10375 GID=10375 MARK=0x3008d SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG IN=wlan0 OUT= SRC=185.198.4.18 DST=192.168.1.231 LEN=105 TOS=0x00 PREC=0x00 TTL=52 ID=16342 DF PROTO=TCP SPT=443 DPT=48370 WINDOW=67 RES=0x00 ACK PSH URGP=0 UID=10375 GID=10375 MARK=0x3008d SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG= OUT=wlan0 SRC=192.168.1.231 DST=185.198.4.18 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=24151 DF PROTO=TCP SPT=48370 DPT=443 WINDOW=72 RES=0x00 ACK URGP=0 UID=10375 GID=10375 MARK=0x8d
https://i.imgur.com/kI1lpdi.png
Citat:
13.49.251.196 => STOCKHOLM > Amazon Data Services Sweden (AT-1921)
185.198.4.18 => SE-111 56 Stockholm, Finansiell ID-Teknik BID AB
185.198.4.10 => SE-111 56 Stockholm, Finansiell ID-Teknik BID AB
185.198.4.18 => SE-111 56 Stockholm, Finansiell ID-Teknik BID AB
185.198.4.10 => SE-111 56 Stockholm, Finansiell ID-Teknik BID AB
Både in och ut trafik, och nf_tables har förändrats i processen för våran applikation mappen för net. Hur gick det till teknisk? Det skall jag inte diskutera, det får personen ovan göra och alla andra som bara skriver hur lätt allting är utan att skriva ut en ändaste detalj.
Vill du använda dig av grafiskt istället OM du är intresserad på riktigt och vill prova själv vilket jag antar det finns många som vill, jag förstår dock vcarför så skriver men isåfall se här för exempel på hur man kan göra: https://developer.android.com/studio...twork-profiler
För att sniffa trafiken med wireshark te.x i grafisk miljö, använd tcpdump och använd wireshark för att läsa stdin, det kräver root så använd emulator om ni ej har rootat luren.tcpdump är med från stock rom:
Kod:
adb shell su -c tcpdump -i any -U -s0 -vvvv -ttt -A -w - 'not port 5555' | wireshark -k -i -
Altenativt ssh om du använder dig openssh: byt ut adb shell till ssh istället.
Använder du wireshark i Windows så funkar det lika fint naturligtvis för att motbevisa alla inlägg från dom som kan bäst, något liklnande nedan:
Kod:
C:\platform-tools\adb.exe shell su -c tcpdump -i any -U -s0 -vvvv -ttt -A -w - 'not port 5555' | C:\Program\Wireshark\wireshark.exe -k -i -
Ändra wireshark till rätt mapp och adb.exe också "C:\Program....\Wireshark\Wireshark.exe" så funkar det lika bra som ovan i linux och osx, ingen skall INTE få vara med och se verkligheten här om man vill
För att kolla vad som sker exakt, kolla i /proc/pid...
- Hur fungerar det egentligen, tekniskt inte i fantasin med dessa applikationer egentligen med tokens och speciellt bankid som topic handlar om?
Citat:
A limit statement matches at a limited rate using a token bucket filter. A rule using this statement will match until this limit is reached. It can be used in combination with the log statement to give limited logging. The optional over keyword makes it match over the specified rate.
Hint:
skuid - UID associated with originating socket
Netfilter dokumentation: https://www.netfilter.org/projects/n...s/manpage.html
// wueseman
__________________
Senast redigerad av wuseman 2022-08-18 kl. 00:16.
Senast redigerad av wuseman 2022-08-18 kl. 00:16.
Citat:
Nu hade jag inte kollat så jävla noga tidigare, men nu tog jag tag i saken och kollade upp det ena och andra jävla hotten tottare:
1. Först så kollade jag i process mapp dvs /proc/pid/net/...
2. Sedan sniffade jag trafiken med iptables på följande vis:
- Först måste vi veta vilken uid som våran app använder, de får vi tag på med:
Vi lägger till ovan i nedan:
Nu kan använda oss av iptables:
Till
Vi måste köra root, vi sniffar all trafik med maximal verbose output:
Vi kollar, ACCEPT, DROP, OUTPUT, FORWARD och REJECT som har med våran uid att göra för applikationen eftersom vi inte kan använda com.bankid.bus så använder oss av appUID och gör exakt som nedan:
KOLLA VAD SOM DÖK UPP!!!
https://i.imgur.com/kI1lpdi.png
Både in och ut trafik, och nf_tables har förändrats i processen för våran applikation mappen för net. Hur gick det till teknisk? Det skall jag inte diskutera, det får personen ovan göra och alla andra som bara skriver hur lätt allting är utan att skriva ut en ändaste detalj.
Vill du använda dig av grafiskt istället OM du är intresserad på riktigt och vill prova själv vilket jag antar det finns många som vill, jag förstår dock vcarför så skriver men isåfall se här för exempel på hur man kan göra: https://developer.android.com/studio...twork-profiler
För att sniffa trafiken med wireshark te.x i grafisk miljö, använd tcpdump och använd wireshark för att läsa stdin, det kräver root så använd emulator om ni ej har rootat luren.tcpdump är med från stock rom:
Altenativt ssh om du använder dig openssh: byt ut adb shell till ssh istället.
Använder du wireshark i Windows så funkar det lika fint naturligtvis för att motbevisa alla inlägg från dom som kan bäst, något liklnande nedan:
Ändra wireshark till rätt mapp och adb.exe också "C:\Program....\Wireshark\Wireshark.exe" så funkar det lika bra som ovan i linux och osx, ingen skall INTE få vara med och se verkligheten här om man vill
För att kolla vad som sker exakt, kolla i /proc/pid...
- Hur fungerar det egentligen, tekniskt inte i fantasin med dessa applikationer egentligen med tokens och speciellt bankid som topic handlar om?
Hint:
skuid - UID associated with originating socket
Netfilter dokumentation: https://www.netfilter.org/projects/n...s/manpage.html
// wueseman
1. Först så kollade jag i process mapp dvs /proc/pid/net/...
2. Sedan sniffade jag trafiken med iptables på följande vis:
- Först måste vi veta vilken uid som våran app använder, de får vi tag på med:
Kod:
cmd package list packages -U|awk -F: '/com.bankid.bus/{print $3}'
10375
Vi lägger till ovan i nedan:
Kod:
appUID=$(cmd package list packages -U|awk -F: '/com.bankid.bus/{print $3}')
Nu kan använda oss av iptables:
Kod:
iptables -I OUTPUT -m owner --uid-owner ${appUID} -j LOG --log-level 7 --log-prefix 'SNIFFING_TO_EXPOSE_NOOBS_THAT_CRY: ' --log-uid
Till
Kod:
owner: Could not determine whether revision 1 is supported, assuming it is. iptables v1.8.7 (legacy): can't initialize iptables table `filter': Permission denied (you must be root) Perhaps iptables or your kernel needs to be upgraded.
Vi måste köra root, vi sniffar all trafik med maximal verbose output:
Vi kollar, ACCEPT, DROP, OUTPUT, FORWARD och REJECT som har med våran uid att göra för applikationen eftersom vi inte kan använda com.bankid.bus så använder oss av appUID och gör exakt som nedan:
Kod:
su -c iptables -I DROP -m owner --uid-owner ${appUID} -j LOG --log-level 7 --log-prefix 'DROP--SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG: ' --log-uid
su -c iptables -I OUTPUT -m owner --uid-owner ${appUID} -j LOG --log-level 7 --log-prefix 'OUTPUT--SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG: ' --log-uid
su -c iptables -I INPUT -m owner --uid-owner ${appUID} -j LOG --log-level 7 --log-prefix 'INPUT--SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG: ' --log-uid
su -c iptables -I FORWARD -m owner --uid-owner ${appUID} -j LOG --log-level 7 --log-prefix 'FORWARD--SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG: ' --log-uid
su -c iptables -I REJECT -m owner --uid-owner ${appUID} -j LOG --log-level 7 --log-prefix '-REJECT--SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG: ' --log-uid
KOLLA VAD SOM DÖK UPP!!!
Kod:
SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG: IN=wlan0 OUT= SRC=185.198.4.19 DST=192.168.1.231 LEN=210 TOS=0x00 PREC=0x00 TTL=52 ID=37793 DF PROTO=TCP SPT=80 DPT=56592 WINDOW=59 RES=0x00 ACK PSH URGP=0 UID=10375 GID=10375 MARK=0x3008d SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG= OUT=wlan0 SRC=192.168.1.231 DST=185.198.4.19 LEN=168 TOS=0x00 PREC=0x00 TTL=64 ID=21921 DF PROTO=TCP SPT=56592 DPT=80 WINDOW=67 RES=0x00 ACK PSH URGP=0 UID=10375 GID=10375 MARK=0x8d SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG: IN= OUT=wlan0 SRC=192.168.1.231 DST=185.198.4.19 LEN=168 TOS=0x00 PREC=0x00 TTL=64 ID=21921 DF PROTO=TCP SPT=56592 DPT=80 WINDOW=67 RES=0x00 ACK PSH URGP=0 UID=10375 GID=10375 MARK=0x8d SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG: IN=wlan0 OUT= SRC=185.198.4.19 DST=192.168.1.231 LEN=52 TOS=0x00 PREC=0x00 TTL=52 ID=37794 DF PROTO=TCP SPT=80 DPT=56592 WINDOW=59 RES=0x00 ACK URGP=0 UID=10375 GID=10375 MARK=0x3008d SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG IN=wlan0 OUT= SRC=185.198.4.18 DST=192.168.1.231 LEN=105 TOS=0x00 PREC=0x00 TTL=52 ID=16342 DF PROTO=TCP SPT=443 DPT=48370 WINDOW=67 RES=0x00 ACK PSH URGP=0 UID=10375 GID=10375 MARK=0x3008d SNIFFING_FOR_PROOVE_THE_CYBE3R_EXPERTS_WRONG= OUT=wlan0 SRC=192.168.1.231 DST=185.198.4.18 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=24151 DF PROTO=TCP SPT=48370 DPT=443 WINDOW=72 RES=0x00 ACK URGP=0 UID=10375 GID=10375 MARK=0x8d
https://i.imgur.com/kI1lpdi.png
Både in och ut trafik, och nf_tables har förändrats i processen för våran applikation mappen för net. Hur gick det till teknisk? Det skall jag inte diskutera, det får personen ovan göra och alla andra som bara skriver hur lätt allting är utan att skriva ut en ändaste detalj.
Vill du använda dig av grafiskt istället OM du är intresserad på riktigt och vill prova själv vilket jag antar det finns många som vill, jag förstår dock vcarför så skriver men isåfall se här för exempel på hur man kan göra: https://developer.android.com/studio...twork-profiler
För att sniffa trafiken med wireshark te.x i grafisk miljö, använd tcpdump och använd wireshark för att läsa stdin, det kräver root så använd emulator om ni ej har rootat luren.tcpdump är med från stock rom:
Kod:
adb shell su -c tcpdump -i any -U -s0 -vvvv -ttt -A -w - 'not port 5555' | wireshark -k -i -
Altenativt ssh om du använder dig openssh: byt ut adb shell till ssh istället.
Använder du wireshark i Windows så funkar det lika fint naturligtvis för att motbevisa alla inlägg från dom som kan bäst, något liklnande nedan:
Kod:
C:\platform-tools\adb.exe shell su -c tcpdump -i any -U -s0 -vvvv -ttt -A -w - 'not port 5555' | C:\Program\Wireshark\wireshark.exe -k -i -
Ändra wireshark till rätt mapp och adb.exe också "C:\Program....\Wireshark\Wireshark.exe" så funkar det lika bra som ovan i linux och osx, ingen skall INTE få vara med och se verkligheten här om man vill
För att kolla vad som sker exakt, kolla i /proc/pid...
- Hur fungerar det egentligen, tekniskt inte i fantasin med dessa applikationer egentligen med tokens och speciellt bankid som topic handlar om?
Hint:
skuid - UID associated with originating socket
Netfilter dokumentation: https://www.netfilter.org/projects/n...s/manpage.html
// wueseman
Problemet är inte huruvida du kan något - det kan du säkert.
Problemet är att det är helt omöjligt att förstå vad fan du skriver. Det är som att du mitt under pågående psykos dragit ladd och sen satt dig ner bakom tangentbordet.
Citat:
Jag förstår jag förstår, hur skall jag förklara så du förstår då? Skall jag förklara så som det INTE är? Det gör ju så många andra så bra redan, om ingen bevisar motsatsen. Skall man då sitta här och skriva saker som inte stämmer så borde ju tråden flytta plats till konspirationsteorier.
Men nog om det, förstår du någonting här: https://developer.android.com/traini...h/authenticate ?
Det som står inom text boxarna där, det är samma sak som jag visat ovan fast jag visade med exakta exempel med appen som diskuteras här dvs com.bankid och hur man kan skicka en signal till bankid via en broadcast, en broadcast. En broadcast är en term inom datorkommunikation som innebär att paket som skickas mottages av alla på nätverket. I motsats till enkelsändning är som sagts informationen som skickas adresserad till alla noderna i nätverket, vilket även namnet tyder på. Inte alla former av nätverk stödjer broadcastning.
Detta betyder att den kan få tillgång till internet och även få tillgång statusen på nätverket. Den har även tillgång till write settings vilket betyder att den får modifiera systemet och dina internet inställningar för in och utgåend etrafik från enheten vilket jag visar ovan med IN= och OUT= trafik från en servers ip address.
<uses-permission android:name="android.permission.INTERNET" />
Eftrersom jag inte kan förklara närmare i detalj så får något annan göra det, men både DATORN och TELEFONEN samtalar med en ip address, så får någon an nan göra det. Men att säga att den inte samtalar med något och sådant här trams, är bara sjukt. Först får man kolla vad för behörigheter den har, sedan får man kolla vad dom behörigheterna har rätt att göra, sedan får man ta det eftersom.
Jag skrev även tidigare i tråden att den har tillåtelse att styra din enhet, dvs ändr ainställningar men det rätta ordet är antagligen "modiifiera" vilet förändrar ett värde på telefonen. Det stämde inte heller tydligen men så är det iaf.
Du får hoppas någonmed pedagogisk utveckling och interaktivt lärande kan komma in och förkalra SAMT förstå vad som sker, det är ju kruxxet uppenbarligen för många..
Nåväl, bra att du sa till. Jag återgår till psykos världen och lämnar härmed tråden för dom som kan förklara bättre, det vore ju förjävligt att slösa sin dyrbara tid på något som man inte förstår ändå.
// wuseman
__________________
Senast redigerad av wuseman 2022-08-18 kl. 07:54.
Senast redigerad av wuseman 2022-08-18 kl. 07:54.
Det är egentligen ganska enkelt. BankID köar upp förfrågningar i sin server och appen pollar sedan med jämna intervall så länge den är i förgrunden.
När den hittar ett jobb som matchar innehavarens UUID så servar den en autentiseringsdialog, och vid godkänt autentiseringsförsök postar den tillbaka detta.
Anledningen till att den pollar utan SSL torde vara att informationen är helt meningslös i sig sålänge den saknar signering. Har dock inte verifierat att den verkligen enbart går över http själv utan utgår från det wuseman skrev.
Dynamisk DNS används med andra ord inte, inte någon direktanslutning till din telefon heller då det är helt omöjligt att garantera att telefonen förblir routebar.
Krävs varken pcaps, curl eller adb för att lista ut.
När den hittar ett jobb som matchar innehavarens UUID så servar den en autentiseringsdialog, och vid godkänt autentiseringsförsök postar den tillbaka detta.
Anledningen till att den pollar utan SSL torde vara att informationen är helt meningslös i sig sålänge den saknar signering. Har dock inte verifierat att den verkligen enbart går över http själv utan utgår från det wuseman skrev.
Dynamisk DNS används med andra ord inte, inte någon direktanslutning till din telefon heller då det är helt omöjligt att garantera att telefonen förblir routebar.
Krävs varken pcaps, curl eller adb för att lista ut.
Citat:
Jag skrev i ett tidigare inlägg kortfattat hur en förfrågan går till och inkluderade då en länk till BankID's egen guide för hur man hanterar BankID-inloggning i sin egen app.
https://www.bankid.com/en/utvecklare...egrationsguide
Lite rörig och väl sparsmakad guide kan jag tycka, men det mesta står där. Om jag har kunnat fixa BankID-inloggning till en app så kan "vemsomhelst".
Citat:
Det är egentligen ganska enkelt. BankID köar upp förfrågningar i sin server och appen pollar sedan med jämna intervall så länge den är i förgrunden.
När den hittar ett jobb som matchar innehavarens UUID så servar den en autentiseringsdialog, och vid godkänt autentiseringsförsök postar den tillbaka detta.
Anledningen till att den pollar utan SSL torde vara att informationen är helt meningslös i sig sålänge den saknar signering. Har dock inte verifierat att den verkligen enbart går över http själv utan utgår från det wuseman skrev.
Dynamisk DNS används med andra ord inte, inte någon direktanslutning till din telefon heller då det är helt omöjligt att garantera att telefonen förblir routebar.
Krävs varken pcaps, curl eller adb för att lista ut.
När den hittar ett jobb som matchar innehavarens UUID så servar den en autentiseringsdialog, och vid godkänt autentiseringsförsök postar den tillbaka detta.
Anledningen till att den pollar utan SSL torde vara att informationen är helt meningslös i sig sålänge den saknar signering. Har dock inte verifierat att den verkligen enbart går över http själv utan utgår från det wuseman skrev.
Dynamisk DNS används med andra ord inte, inte någon direktanslutning till din telefon heller då det är helt omöjligt att garantera att telefonen förblir routebar.
Krävs varken pcaps, curl eller adb för att lista ut.
Jo det är klart, men hur kan servern kontakta appen när/om telefonen har en brandvägg vilket den har per default? Den kommunicerar på port 80 och även 443 och då behövs det dom verktygen bl.a för att kunna ta del av den informationen och se det.
Om man går in till valfri site, skickar en förfrågan om login och så poppar bankid upp och sedan kollar man på enheten oavsett om det är en telefon eller dator via netstat. Så kommer det att bli etablerad anslutning mellan din ip address och en av dom två ip addresserna som leder till bankids server. Då har man ju direkt kontakt med servern?
Kollar man även med lsof, som visar vilka filer som ens app använder så ser man flera processer som har en socket anslutning och det är direkt mot deras ip också.
INTERNET.PERMISSION som är en behörighet man måste ge tillgång till bankid har/får rättigheter att modifiera internet inställningarna på enheten de är vad behörigheten gör så det är inget konstigt egentligen.
Om man sniffar trafiken, det spelar nog ingen roll vilken enhet på mobil det gäller men den jag har här iaf med bankid på använder "rmnet4" interfacet för internet för mobilnätverk, det kan jämföras med te.x är wlan0 eller eth0 på en dator men men på telefoner heter dom oftast rmnet, "r" iom roaming och "m" för mobil och "net" för nätverk så detta är helt enkelt nätverksenheten för mobilt nätverk.
Listar man enhetens brandvägg regler med "iptables -L" som betyder list ip tables helt enkelt så ser man: "bw_costly_rmnet4 all -- anywhere anywhere " det betyder att all trafik överallt är tillåten och då behöver appen aldrig kringå en brandvägg för trafiken är alltid tillåten på rmnet4
på det viset dom kommunicerar med ens enhet och android permissions ger man tilltåelse till när man installerar appen annars kan man inte använda appen och kommunicera med servern så det är ett måste och denna inställningen har tillåtelse att modifiera ens nätverks inställningar och kan om det behövs te.x lägga till en regel så att vi får kommunicera med deras server in/ut om det krävs så man behöver inte kringå någon brandvägg.
Det är det jag menade, inte något annat med det jag sdkrev tidigare, nästa steg i proceduren är det som du berättar med ditt inlägg hur man loggar in och det blir verifierat. Så det är två olika saker vi skirver om men dom båda berör ändå hur det går till och det senare altenativet vet du bättre än mig men för att ens komma hit till den steg i processen så måste det ske allt annat före så att säga och det är där jag är och det är det jag skriver om även om det går på microsekunder. Hurvida man signar med eller utan ssl eller skickar någon data har jag ingten aning om men den lyssnar iaf på http och port 80 OCH ssl men när förfrågan kommer in så kommer den på port 80, därefter har jag inte fortsatt följa trafiken för det är jku själva bankid det diskuteras så det kan mycket väl ske med ssl därefter det vet inte jag vad som händer sen eller nu vet jag nu när du berättat.
Nu är bankid en rätt tråkig app för den gör inget som den inte borde den tar emot och skickar authen sen raderar den all info precis som den skall så det är inte ultimat att ta det som exempel som jag visat kanske men det är mer intressant att följa andra appar för att kunna se mer detaljerat för det händer mycket skumt på en telefon men bankid är ett dåligt exempel om man vill förstå processen och kanske är nyfiken på området om man själv vill kolla och lära sig så jag förstår det inte gav mycket kanske nu i efterhand det jag skrev, men oavsett vad iaf så är det inte något behov av att kringå någon brandvägg .
Vill man veta exakt vad bankid använder för tokens/gps/behörigheter m.m så kan man om man har lust och vill se under skalet om man är nyfiken kanske inte vet jag iaf låsa filerna som skapas precis under sekunden den authar för att veta vad det är den skapar och raderar under en auth på den korta stunden för man hinner inte kopiera manuellt eftersom det går så fort tills att den raderar temp filerna som skapas under authen.
den sparar exit reason te..x för att logga och veta om ens gps location är fine eller wrong:
Kod:
z3s:/data/data/com.bankid.bus # cat shared_prefs/pp_shared_prefs.xml
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<int name="xxxxxxxxxxxxxx" value="1" />
<int name="Latest_exit_reason" value="13" />
<int name="xxxxxxxxxxxx" value="169" />
<int name="74accd_android.permission.ACCESS_FINE_LOCATION" value="xxxxxxx" />
<int name="74accd_android.permission.CAMERA" value="xxxxxxx" />
<string name="xxxxxxxxx"></string>
<int name="Latest_error_code" value="15" />
<string name="language_pref_name">sv</string>
<string name="xxxxxxxxx">xxxxxxxx</string>
</map>
Därför vet appen te.x ifall om man använder den på en emulator och därför går det inte använda den på en emulator te.x då det inte finns en riktig sensor fölr location i en dator oftast.
Topic handlade om hur den kringår så därför tog jag upp detta för den som är nyfiken och inte vet och vad allt betyder finns i manifeset
Det sker en hel del kontroller innan man kommer till tokens överhuvud taget, den kollar framförallt CAMERA och LOCATION sedan kommer INTERNET permission
Själva tokens finns i nedan och id:it finns i 0.ngp filen som jag skrivit om tidigare den innehåller även personnummret, banken och för/efternamn för att kunna skapa idit.
com.google.android.gms.appid.xml
com.google.firebase.messaging.xml
FirebaseAppHeartBeat.xml
com.bankid.bus_preferences.xml
pp_shared_prefs.xml
Det är ju inte bara bara så att säga så "enkelt" det är en jävla process innan den ens kommit till signeringen, nu skriver jag om det som sker från att första paketet in i telefonen tas emot till man skall skriva in koden i appen, sedan börjar det du skrev om som sagt detta är hur en telefon fungferar inte bankid i sig så det är inte bankid som kringår brandväggen det är en funktion i telefonen kan man säga.
Nu försökte jag berätta på ett annat sätt, är det fortfarande oförståeligt hur jag menade så kan jag inte bättre förklarat.
__________________
Senast redigerad av wuseman 2022-08-19 kl. 19:27.
Senast redigerad av wuseman 2022-08-19 kl. 19:27.
Citat:
Jo det är klart, men hur kan servern kontakta appen när/om telefonen har en brandvägg vilket den har per default? Den kommunicerar på port 80 och även 443 och då behövs det dom verktygen bl.a för att kunna ta del av den informationen och se det.
Om man går in till valfri site, skickar en förfrågan om login och så poppar bankid upp och sedan kollar man på enheten oavsett om det är en telefon eller dator via netstat. Så kommer det att bli etablerad anslutning mellan din ip address och en av dom två ip addresserna som leder till bankids server. Då har man ju direkt kontakt med servern?
Kollar man även med lsof, som visar vilka filer som ens app använder så ser man flera processer som har en socket anslutning och det är direkt mot deras ip också.
INTERNET.PERMISSION som är en behörighet man måste ge tillgång till bankid har/får rättigheter att modifiera internet inställningarna på enheten de är vad behörigheten gör så det är inget konstigt egentligen.
Om man sniffar trafiken, det spelar nog ingen roll vilken enhet på mobil det gäller men den jag har här iaf med bankid på använder "rmnet4" interfacet för internet för mobilnätverk, det kan jämföras med te.x är wlan0 eller eth0 på en dator men men på telefoner heter dom oftast rmnet, "r" iom roaming och "m" för mobil och "net" för nätverk så detta är helt enkelt nätverksenheten för mobilt nätverk.
Listar man enhetens brandvägg regler med "iptables -L" som betyder list ip tables helt enkelt så ser man: "bw_costly_rmnet4 all -- anywhere anywhere " det betyder att all trafik överallt är tillåten och då behöver appen aldrig kringå en brandvägg för trafiken är alltid tillåten på rmnet4
på det viset dom kommunicerar med ens enhet och android permissions ger man tilltåelse till när man installerar appen annars kan man inte använda appen och kommunicera med servern så det är ett måste och denna inställningen har tillåtelse att modifiera ens nätverks inställningar och kan om det behövs te.x lägga till en regel så att vi får kommunicera med deras server in/ut om det krävs så man behöver inte kringå någon brandvägg.
Det är det jag menade, inte något annat med det jag sdkrev tidigare, nästa steg i proceduren är det som du berättar med ditt inlägg hur man loggar in och det blir verifierat. Så det är två olika saker vi skirver om men dom båda berör ändå hur det går till och det senare altenativet vet du bättre än mig men för att ens komma hit till den steg i processen så måste det ske allt annat före så att säga och det är där jag är och det är det jag skriver om även om det går på microsekunder. Hurvida man signar med eller utan ssl eller skickar någon data har jag ingten aning om men den lyssnar iaf på http och port 80 OCH ssl men när förfrågan kommer in så kommer den på port 80, därefter har jag inte fortsatt följa trafiken för det är jku själva bankid det diskuteras så det kan mycket väl ske med ssl därefter det vet inte jag vad som händer sen eller nu vet jag nu när du berättat.
Nu är bankid en rätt tråkig app för den gör inget som den inte borde den tar emot och skickar authen sen raderar den all info precis som den skall så det är inte ultimat att ta det som exempel som jag visat kanske men det är mer intressant att följa andra appar för att kunna se mer detaljerat för det händer mycket skumt på en telefon men bankid är ett dåligt exempel om man vill förstå processen och kanske är nyfiken på området om man själv vill kolla och lära sig så jag förstår det inte gav mycket kanske nu i efterhand det jag skrev, men oavsett vad iaf så är det inte något behov av att kringå någon brandvägg .
Vill man veta exakt vad bankid använder för tokens/gps/behörigheter m.m så kan man om man har lust och vill se under skalet om man är nyfiken kanske inte vet jag iaf låsa filerna som skapas precis under sekunden den authar för att veta vad det är den skapar och raderar under en auth på den korta stunden för man hinner inte kopiera manuellt eftersom det går så fort tills att den raderar temp filerna som skapas under authen.
den sparar exit reason te..x för att logga och veta om ens gps location är fine eller wrong:
Därför vet appen te.x ifall om man använder den på en emulator och därför går det inte använda den på en emulator te.x då det inte finns en riktig sensor fölr location i en dator oftast.
Topic handlade om hur den kringår så därför tog jag upp detta för den som är nyfiken och inte vet och vad allt betyder finns i manifeset
Det sker en hel del kontroller innan man kommer till tokens överhuvud taget, den kollar framförallt CAMERA och LOCATION sedan kommer INTERNET permission
Själva tokens finns i nedan och id:it finns i 0.ngp filen som jag skrivit om tidigare den innehåller även personnummret, banken och för/efternamn för att kunna skapa idit.
com.google.android.gms.appid.xml
com.google.firebase.messaging.xml
FirebaseAppHeartBeat.xml
com.bankid.bus_preferences.xml
pp_shared_prefs.xml
Det är ju inte bara bara så att säga så "enkelt" det är en jävla process innan den ens kommit till signeringen, nu skriver jag om det som sker från att första paketet in i telefonen tas emot till man skall skriva in koden i appen, sedan börjar det du skrev om som sagt detta är hur en telefon fungferar inte bankid i sig så det är inte bankid som kringår brandväggen det är en funktion i telefonen kan man säga.
Nu försökte jag berätta på ett annat sätt, är det fortfarande oförståeligt hur jag menade så kan jag inte bättre förklarat.
Om man går in till valfri site, skickar en förfrågan om login och så poppar bankid upp och sedan kollar man på enheten oavsett om det är en telefon eller dator via netstat. Så kommer det att bli etablerad anslutning mellan din ip address och en av dom två ip addresserna som leder till bankids server. Då har man ju direkt kontakt med servern?
Kollar man även med lsof, som visar vilka filer som ens app använder så ser man flera processer som har en socket anslutning och det är direkt mot deras ip också.
INTERNET.PERMISSION som är en behörighet man måste ge tillgång till bankid har/får rättigheter att modifiera internet inställningarna på enheten de är vad behörigheten gör så det är inget konstigt egentligen.
Om man sniffar trafiken, det spelar nog ingen roll vilken enhet på mobil det gäller men den jag har här iaf med bankid på använder "rmnet4" interfacet för internet för mobilnätverk, det kan jämföras med te.x är wlan0 eller eth0 på en dator men men på telefoner heter dom oftast rmnet, "r" iom roaming och "m" för mobil och "net" för nätverk så detta är helt enkelt nätverksenheten för mobilt nätverk.
Listar man enhetens brandvägg regler med "iptables -L" som betyder list ip tables helt enkelt så ser man: "bw_costly_rmnet4 all -- anywhere anywhere " det betyder att all trafik överallt är tillåten och då behöver appen aldrig kringå en brandvägg för trafiken är alltid tillåten på rmnet4
på det viset dom kommunicerar med ens enhet och android permissions ger man tilltåelse till när man installerar appen annars kan man inte använda appen och kommunicera med servern så det är ett måste och denna inställningen har tillåtelse att modifiera ens nätverks inställningar och kan om det behövs te.x lägga till en regel så att vi får kommunicera med deras server in/ut om det krävs så man behöver inte kringå någon brandvägg.
Det är det jag menade, inte något annat med det jag sdkrev tidigare, nästa steg i proceduren är det som du berättar med ditt inlägg hur man loggar in och det blir verifierat. Så det är två olika saker vi skirver om men dom båda berör ändå hur det går till och det senare altenativet vet du bättre än mig men för att ens komma hit till den steg i processen så måste det ske allt annat före så att säga och det är där jag är och det är det jag skriver om även om det går på microsekunder. Hurvida man signar med eller utan ssl eller skickar någon data har jag ingten aning om men den lyssnar iaf på http och port 80 OCH ssl men när förfrågan kommer in så kommer den på port 80, därefter har jag inte fortsatt följa trafiken för det är jku själva bankid det diskuteras så det kan mycket väl ske med ssl därefter det vet inte jag vad som händer sen eller nu vet jag nu när du berättat.
Nu är bankid en rätt tråkig app för den gör inget som den inte borde den tar emot och skickar authen sen raderar den all info precis som den skall så det är inte ultimat att ta det som exempel som jag visat kanske men det är mer intressant att följa andra appar för att kunna se mer detaljerat för det händer mycket skumt på en telefon men bankid är ett dåligt exempel om man vill förstå processen och kanske är nyfiken på området om man själv vill kolla och lära sig så jag förstår det inte gav mycket kanske nu i efterhand det jag skrev, men oavsett vad iaf så är det inte något behov av att kringå någon brandvägg .
Vill man veta exakt vad bankid använder för tokens/gps/behörigheter m.m så kan man om man har lust och vill se under skalet om man är nyfiken kanske inte vet jag iaf låsa filerna som skapas precis under sekunden den authar för att veta vad det är den skapar och raderar under en auth på den korta stunden för man hinner inte kopiera manuellt eftersom det går så fort tills att den raderar temp filerna som skapas under authen.
den sparar exit reason te..x för att logga och veta om ens gps location är fine eller wrong:
Kod:
z3s:/data/data/com.bankid.bus # cat shared_prefs/pp_shared_prefs.xml
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<int name="xxxxxxxxxxxxxx" value="1" />
<int name="Latest_exit_reason" value="13" />
<int name="xxxxxxxxxxxx" value="169" />
<int name="74accd_android.permission.ACCESS_FINE_LOCATION" value="xxxxxxx" />
<int name="74accd_android.permission.CAMERA" value="xxxxxxx" />
<string name="xxxxxxxxx"></string>
<int name="Latest_error_code" value="15" />
<string name="language_pref_name">sv</string>
<string name="xxxxxxxxx">xxxxxxxx</string>
</map>
Därför vet appen te.x ifall om man använder den på en emulator och därför går det inte använda den på en emulator te.x då det inte finns en riktig sensor fölr location i en dator oftast.
Topic handlade om hur den kringår så därför tog jag upp detta för den som är nyfiken och inte vet och vad allt betyder finns i manifeset
Det sker en hel del kontroller innan man kommer till tokens överhuvud taget, den kollar framförallt CAMERA och LOCATION sedan kommer INTERNET permission
Själva tokens finns i nedan och id:it finns i 0.ngp filen som jag skrivit om tidigare den innehåller även personnummret, banken och för/efternamn för att kunna skapa idit.
com.google.android.gms.appid.xml
com.google.firebase.messaging.xml
FirebaseAppHeartBeat.xml
com.bankid.bus_preferences.xml
pp_shared_prefs.xml
Det är ju inte bara bara så att säga så "enkelt" det är en jävla process innan den ens kommit till signeringen, nu skriver jag om det som sker från att första paketet in i telefonen tas emot till man skall skriva in koden i appen, sedan börjar det du skrev om som sagt detta är hur en telefon fungferar inte bankid i sig så det är inte bankid som kringår brandväggen det är en funktion i telefonen kan man säga.
Nu försökte jag berätta på ett annat sätt, är det fortfarande oförståeligt hur jag menade så kan jag inte bättre förklarat.
Grejen är att det följer client/server-modellen, så det behövs ingen inkommande anslutning. Klienten gör en reach out till servern och push/pullar informationen. Utgående anslutningar släpper 99% av alla brandväggar igenom per default pga UPnP.
Inga vidare undersökningar är nödvändiga. Alla utvecklare eller forensiker värda sin vikt i salt bör kunna dra den slutsatsen omedelbart bara genom att läsa problembeskrivningen.
Citat:
Grejen är att det följer client/server-modellen, så det behövs ingen inkommande anslutning. Klienten gör en reach out till servern och push/pullar informationen. Utgående anslutningar släpper 99% av alla brandväggar igenom per default pga UPnP.
Inga vidare undersökningar är nödvändiga. Alla utvecklare eller forensiker värda sin vikt i salt bör kunna dra den slutsatsen omedelbart bara genom att läsa problembeskrivningen.
Inga vidare undersökningar är nödvändiga. Alla utvecklare eller forensiker värda sin vikt i salt bör kunna dra den slutsatsen omedelbart bara genom att läsa problembeskrivningen.
IN=wlan0 OUT= SRC=185.198.4.19 DST=192.168.1.231 LEN=210 TOS=0x00 PREC=0x00 TTL=52 ID=37793 DF PROTO=TCP SPT=80 DPT=56592 WINDOW=59 RES=0x00 ACK PSH URGP=0 UID=10375 GID=10375 MARK=0x3008d
https://apps.db.ripe.net/db-web-ui/q...t=185.198.4.19
Säger det motsatta? Gissar du eller? Uppenbarligen behövs det kollas upp för du har fel. Socke processerna talar för sig själv, varenda forensiker vet att man kollar upp saker innan man påstår sig veta någonting, eller vad vet jag vad dom gör detta är exakt vad som sker, iptables är en del av linux kärnan som hanterar inkommande och utgående trafik som samtalar med hårdvaran. Den skriver ut fel menar du?
"IN"
__________________
Senast redigerad av wuseman 2022-08-19 kl. 21:01.
Senast redigerad av wuseman 2022-08-19 kl. 21:01.
Citat:
IN=wlan0 OUT= SRC=185.198.4.19 DST=192.168.1.231 LEN=210 TOS=0x00 PREC=0x00 TTL=52 ID=37793 DF PROTO=TCP SPT=80 DPT=56592 WINDOW=59 RES=0x00 ACK PSH URGP=0 UID=10375 GID=10375 MARK=0x3008d
https://apps.db.ripe.net/db-web-ui/q...t=185.198.4.19
Säger det motsatta? Gissar du eller? Uppenbarligen behövs det kollas upp för du har fel. Socke processerna talar för sig själv, varenda forensiker vet att man kollar upp saker innan man påstår sig veta någonting, eller vad vet jag vad dom gör detta är exakt vad som sker, iptables är en del av linux kärnan som hanterar inkommande och utgående trafik som samtalar med hårdvaran. Den skriver ut fel menar du?
"IN"
https://apps.db.ripe.net/db-web-ui/q...t=185.198.4.19
Säger det motsatta? Gissar du eller? Uppenbarligen behövs det kollas upp för du har fel. Socke processerna talar för sig själv, varenda forensiker vet att man kollar upp saker innan man påstår sig veta någonting, eller vad vet jag vad dom gör detta är exakt vad som sker, iptables är en del av linux kärnan som hanterar inkommande och utgående trafik som samtalar med hårdvaran. Den skriver ut fel menar du?
"IN"
Slutsatsen du drar är felaktig. HTTP över TCP fungerar som så att servern skapar en socket där den lyssnar efter en request. När den mortality en request öppnar klienten en socket där den kan ta emot responsen.
Anledningen till att detta inte kräver en egen brandväggsregel är för att paketet tillhör en redan accepterad och etablerad utgående anslutning (på port 80). Hade detta inte varit fallet hade du inte kunnat komma åt någonting alls. Därav att du ser att source porten är 80 och desinationsporten en hög port I den dynamiska rangen.
Du har analyserat problemet så till den förbannelse att du ser red herrings där inget fuffens försigår.
Rekommenderar att du läser "TCP/IP Illustrated" av W. Richard Stevens för att lära dig mer om hur nätverkskommunikation fungerar fundamentalt.
Stöd Flashback
Flashback finansieras genom donationer från våra medlemmar och besökare. Det är med hjälp av dig vi kan fortsätta erbjuda en fri samhällsdebatt. Tack för ditt stöd!
Swish: 123 536 99 96 Bankgiro: 211-4106
