samdunk - theroot.ninjatheroot.ninja/disclosures/samdunk_1.0-03262016.pdf · samdunk sunday, march...

Post on 04-May-2018

225 Views

Category:

Documents

2 Downloads

Preview:

Click to see full reader

TRANSCRIPT

SamDunk

Sunday,March27,2016 1

eMMCbackdoorleadingtobootloaderunlockonSamsungGalaxyDevicesDiscoveredanddocumentedbySeanBeaupre(beaups)

AffectedproductsThisvulnerabilityaffectscertainbootloader-lockedQualcommbasedSamsungGalaxyproductscontainingSamsungeMMC.TestedandconfirmedtounlockthebootloaderoftheVerizonSamsungGalaxyS5.WhilepossiblyeverydevicecontainingaSamsungeMMCcontrollerisvulnerabletotheattackdescribedbelow,it’susefulnessasabootloaderunlockislikelylimitedtoselectSamsungGalaxydevices.

Samsung’sunlockmechanismManufacturersemployawidevarietyofmethodsandmechanismstodetermineandcontroladevice’sbootloaderlockstatus.MotorolausesTrustZoneprotectedfuses,HTCusesdatainawriteprotectedregionofeMMC,andsomeLGdevicesuseasignedblobintheboot(kernel)partition.Therearelikelymanyothermethods,buttheconceptisthesame:onlyallowtheunlockstatustobechangedviaacontrolledanddeliberatemethod.Additionally,whenunlockingthebootloaderofmostdevices,theuser’sdatapartitioniswipedtoensurethattheunlockwasn’tperformedinattempttomaliciouslygainaccesstoauser’sdata.Insomecases,likemostdevicesbuiltforuseontheVerizonnetwork,theabilityforausertounlockthebootloaderisblockedentirely.OnesuchdevicewastheGalaxyS5usedforthisresearch.TheGalaxyS5(andprobablysome/manyotherGalaxydevices)usesauniquemechanismfordeterminingadevice’sunlock/devstatus.AsResearchedanddiscoveredby@ryanbg(http://forum.xda-developers.com/member.php?u=766721):

Ablob in theabootpartition image is readanddecrypted. Then, thedevice’seMMCCIDishashedandcomparedtothevalueofthedecryptedblob.Iftheymatch,thedeviceisconsideredunlocked.

Basically,atsomepointinthemanufacturingprocess,whenadeviceisconfiguredtobea“dev-edition”device,Samsunghashesthedevice’seMMCCID,padsit,signs(orencrypts?)itwiththeirprivatekey,andplacesthatsigneddatainthedevice’sabootpartition.Ateveryboot,abootisabletoverifythatthedeviceisactuallyadev-editiondevice.WhatisaneMMCCID?AccordingtoeMMCdocumentation:

“The Device IDentification (CID) register is 128 bits wide. It contains the Device identification information used during the Device identification phase (e•MMC protocol). Every individual flash or I/O Device shall have an unique identification number. Every type of

SamDunk

Sunday,March27,2016 2

e•MMC Device shall have a unique identification number.”

Great!WecansimplychangetheeMMCCIDtomatchonefromafactorydev-editiondevice,andthenflashtheabootpartition(containingthehashedandsignedCIDblob)fromthesamedev-editiondevice.Except,elsewhereintheeMMCdocumentation:

“Programming of the Device identification register. This command shall be issued only once. The Device contains hardware to prevent this operation after the first programming. Normally this command is reserved for the manufacturer.”

Effectively, the CID is a serial number programmed at the factory and, according to the eMMC standard, is only programmable once. What “hardware” prevents the CID from being reprogrammed? Is it really stored in some OTP region? The fact that an eMMC contains mass amounts of non-volatile reprogrammable NAND memory should make any researcher skeptical that it is truly “write-once”.

EntervendorcommandsGenerallyspeaking,vendorcommandsarecommands/codes/instructionsthatdon’tappearinanyofficialstandardsandallowahost/user/factory/softwaretointeractwithadeviceinanon-standardway.SpecificallyforSamsungeMMC,aspecial(mostly)undocumentedCMD62inconjunctionwithsome“secret”argumentsareused.SomeofSamsung’svendorcommandswerepubliclyreleasedbySamsungduetoasoftwaredefectintheireMMCcontrollerfirmware.Samsungneededthelinux/androidkerneltobeabletopatchtheeMMCfirmwareinrealtime,andthushadtoreleaseanddocumentsomeoftheirproprietaryeMMCvendorcommands:https://android.googlesource.com/kernel/omap/+/3c57a612f12b069bbc863ec0c74a26850d76a9e8%5E!Samsungprovidedacriticalfunctionforenablingfurtherresearch:mmc_movi_read_cmd.Withasimpleloopofthisfunction,weareabletodumptheentirerunningfirmwareandramoftheeMMCcontroller.

SamDunk

Sunday,March27,2016 3

FindingsomethingusefulThefirststepwastofindwhatfunctioninSamsung’sfirmwarehandledahost’sPROGRAM_CIDrequest.Aquick(andquitelucky,asmosteMMCcommandsuseafunctionpointertable)searchfortheimmediatevalue26(eMMCcommand26isPROGRAM_CID)revealsthis:

SamDunk

Sunday,March27,2016 4

Somebasicsetupisdone,thentheopcodeischeckedtodecidewhetherornotthehostistryingtoprogramtheCSDregisterortheCIDregister.SincewearetryingtoreprogramtheCIDregister,let’slookattheprogram_cidfunctioncalledwhenR0=0x1A(26):

SamDunk

Sunday,March27,2016 5

Thefunctionread_security_registerisimportantandverysimple:

Itsimplyreadsavaluefromram,storesitinthecaller’spointer,andreturns.Backtotheprogram_cidfunction:

SamDunk

Sunday,March27,2016 6

Thesecurityregisterisreadandbit0istested.Ifbit0isclear,abranchistakentoloc_4AC84,andultimatelytheCIDprogrammingfails.Ifbit0==1,thefunctioncontinues:

1.) Bit0iscleared,andthesecurityregisterisupdatedwiththenewvalue2.) TheCIDisprogrammed

