Inlägg

Prova att fimpa alla energisparläge i BIOS. Prova att omöjliggöra dom om möjlighet så att OS inte försöker sparka igång dom ändå.

Plus att den verkar ena gången ha gnällt på en lagringsenhet men det kan vara en bieffekt.
Vad kör Du för lagringsstyrenhet? LSI?

Glöm inte så låg ESR som möjligt(som ovanstående skriver) och kolla så att benavståndet är identiskt med original. Nu verkar dessa sitta parallellt och så pass många, så låg ESR är kanske inte det viktigaste.

Läge att öppna lådan och kolla om fläkten.

Så länge rengöringsmedlet luktar gott(citrus) så är det bara att köra på. Mina är nog ifrån år 2004/2006 och jag använde dom sist december 2019. Burken lirar än och inga konstigheter med temperaturer .

I detta fall så är det för att vi känner till våra lösenord. Därav är det inga svårigheter. Annars får man lägga ner tid på att knäcka lösenord eller prova att lista ut kryptonycklarna vilket kommer ta en evighet i vårt fall. Plus att vi redan har tillåtit inladdning utav TWRP på våra telefoner utav andra anledningar. Normalt så är det inte enkelt att byta ut recovery på en enhet om man inte tillåtit det inne i Android.

I hans exempel så krävs det en skicklig person/verktyg om det bara är låsskärmen som förhindrar åtkomst. Om telefonen är avstängd så är det jobbigare.

Kollar man på https://blog.oxygen-forensic.com/oxygen-forensic-detective-v-... så påstår dom att dom har stöd för att gå förbi skärmlåset.

Medan i FBE så kan man i praktiken skapa olika nycklar för olika filer och således ha olika nivåer på säkerhet. Plus att väckarklockan, kalenderpåminnelser och lite annat fungerar utan startlösenord .

Detta var på en CAT S60 som kör Android 6.0.

Absolut kan det vara så. Dom krypterade som jag har är Android 4.4.x samt 6.0. Den okrypterade är Android 8.0. Så jag har själv ingen Android 9 att prova mot, d.v.s. alla mina är FDE eller inget alls.

Kika i dmesg i terminalen ifall den avslöjar något specifikt i ditt fall. Se också om Du kan hitta en log mapp som TWRP skriver till. Kan troligtvis vara en RamDisk monterad mot /tmp eller hela vägen mot /var/log. Kanske finns något där som avslöjar. En annan grej, som dock kan ta längre tid, är att kika in i källkoden för just din version utav TWRP, att där kika på vilka metoder den kör för dekrypteringen.

Om det är filbaserad kryptering så är jag lost i detta fall då jag inte har sådant i dagsläget. Frågan blir om där finns färdiga verktyg som kan dekryptera FBE filer som är raderade.

Du får slå gänget på Oxygen-Forensic en signal och fråga efter en kopia utav https://www.oxygen-forensic.com/en/products/oxygen-forensic-d... .

Man kan även se "värms upp" som att komponenten initierar sig bättre när den startas om via en varmstart.

Tänk inte på kallstart/varmstart/"värmas upp" som direkt relaterat till temperatur. Det är mer ett talesätt .

Kallstart == Helt avstängd, sedan start.
Varmstart == omstart utan att bryta strömmen.
"Värmas upp" == Komponenten kommer igång men måste först stabiliseras innan den kan ingå i en "produktionsgrupp". Vissa komponenter kan vara kinka om strömmen inte korrekt och ren vid start, oftast då vid en kallstart, eftersom allt strömmen rusar som mest vid kallstart.

Min laptop som detta skrivs på laddas via USB-C kontakt. Visst, jag har själv inte använt större tegelstenar än 180 watt till laptop. Men framtiden utvecklas.

Jag säger inte emot dig gällande fördelen med att ha en sladd som täcker många behov.

Det jag är emot är att det skall på union-nivå lagstiftas om en sådan grej. Jag är för konsumentens eget val eftersom det styr marknaden och hjälper dessutom till att driva marknaden när det är fritt att komma på nya idéer som konsumenterna kan ta del av.

Föreställ dig när där i framtiden kommer en bättre lösning än USB-C. Skall den bättre lösningen bannlysas inom EU?

Det är det som är grejen, varför måste man ha en enda standard? Varför inte låta folk själv välja bland olika standardiserade format? Jag menar, skall någon snart bestämma att min dator får inte lov att dra mer än 240 watt p.g.a. kontakten?

Jag kan vara helt off eftersom hakarna matchar inte det som är på din bild. Har en 478 hemma men den är ifrån HP(en xw5000) och där är det klassiska med fyra skruvhål.

Där ser det ut så här:

https://i.ebayimg.com/images/g/PYIAAOSwZUJh5d60/s-l1600.jpg

Mitt tips är att ta reda på exakt modell som ditt moderkort är och kolla på Google via bilder.

Jepp, inte den klassiska "vanliga". Verkar låsas fast med "hake" mekanism i gröna respektive svarta fattningarna till vänster respektive höger.

Notis vid sidan om: Om Du skall fortsätta med detta moderkort så kanske Du får byta ut ett antal utav elektrolytkondensatorerna som syns på bild då dom har jäst.

EDIT:
Misstänker att det är något i denna stil:

https://i.ebayimg.com/images/g/3ysAAOSwRsZZ1L3C/s-l500.jpg

