Eller NVRAM som det är i detta fallet.
Jag har länge försökt lista ut ett sätt att knäcka koden i Pioneers bilstereo DEX-77. För att vara så till åren är den ändå avancerad. Koden går att ändra, så att räkna ut den medelst serienummer och annat är bara att glömma. Den sparas inte i klartext i kodminnet (Xicor X24C44, Pioneer-brandad till PDH001), man har bara tre försök på sig innan stereon låser sig i tre timmar innan man får försöka igen.
I minnet sparar den antalet försök, och när den är låst måste man ha den avstängd men spänningssatt på minnesmatningen för att den ska återställa sig.
Min tanke var att bruteforca genom att kontinuerligt mata in 0000, på ett sätt eller annat, därefter öka innehållet i minnet med ett och mata in igen. När koden accepteras borde det inte resultera i en skrivning till minnet, alternativt en nollställning av byten som räknar antalet försök. Så jag tänkte trigga ett stopp på att man inte får en skrivning till felbyten som svar.
Har jag tänkt någorlunda rätt? Andra förslag på metod?
Eeprom-emulator
Re: Eeprom-emulator
sparas antal försök i eepmromet? Isf borde det väl räcka att blockera skrivningar till minnet och köra en bruteforce med poweroff mellan varje.
Re: Eeprom-emulator
Vad sitter den i för någon bil?
Eller rättare sagt, har den varit orginalmonterad i någon bil?
Eller rättare sagt, har den varit orginalmonterad i någon bil?
Re: Eeprom-emulator
mrfrenzy's idé verkar vettig. Fast huruvida det verkligen är enklare att blockera skrivning jämfört med att emulera hela eeprom'et låter jag vara osagt.
Det kanske eller kanske inte går att skrivskydda genom att mata eeprom'et med en egen spänningsmatning som har extremt klen strömgräns, och kanske övervaka datapinnen genom att leda den signalen genom lågohmigt motstånd och detektera när eeprom'et försöker skicka ut en positiv flank och då 'erbjuda' högre strömgräns på matningen eller nåt.
Med tre timmars blockering per tre försök så tar det ju å andra sidan bara ett år och 52 dagar att prova alla kombinationer om det är 000-9999
Halvofta är det väl 1111-6666 eller liknande och då blir det färre kombinationer, såpass få (1296) att man faktiskt skulle kunna emulera tangenttryckningar med en pålödd 4066 och antingen avlyssna displaydrivningen eller köra kamera + "OCR" för att se ifall koden funkat. Man kan ju också bara göra en krets som drygt var tredje timme provar tre koder och så får man titta till manuellt då och då för att se ifall den blivit upplåst, man vet ju att koden var någon av de som provats sen man tittade sist. Ett mellanting är väl ett bygge som bara provar koder och sparar ner bilder utan att tolka bilderna.
Annars kan du väl bygga nån enkel muxkrets som väljer om extern dator eller bilstereon ska få prata med eeprom'et, så att du direkt kan skriva in nytt innehåll efter varje försök.
Det kanske eller kanske inte går att skrivskydda genom att mata eeprom'et med en egen spänningsmatning som har extremt klen strömgräns, och kanske övervaka datapinnen genom att leda den signalen genom lågohmigt motstånd och detektera när eeprom'et försöker skicka ut en positiv flank och då 'erbjuda' högre strömgräns på matningen eller nåt.
Med tre timmars blockering per tre försök så tar det ju å andra sidan bara ett år och 52 dagar att prova alla kombinationer om det är 000-9999

Halvofta är det väl 1111-6666 eller liknande och då blir det färre kombinationer, såpass få (1296) att man faktiskt skulle kunna emulera tangenttryckningar med en pålödd 4066 och antingen avlyssna displaydrivningen eller köra kamera + "OCR" för att se ifall koden funkat. Man kan ju också bara göra en krets som drygt var tredje timme provar tre koder och så får man titta till manuellt då och då för att se ifall den blivit upplåst, man vet ju att koden var någon av de som provats sen man tittade sist. Ett mellanting är väl ett bygge som bara provar koder och sparar ner bilder utan att tolka bilderna.
Annars kan du väl bygga nån enkel muxkrets som väljer om extern dator eller bilstereon ska få prata med eeprom'et, så att du direkt kan skriva in nytt innehåll efter varje försök.
Re: Eeprom-emulator
Jag har låst upp en bilstereo på det vis ni beskriver en gång på sent 80tal. Fick en av våra programmerare på jobbet att skriva ett program till vår PLC som stegade upp koden 3 gånger för att sedan vänta 3 timmar.
Lödde in sladdar på knappsatsen och sedan var det bara att vänta.Tog några veckor
Kommer ihåg att kompisen som ägde stereon vaknade av att något mystiskt ljud i sovrummet , den försökte vända bandriktningen.
Lödde in sladdar på knappsatsen och sedan var det bara att vänta.Tog några veckor
Kommer ihåg att kompisen som ägde stereon vaknade av att något mystiskt ljud i sovrummet , den försökte vända bandriktningen.
Re: Eeprom-emulator
Tror nog att det blir svårare att ändra vilken kod som matas in mellan varje försök än att ändra i minnet.mrfrenzy skrev:sparas antal försök i eepmromet? Isf borde det väl räcka att blockera skrivningar till minnet och köra en bruteforce med poweroff mellan varje.
Spelar ingen roll. Koden går att ändra som jag skrev.TomasL skrev:Vad sitter den i för någon bil?
Eller rättare sagt, har den varit orginalmonterad i någon bil?
MiaM: Det finns ju faktiskt en pin på minnet som synkar sram-delen med eeprom-delen. Om man kopplar bort denna och kör poweroff mellan varje tre försök borde minnet förbli intakt. Då borde man kunna mata in kod efter kod. Dock kan man även initiera denna skrivning med kommando i mjukvara, det är frågan vilken metod denna maskin använder.
BMI: Skoj

Edit: Konstaterade att det inte räcker att koppla bort /store.