Surelythis“security_register”can’tbethe“hardware to prevent this operation after the first programming” as described in the eMMC spcifications; it is simply a dword in the controller’s RAM. How can we get bit 0 set in the security_register? A quick refs search to write_security_register answers this question quickly:

vendor_security_functions()isarealmess:

SamDunk

Sunday,March27,2016 7

Weneedtofindacalltowrite_security_registerwithavalueof1,toallowustoreprogramtheCID.Zoomingin:

Bingo:

Youcanseeveryclearly,thesecurityregisterisread,bit0isset,andthesecurityregisterisupdated,enablingprogrammingoftheCID.Workingbackwardsthroughthe~100argumentcalculationsinthevendorcommandhandler,I’llsimplystatethattheargvaluethatneedstobepassedwiththeCMD62is0xEF50.Issuingthevendorcommandwithargument0xEFAC62ECfollowedbythevendorcommandwithargument0xEF50isSamsung’sbackdoortoallowreprogrammingoftheeMMCCID.

SamDunk

Sunday,March27,2016 8

DoingthedeedI’vepushedcodetogithubtochangetheCIDinSamsungeMMCusingthebackdoordescribedabove:https://github.com/beaups/SamsungCIDCaveats(important):

1.) ItisgenerallyabadideatodomuchwithSamsungvendorcodesfromuserspace,asyoucannottakealockontheeMMC.Theprogram_cidbackdoorappearstobequitesafe,butdoNOTtrytoupdatethecodetodooperationssuchasreading/writingcontrollermemory.You’llwanttodothatwithakernelmodule.You’vebeenwarned.

2.) Whilethecodewillchangethedevice’sCID,youwillneedtocheck(afterreboot)toseethattheCIDchanged“perfectly”.Insomeinstances,afewbitsarekeptfromtheoriginalCID.Ifthathappens,youwillneedtowriteakernelmodule,dumpthecontrollermemory,findthecurrentCIDinthecontroller’smemory,patchitto0,andprogramtheCIDagain.

3.) IhavenotresearchedwhatelseSamsung/Android/bootloaders/apps/etc.mightusethedevice’sCIDfor.ChangeyourCIDatyourownrisk.

4.) Ifyourgoalistoturnyourdeviceintoadev-editiondevice,YOUwillneedtofindthedev-editionabootimageandthecorrespondingCID.Further,youshouldonlyattempttoflashanyabootthroughODIN.IfODINrejectstheflash,you’vedonesomethingwrong.

5.) OnlyUID0haswriteaccesstommcblk0,whichisneededtoissuethenecessaryIOCTLs.

6.) DonotPM,email,call,orotherwisestalkmelookingforsupport,supportingfiles,oranythingelse.

top related