Standarder är bra men jag tycker inte att det är unionsfråga att bestämma vilken typ av laddningsport en telefon skall ha. Låt köparna(läs marknaden) själv bestämma över detta genom konsumentens val utav produkter vilket i sin tur styr marknaden.

Vad blir nästa grej, skall EU bestämma vilken maxeffekt min dator får lov att ha innan den klassas som olaglig?

Knepigt. Blinkar Caps Locks, Num Lock och Scroll Lock till på tangentbordet vid den första uppstarten?

För rent krasst så låter det som att en pryl inte initierar sig korrekt vid kallstart men har sedan inte problem vid en varmstart. Spontant så kan prylar hänga sig när dom får elektrisk energi där energin är för lite, för mycket eller smutsig. Eller så kan en komponent lägga av vilket kräver att den "värms upp" ett kort ögonblick och därefter kommer igång vid en varmstart.

Möjlighet att prova med en annan nätdel?

Prova att nollställa BIOS till fabriksinställningar(skriv först ner dagens inställningar om dom är förändrade) och sedan prova på nytt?

Kasst CR2032 batteri?

Helt rätt. Den gör exakt samma sak.

Nu är jag klar med labbandet.
adb pull /dev/block/dm-0 ./dekrypterad-data.img fungerade för mig. Blev en fil på 23.5 GiB i mitt fall.

Inga konstigheter att kika i den med Linux Reader.

Inga konstigheter heller att hitta min raderade fil i din med hjälp av HxD. Det var en textfil med loggar fram till idag(kollade innan i den innan jag raderade den). Dock så hittade jag bara ett fragment utav filen och det var det som precis var nästan i början utav filen.

Alltså har den Android jag kör tydligen en förmåga att skriva saker relativt fort till filsystemet efter det enda jag gjorde efter att ha raderat filen var att stänga av telefonen och starta TWRP i recovery läge.

Det känns som att Du behöver utreda varför det i ditt fall inte skapas en blockenhet som är den okrypterade versionen, trots att Du kan se dina nuvarande filer i TWRP.

I annat fall så får Du dra hem blockenheten i krypterat läge som Du redan har gjort, och hitta en programvara som körs på en PC som begriper sig på krypteringsformatet. Kanske köra TWRP i en Android x86 VM. Men känns som att det borde inte gå bättre där än på den riktiga fysiska Android enheten.

Jag hade satsat på det första alternativet eftersom om TWRP klarar av att läsa den efter att Du slagit in lösenordet är det betydligt enklare att hitta var den monterar den okrypterade varianten än att prova den sistnämnda varianten.

Då har jag provat lite men blev inte helt färdig då det börjar bli morgon och strax dags att sticka ut och telefonen kan då inte vara recovery läge.

Jag behöver inte ens ange adb shell twrp decrypt ditt-lösen-ord. Blockenheten dm-0 skapas direkt efter att TWRP uppmanat mig att ange lösenordet för /data för jag startar telefonen i recovery läge.

Sedan så fungerar naturligtvis adb pull /dev/block/dm-0 ./dekrypterad-data.img men jag var tvungen att avbryta vid 12 GiB p.g.a. tidsbrist. När jag gick in i den delvis nerladdade img fil med HxD så ser jag mitt eget programs inställningar som ligger i en liten databas fil.

Skall titta på det närmare på kvällen/imorgon, men problemet verkar vara att Du inte får dm blockenheten i TWRP, och då förstår jag inte heller hur Du kan se innehållet i /data eftersom den borde inte finnas eftersom TWRP borde inte ha montera sökvägen /data mot blockenheten dm-x.

Kommer då även att prova skapa en fil med lite unik data, radera filen, dra hem dm-0 och söka i den med HxD om innehållet i filen och filnamnet fortfarande finns kvar i filsystemet.

Låter som om det dessvärre stämmer .

Skall ändå klona mina telefoner denna vecka så skall efter kloningen testa detta specifikt på CAT S60 telefonen då den har kryptering som TWRP begriper sig på.

Återkommer.

Har Du en lysdiod på CapsLock knappen?
Om ja, tänds/släcks den när Du trycker på knappen?

Länk är det inte i mitt fall utan en äkta monteringspunkt som kör filsystemet ext4 med tanke på vad som syns ifrån mount. En monteringspunkt ger tillgång till hela det underliggande filsystemet, inklusive alla sektorer/block som finns där, d.v.s. om där finns "raderade" filer där så finns dom tillgängliga via monteringspunkten.

Enligt min mount så härstammar både /sdcard och /data ifrån /dev/block/sda18, d.v.s. dom är identiska. Troligtvis för bakåtkompatibilitet.

Man hade behövt se din mount för att ge dig ett specifikt tips, för i mitt fall så ser jag det som att:

adb pull /sdcard ./dekrypterad-data.img

hade gett mig en avbild utav den okrypterade varianten utav partitionen.

Och där i så finns även "raderad" data. Sedan hade man kunnat leka fritt med det hela i verktyg avsedda för syftet på en PC.

Den fråga man ställer sig är: varför kan dom inte ha funktionerna lokalt istället? Varför måste den upp till molnet för att få tillgång till alla funktioner?

Jag skulle t.ex. inte acceptera att ha en bil som måste ha uppkoppling till molnet för att få tillgång till alla funktioner. Eller en drönare som måste vara uppkopplad till molnet för att få tillgång till alla funktioner.