Gathering of Tweakers

Dat klopt inderdaad wel, misschien kan je het wissen van EEPROM in de uC nog wel voorkomen door de voeding van de controller zo laag mogelijk te zetten. Misschien dat de uC dan nog werkt maar niet meer de spanning op kan wekken om het geheugen te wissen, daar is vaak wel een hogere spanning voor nodig (en vast ook wel meer stroom).

Allereerst: Nice job, _ferry_!

Ik post hier niet zo heel vaak, maar heb nu iets waar ik zelf niet achter kan komen.
Ik ben bezig met een soort SMS-controller voor mijn alarmcentrale, ik gebruik een AVR in combinatie met een Ericsson T18s GSM. Heeft altijd goed gewerkt met een vorig controllerprintje, met in plaats van een accu een 7805-voeding op een klein printje. De originele accu was volgens spec 4,8V dus dat ging eigenlijk prima. Nu wilde ik hem vanuit mijn AVR-bordje gaan voeden en heb de accu-aansluitingen van de GSM rechtstreeks verbonden met het bordje. In de GSM nog een klein elkootje en een 100nF capje over de voedingslijnen geplaatst voor wat extra stabiliteit.

Vervolgens leek het me handig als de GSM automatisch inschakelde zodra er spanning op kwam.
Hier had ik een mede-hobbyist gevonden die iets soortgelijks met een T10s deed; alleen de "NO" toets doorverbinden via een schakelaar was voldoende. Werkte bij de T18s ook! Ik ben gaan meten en vond twee via's op de PCB welke naar de "NO"-toets gingen. Daar heb ik een stukje roadrunner-draad aan geknoopt en naar de achterkant van de telefoon gebracht om in het batterijvak de schakelaar te kunnen plaatsen. So far so good, dacht ik.

De ene kant van de schakelaar gaat waarschijnlijk naar een controller op de print, de andere kant verbond rechtstreeks door met V+ van de batterij. Op zich vreemd, maar ik had het gedubbelcheckt. Voor de zekerheid heb ik er een 100 ohm weerstandje tussen geknoopt, de folietoets had een ohmse weerstand van 50 - 60 ohm.

Maar ergens is hier dus iets mis gegaan. Zelf vermoed ik nog het meest dat die schakelaar niet naar Vbatt schakelt, maar naar een andere, interne Vcc. Gevolg is dat de telefoon dus gedeeltelijk de geest heeft gegeven. Hij schakelt nog in, gaat zoeken naar netwerk, en vlak nadat de streepjes bij de ontvangst-indicator opkomen, schakelt het toestel zichzelf helemaal uit. Zonder SIM start hij op en blijft netjes de melding "SIM plaatsen" oid geven. Hij valt dan ook niet uit.


Kortom: Er is iets gesloopt in de voeding van deze T18s. Met lage belasting gaat alles prima, maar zodra er meer vermogen gevraagd lijkt te worden (daadwerkelijk zenden na het vinden van mijn provider waarschijnlijk?) valt het toestel uit. Het kan natuurlijk ook zo zijn dat de/een eindtrap van de zender om zeep gegaan is waardoor de voeding wordt kortgesloten. De kans is dus groot dat de spanningsregelaar of een eindtrap van de T18s om zeep is. Heeft iemand die ooit al eens vervangen of weet iemand waar 'ie precies zit? Ik weet niet waar ik 'm zou moeten vinden op het printje! Is 'ie uberhaupt los of zit 'ie geïntegreerd in één van de vele "ericsson" branded IC's?

_{Ik vermoed dat deze reparatie-actie bij voorbaat al vrij kansloos gaat zijn. Heb al een V&A geplaatst voor een ander toestel, maar daar loopt het nog niet echt storm...}

Wie kan mij vertellen wat voor dimmer ik nodig heb voor een rail met halogeen lampjes, met een gewone ringkerntrafo? (geen elektronische dus!) ?

De bouwmarkt biedt deze dimmers aan:

• Conventionele dimmer voor gloeilampen
• Halogeendimmer (deze zou niet geschikt zijn voor gewikkelde trafo's )
• Elektronische dimmer

quote:

madwizard schreef op maandag 10 maart 2008 @ 20:39:
Dat klopt inderdaad wel, misschien kan je het wissen van EEPROM in de uC nog wel voorkomen door de voeding van de controller zo laag mogelijk te zetten. Misschien dat de uC dan nog werkt maar niet meer de spanning op kan wekken om het geheugen te wissen, daar is vaak wel een hogere spanning voor nodig (en vast ook wel meer stroom).

Kwestie van eerst kijken of je sleutel weg is, zoniet extra bit schrijven en dan pas laten weten dat het fout was. Volgens mij zou dat moeten werken:
1:Men voert foute pincode in:
1.1: Voeding is goed en sleutel word weggegooid (indien het de 3e keer is anders word teller-1 gedaan)
1.2: Voeding is niet voldoende en een extra bit word geschreven (schrijven kost volgens mij minder stroom) Bij de volgende boot wordt de fout-bit gevonden en de uC stopt met verwerken van code.

Is het zo waterdicht? Op dit moment begin ik te twijfelen. Sowieso zou je een ARM kunnen pakken met interne power regulator: AT91SAM7L128 bijv. in de datasheet staat wel een melding dat flash niet meer werkt onder 1.55V maar je kunt de voltage regulator zo proggen dat ie of 1.65V+ geeft of niks.

quote:

madwizard schreef op maandag 10 maart 2008 @ 20:39:
Dat klopt inderdaad wel, misschien kan je het wissen van EEPROM in de uC nog wel voorkomen door de voeding van de controller zo laag mogelijk te zetten. Misschien dat de uC dan nog werkt maar niet meer de spanning op kan wekken om het geheugen te wissen, daar is vaak wel een hogere spanning voor nodig (en vast ook wel meer stroom).

Je kan toch ook gewoon in je flash schrijven?

Ik denk eigenlijk dat je nooit tot een hooge beveiliging kan komen met een micro. Omdat er altijd een mogelijkheid is om de lock fuses te omzeilen en zo de source er van af te halen. Daar kan je dan weer de sleutel uit halen.

Je zou een soort challenge voor de host moeten maken met een heleboel verschillende mogelijkheden van verschuiven and or-en wat je allemaal wel niet kan verzinnen. En hierna pas de data (die ge-encrypt in het geheugen staat uiteraard) kan lezen.

HammerT wijzigde dit bericht 10-03-2008 21:29 (4%)

quote:

HammerT schreef op maandag 10 maart 2008 @ 21:27:
[...]

Je kan toch ook gewoon in je flash schrijven?

Ik denk eigenlijk dat je nooit tot een hooge beveiliging kan komen met een micro. Omdat er altijd een mogelijkheid is om de lock fuses te omzeilen en zo de source er van af te halen. Daar kan je dan weer de sleutel uit halen.

Je zou een soort challenge voor de host moeten maken met een heleboel verschillende mogelijkheden van verschuiven and or-en wat je allemaal wel niet kan verzinnen. En hierna pas de data (die ge-encrypt in het geheugen staat uiteraard) kan lezen.

edit:
en brown uit fuses kan je ook gebruiken, maar ik weet niet of die zo betrouwbaar zijn

Madwizard heeft wel deels gelijk:
Onder 1.55V is flash niet meer beschrijfbaar (en wisbaar) maar werkt de Core nog wel: Je zou met een brownout detector kunnen resetten maar dan heb je nog steeds 1 poging (behalve dus als je bij het intoetsen van de laatste toets eerst een bit wegschrijft en dan pas kijkt of of de code goed is: is ie goed wis je die bit, is ie fout wis je de sleutel of zet je de pogingen over eentje minder, kan dat niet staat die bit er ook nog en boot je stick niet meer) Daarnaast was mijn streven om de USB-stick software vrij te maken zodat hij op elke pc zou werken...

EEPROM uitlezen van een µC is idd mogelijk,gooi de µC in zuur zodat de behuizing weggevreten wordt, stop em onder de microscoop, en prik met minieme naaldjes in het EEPROM gedeelte om em uit te lezen (bijvoorbeeld tijdens het inschakelen van de stick, dan moet ie op een bepaald moment de code uitlezen om te vergelijken).
Een gespecialiseerd lab doet het voor je in een paar uurtjes, voor enige duizenden €.

quote:

timcooijmans schreef op maandag 10 maart 2008 @ 21:34:
[...]

Madwizard heeft wel deels gelijk:
Onder 1.55V is flash niet meer beschrijfbaar (en wisbaar) maar werkt de Core nog wel: Je zou met een brownout detector kunnen resetten maar dan heb je nog steeds 1 poging (behalve dus als je bij het intoetsen van de laatste toets eerst een bit wegschrijft en dan pas kijkt of of de code goed is: is ie goed wis je die bit, is ie fout wis je de sleutel of zet je de pogingen over eentje minder, kan dat niet staat die bit er ook nog en boot je stick niet meer) Daarnaast was mijn streven om de USB-stick software vrij te maken zodat hij op elke pc zou werken...

Dat is niet zo'n probleem, dan gebruik je gewoon meerdere partities. Eentje met het tooltje er op. Hoewel je dan weer met mac linux windows compatibiliteit zit

Zowiezo denk ik dat het een goed idee is om je data steeds op een andere locatie te schrijven.

Maar waarom zou je je retry count niet gewoon encrypted in je geheugen kunnen plaatsen? Je zou voorhand kunnen controleren of write protection oid aan staat.

Tim_bots begint ook eens hardop mee te denken aan de "uber secure" USB-pen.

Op zich ben je met een geheugenkaart (SD) en een snelle controller + USB (of tragere met crypto functies) al een heel eind. Maar volgens mij is het niet direct noodzakelijk om de key ergens op te slaan. In theorie is het al voldoende om een string te pakken en die te XOR-en met de data (of optellen). Omdat er truken zijn om dit soort encryptie te omzeilen is dit natuurlijk niet de meest handige manier. (vind een bestand waarvan je de inhoud kent en daar vliegt je beveiliging).

Misschien is het beter om leentje-buur te gaan spelen bij projecten die zichzelf al bewezen hebben (en gedeeltelijk hetzelfde probleem hebben(*)). HET voorbeeld hiervan is TrueCrypt. Wat moet er dus in de elektronica gebeuren: de software moet dezelfde functies bevatten als TrueCrypt en in plaats van wegschrijven naar een bestand naar de SD-kaart. Is er alleen nog een stukje software nodig op de PC (simpele EXE (voor windows dan)) wat het wachtwoord naar de controller stuurt en vervolgens beëindigd. Daarna bepaalt de software op de controller (truecrypt) of het wachtwoord enz... klopt.

Het voordeel is dat je niets op je PC hoeft te installeren maar toch secure aan de gang kunt gaan en je kunt ook alle andere truecrypt functies gebruiken (2 wachtwoorden voor verschillende data in 1 file).

(*) Als je de truecrupt container hebt gevonden is het natuurlijk een eitje om een kopie van de file te maken en wat truecrypt dat ook weggooit/aanpast je kan het volledig herstellen want je hebt een kopie.

quote:

HammerT schreef op maandag 10 maart 2008 @ 21:42:
[...]

Dat is niet zo'n probleem, dan gebruik je gewoon meerdere partities. Eentje met het tooltje er op. Hoewel je dan weer met mac linux windows compatibiliteit zit

Zowiezo denk ik dat het een goed idee is om je data steeds op een andere locatie te schrijven.

Maar waarom zou je je retry count niet gewoon encrypted in je geheugen kunnen plaatsen? Je zou voorhand kunnen controleren of write protection oid aan staat.

Je pakt een usb stick, leest het flash uit, toetst code fout in en zie daar een verandering in je flash. Met een geheugen controller kopieer je het oude image weer terug en je kunt nog een keer proberen! Volgens mij kost dit minder moeite dan het openhalen van een behuizing en het daaruit proben van de data.

Met genoeg geld en middelen zal je een microcontroller (of elke soort hardware) wel in een bepaalde staat kunnen 'backuppen' en 'restoren'. Heb op internet ook wel eens iemand gezien die door een bedrijf de bovenkant van een PIC met anti-uitlees fuses ingesteld eraf had laten halen, en vervolgens met UV licht onder een bepaalde hoek de fuses gereset kreeg en de code uit kon lezen (zij het niet helemaal intact). En dat is dan nog een 'amateur'. Dus beveiligingen die uitgaan van pogingen registreren, of geheimhouden van data zullen meestal wel gekraakt kunnen worden.

Zoals tim_bots noemt kun je zoiets doen als truecrypt, die weet de goede key zelf ook niet maar checkt deze door een stuk data te decrypten met een gegeven wachtwoord en de uitkomst te controleren op geldige data (winrar doet ook zoiets volgens mij, daar merk je bij uitpakken pas aan een CRC error dat het wachtwoord niet goed was). Aangenomen dat de encryptie goed is kun je zoiets alleen met brute force proberen te kraken.

Maar alles staat en valt natuurlijk bij het wachtwoord/pincode. Er vanuit gaande dat je altijd de encryptiemethode wel kunt achterhalen en alle data (firmware, flash, EEPROM, NAND flash) op een PC kunt krijgen is de makkelijkste aanpak het wachtwoord brute forcen. Meestal wordt daar dan een key van gegenereerd/gedecodeerd die als decryptiekey gebruikt wordt, maar die is een stuk groter dan het wachtwoord. Een pincode met alleen cijfers stelt cryptografisch natuurlijk weinig voor. Een wachtwoord (a-z, A-Z, 0-9) heeft al zoveel meer combinaties bij gelijk aantal karakters.

Hoewel we volgens mij op het moment over-the-top aan het gaan zijn:
Je hebt het nu over brute-forcen, maar als je maar 3 pogingen hebt is er niks te brute forcen...

We hebben nu 2 optie's:
-Vertouwen op het "uitschakelen" van hardware bij 3 foutieve pogingen
-Het gebruiken van een onbekende sleutel, software checkt of hij de goede sleutel heeft gekregen door CRC. Gebruiker voert de sleutel van lange lengte (anders is het namelijk te brute forcen) in.

timcooijmans wijzigde dit bericht 10-03-2008 22:12 (47%)

quote:

timcooijmans schreef op maandag 10 maart 2008 @ 22:07:
Je hebt het nu over brute-forcen, maar als je maar 3 pogingen hebt is er niks te brute forcen...

Niet als je alle relevante data uit het systeem weet te halen (hoe dan ook) en op een PC alles simuleert. Die drie pogingen check valt altijd wel te omzeilen, hoe dan ook is het cryptografisch gezien handig daar vanuit te gaan.

quote:

ThinkPad schreef op maandag 10 maart 2008 @ 21:19:
Wie kan mij vertellen wat voor dimmer ik nodig heb voor een rail met halogeen lampjes, met een gewone ringkerntrafo? (geen elektronische dus!) ?

De bouwmarkt biedt deze dimmers aan:

• Conventionele dimmer voor gloeilampen
• Halogeendimmer (deze zou niet geschikt zijn voor gewikkelde trafo's )
• Elektronische dimmer

Ik heb een Praxis Halo halogeen dimmer en volgens de verpakking kan deze 230V en 12V (conventionele trafo) halogeen dimmen.

quote:

madwizard schreef op maandag 10 maart 2008 @ 22:11:
[...]

Niet als je alle relevante data uit het systeem weet te halen (hoe dan ook) en op een PC alles simuleert. Die drie pogingen check valt altijd wel te omzeilen, hoe dan ook is het cryptografisch gezien handig daar vanuit te gaan.

Leuk dat je het aanhaalt, want dat zou namelijk betekenen dat je dmv. een Rabobank randomreader en een bankpasje, de pincode van het desbetreffende bankpasje kan achterhalen.

quote:

timcooijmans schreef op maandag 10 maart 2008 @ 22:17:
Leuk dat je het aanhaalt, want dat zou namelijk betekenen dat je dmv. een Rabobank randomreader en een bankpasje, de pincode van het desbetreffende bankpasje kan achterhalen.

Ik weet niet hoe dat ding werkt, het werkt wel losstaand toch zonder verbinding met internet ofzo? Wel een interessant apparaat ook. Maar ik vermoed dat daar wel over nagedacht is. Het zou bijvoorbeeld kunnen dat meerdere pincodes hetzelfde resultaat geven, je krijgt toch een soort transactie code op basis van je pincode?

quote:

madwizard schreef op maandag 10 maart 2008 @ 22:25:
[...]

Ik weet niet hoe dat ding werkt, het werkt wel losstaand toch zonder verbinding met internet ofzo? Wel een interessant apparaat ook. Maar ik vermoed dat daar wel over nagedacht is. Het zou bijvoorbeeld kunnen dat meerdere pincodes hetzelfde resultaat geven, je krijgt toch een soort transactie code op basis van je pincode?

Het apparaat is inderdaad losstaand, en geeft een transactie code op basis van je pincode máár geeft zelf (dwz. op het apparaat zelf) aan dat de pincode fout is. Dus het dingetje heeft zelf het algoritme om te checken of een pincode juist is of niet...

Zie nu ergens dat de chip op de pas ook gebruikt wordt, dat is weer wat anders dan dat de kaart alleen gelezen wordt met magneetstrip.

Uit een oud topic:

quote:

fsfikke schreef op donderdag 02 augustus 2007 @ 02:41:Ook onthoudt de kaart zelf hoeveel pogingen je nog hebt. Als je te vaak fout zit blokkeert de chip. Je kan dan dus niet meer online inloggen of Chipknippen. PIN automaten werken met de magneetstreep en hebben dus niets met de chip te maken. Betalen met een geblokkeerde chipknip kan dus nog wel.

Neemt niet weg dat de chip op de pas dus blijkbaar je pincode kan controleren, je kan daar natuurlijk ook dezelfde trucs op gaan toepassen.

quote:

madwizard schreef op maandag 10 maart 2008 @ 22:31:
Zie nu ergens dat de chip op de pas ook gebruikt wordt, dat is weer wat anders dan dat de kaart alleen gelezen wordt met magneetstrip.

Uit een oud topic:

[...]


Neemt niet weg dat de chip op de pas dus blijkbaar je pincode kan controleren, je kan daar natuurlijk ook dezelfde trucs op gaan toepassen.

Het is natuurlijk helemaal intressant dat de volledige specificaties van EMVco online staan: Klik

Die random reader valt trouwens niet open te maken, voor de nieuwschierigen onder ons.
Heb eens gelezen dat er een verbinding wordt verbroken, en daardoor een chip wordt gewist.

quote:

ThinkPad schreef op maandag 10 maart 2008 @ 23:29:
Die random reader valt trouwens niet open te maken, voor de nieuwschierigen onder ons.
Heb eens gelezen dat er een verbinding wordt verbroken, en daardoor een chip wordt gewist.

Lijkt me wel anders eens leuk om de data overdracht tussen het kaartje en de random reader te bekijken. zeg maar een soort adapter op je pasje plakken en daarmee de data loggen.

quote:

ThinkPad schreef op maandag 10 maart 2008 @ 23:29:
Die random reader valt trouwens niet open te maken, voor de nieuwsgierigen onder ons.
Heb eens gelezen dat er een verbinding wordt verbroken, en daardoor een chip wordt gewist.

quote: rabobank.nl

Als uw Random Reader stuk is of de batterij is leeg, kunt u gratis een nieuw exemplaar ophalen bij uw Rabobank

Dus gewoon wachten tot die leeg is en dan open maken

quote:

HammerT schreef op dinsdag 11 maart 2008 @ 07:52:
[...]


[...]

Dus gewoon wachten tot die leeg is en dan open maken

Kun je lang wachten, heb de mijne al bijna 2 jaar zonder problemen

quote:

HammerT schreef op dinsdag 11 maart 2008 @ 07:52:
[...]


[...]

Dus gewoon wachten tot die leeg is en dan open maken

Gaat niet lukken, zo'n randomreader wist zijn geheugen als ie bijna leeg is. Ik vermoed dat er een Maxim-IC chip in zit die ipv flash, ram met intene batterij heeft: Is de batterij op word het ram gewist. Ze hebben dan ook een laagje over het eeprom zitten wat proben tegen gaat...

quote:

ThinkPad schreef op maandag 10 maart 2008 @ 23:29:
Die random reader valt trouwens niet open te maken, voor de nieuwschierigen onder ons.
Heb eens gelezen dat er een verbinding wordt verbroken, en daardoor een chip wordt gewist.

Kan wel, maar dan moet je weten via een donor random reader waar dat contactje zit. vervolgens neem je er nog 1, en ga je rond dat contactje de behuizing weg dremelen, en dan die contactjes met wat dun draad doorverbinden.