#S-EL3 | Explore Tumblr Posts and Blogs

shinyquagsire23 · 4 years

Text

Tying It All Together - Pwning To Own on LG phones

Last year I detailed a secure EL3 vulnerability which affected (and still affects, for devices with discontinued updates) LG Android devices. However, this vulnerability alone isn't actually all that useful for a number of reasons, the more immediate being that many phones simply do not allow writing to eMMC without root or a custom recovery. Additionally, gaining full control over all privilege levels requires draining the battery to below 0%, which while it would be possible to create a modchip that facilitated this, is impractical. To finish off my exploit chain, I would like to detail two additional vulnerabilities that I have found and utilized in my coldboot process. It's worth noting though that these vulnerabilities were reported to LG and may be patched on updated units.

Live, LAF, Love

The first exploit is an obvious necessity: In order to write the rle888 payload into the eMMC's boot graphics, I need to be able to achieve an arbitrary partition write. While exploiting Android *is* an option for this (as are hardware methods), I instead opted to attack LAF, LG's recovery/flashing component. While many Android phones in the past have used fastboot in order to flash radios and other system components to eMMC, fastboot has been completely removed on the Q710/Q720. Some phones such as the Nexus 5 actually maintain both fastboot methods and LAF, but for maximum spread, LAF is the clear target.

LAF is designed to work with LGUP, a frequently-leaked LG-internal flashing tool that allows flashing KDZ update files. While LAF in the past was able to read and write eMMC partitions without any restriction, in recent years LG has opted to sign all of their KDZ files in order to make it more difficult for things like cross-carrier flashing, version mixing/matching between partitions and other modifications to occur. Flashing is done via USB, and most of the protocol has been documented at https://github.com/Lekensteyn/lglaf.

The LAF update process largely consists of an ioctl-over-USB shim: The OPEN command is able to open a partition block device, and READ/WRTE will seek into the file and write contents. However, reading and writing are explicitly blocked until a list of partitions, their eMMC offsets, their KDZ content offsets, and their content hashes is sent via the SIGN command, all of which is hashed and signed by LG. If the contents of the partitions in the KDZ are modified, the partition list hashes will fail to verify, and modifying the hashes in the partition list will make the SIGN check fail. The private key is not stored in LGUP; KDZs are downloaded from LG's servers, signed presumably by their build servers.

So, how can we manage to activate WRTE commands, with valid partition content hashes of our arbitrary contents, if we cannot sign our own? To start, I investigated how the WRTE commands actually handled hash checking--if the partition list is sent with SIGN, then at some point the WRTE command must be able to figure out which partition the current write is for, and the current partition's contents must be buffered in RAM somewhere along with an updating SHA context, because if the SHA check fails, then it shouldn't write at all. As it turns out, most of the checks in this area were fairly solid (the write must be in the range of a partition in the list, the entire transaction is one bulk packet of the hashed size, etc). However, this led me to realize: The partition list signature is only checked once, and there is nothing stopping me from, say, sending another SIGN command.

The SIGN verification process works as follows:

The partition information is sent along with a signature in one bulk transaction.

The partition information is copied into a global .bss array from the USB buffer with a fixed size.

The partition information hash buffer is prepared: An allocation is made for N partitions and an optional string, the string being the device model (to prevent cross-flashing). The number of partitions is determined by a signed portion of the header. If the allocation fails, an error is returned.

The partition information is copied again into this allocation along with the string, and the contents are hashed. The signature is crypted with the public key and the signature hash is verified against the partition info hash. If the check fails, the global .bss array is cleared and an error is returned. If the check passes, some write threads and structs are initialized and a success value is returned.

The .bss buffer storing partition info (used by other functions) is copied to before the packet is verified

The .bss buffer is cleared when the signature mismatches, but not with this malloc fail...?

The flaw here is subtle, but not terribly difficult to notice: The number of partitions is user-controlled even though it is signed, and the partition info was copied into a global variable before verification. In all other error conditions, LAF will memset the partition information before returning an error code, however if the hashing allocation fails (ie by setting the number of partitions to -1), then the allocation will fail and an error is returned without clearing the partition information. Thus, we can fakesign our own update KDZs by

Sending a valid SIGN command, which will start the write threads

Sending a fakesigned SIGN command with the number of partitions set to -1, and all partition information set however we want. The partition information in .bss is now set without a signature being checked.

While this fakesign has the potential to hang WRTE commands while due to the number of partitions being set much larger than the global partition array, all loops when WRTE checks the partition list hashes will break once a valid partition is found. So, as long as the hash contents of the WRTE command are existent in the first few entries, it will not hang, however any writes sent that do not match will hang lafd.

Another S-EL3 vuln to wrap it all up

This might seem a bit pointless given that the former vulnerability paired with 🔋 📱❄️🥾🔓 at aboot is more than enough to unlock bootloaders, since aboot is usually the code that handles bootloader unlocking/wiping/boot image signature verification, but the downside to unlocking your bootloader is that you lose SafetyNet. To most effectively mitigate SafetyNet issues you basically need an S-EL3 exploit in order to patch Qualcomm's TrustZone to spoof a locked bootloader. While 🔋 📱❄️🥾🔓 has a vector for S-EL3 code execution via SBL1 and its charging graphic, it only triggers at extremely low battery voltages and it would be more convenient to find an alternative means to gaining S-EL3 code execution via aboot, which runs at EL2/EL1.

One of the first things I noticed when I began to look for SBL vulnerabilities, and actually the reason I looked at SBL in the first place is its crash handler. Since at least the Nexus 5, LG has shipped its "Demigod Crash Handler" which can print registers and stack information and RAM console logs from EL1 kernel, S-EL3 SBL, TrustZone, etc. I first discovered it while trying to exploit a kernel stack overflow. It also allows the user to dump memory contents over USB via its Sahara protocol which also gets used in PBL for Firehose bootstrapping.

Naturally, SBL cannot know the exact details of every execution environment it displays stack dumps for, it requires the faulting environment to store that information before warm-resetting into SBL. Consequently, this means there are portions of RAM writable by EL1 which will be later parsed at an S-EL3 execution level, and of course to make matters worse it also expects EL1 to handle the memory allocation for both the RAM console as well as for the framebuffer. These structures are also plainly visible in LG's kernel sources available in their Android OSS zips.

Above roughly shows the arbitrary write which is possible with this ramconsole parsing. The ramconsole offset is not bounds checked, so we are able to achieve an arbitrary write to a limited set of addresses based on ramconsole_offs, the limit being that the offset factors both into what you write and where you write it. However, I found that since DRAM takes up such a significant portion of the address space, it was more than enough to specifically write a function pointer to the stack. To keep the exploit as simple as possible, I chose to force console_init_maybe to return to the missing battery graphic draw routine, which then triggered 🔋 📱❄️🥾🔓 without the need to drain the battery below 1% and made loading additional payloads significantly easier.

As an interesting sidenote, this vulnerability is extremely similar to hexkyz's Wii U boot1 exploit, which also abuses warmboot behavior to take over the secondary bootloader of the Wii U's ARM boot processor. In that case, however, the Wii U encrypted its PRSH/PRST structure in RAM, and rather than displaying syslogs, it uses the structure to store boot timings and other info between IOS reboots.

For most practical usecases, this vulnerability is a bit difficult to exploit, due to SBL's text and stack differing between devices. However, S-EL3 vulnerabilities aren't all that frequently documented on Android, so I hope that it will at least be useful for anyone interested in examining Qualcomm's TrustZone components or avoiding weird SafetyNet junk.

Code for both of these exploits can be seen at https://github.com/shinyquagsire23/Q710-SIGNhax-EL3-Warmboot

#LG #SBL1 #S-EL3 #exploit #bootloader unlock #SIGNhax

4 notes · View notes

drrubinspomade · 5 years

Photo

#el3 imagery

Yes, Yes, Yes. And GREETINGS FROM LOS ANGELES.

This photo was harvested along one of our travels through the interwebs. If you like what you see, we urge you to further investigate the creator(s) and/or subject(s) of the above work and follow them, fan them, hire them.

If, on the other hand, you’d like us to remove; or you know who made this so that we can credit; holler POST HASTE.

DrRubins.com

Gracias.

1 note · View note

nuadox · 4 years

Text

Researchers improve white paints that keep buildings cool

- By UCLA -

A research team led by University of California, Los Angeles (UCLA) materials scientists has demonstrated ways to make super white paint that reflects as much as 98% of incoming heat from the sun.

The advance shows practical pathways for designing paints that, if used on rooftops and other parts of a building, could significantly reduce cooling costs, beyond what standard white ‘cool-roof’ paints can achieve.

The findings, published online in Joule, are a major and practical step towards keeping buildings cooler by passive daytime radiative cooling – a spontaneous process in which a surface reflects sunlight and radiates heat into space, cooling down to potentially sub-ambient temperatures. This can lower indoor temperatures and help cut down on air conditioner use and associated carbon dioxide emissions.

“When you wear a white T-shirt on a hot sunny day, you feel cooler than if you wore one that’s darker in color – that’s because the white shirt reflects more sunlight and it’s the same concept for buildings,” said Aaswath Raman, an assistant professor of materials science and engineering at UCLA Samueli School of Engineering, and the principal investigator on the study. “A roof painted white will be cooler inside than one in a darker shade. But those paints also do something else: they reject heat at infrared wavelengths, which we humans cannot see with our eyes. This could allow buildings to cool down even more by radiative cooling.”

Image: Under noontime sunlight, superwhite paints (labeled EL1 and EL3) developed by the researchers remain significantly cooler than traditional white paints (right corner, labeled EL2), which could lead to higher energy savings in buildings. Credit: Jyotirmoy Mandal.

The best performing white paints currently available typically reflect around 85% of incoming solar radiation. The remainder is absorbed by the chemical makeup of the paint. The researchers showed that simple modifications in a paint’s ingredients could offer a significant jump, reflecting as much as 98% of incoming radiation.

Current white paints with high solar reflectance use titanium oxide. While the compound is very reflective of most visible and near-infrared light, it also absorbs ultraviolet and violet light. The compound’s UV absorption qualities make it useful in sunscreen lotions, but they also lead to heating under sunlight – which gets in the way of keeping a building as cool as possible.

The researchers examined replacing titanium oxide with inexpensive and readily available ingredients such as barite, which is an artist’s pigment, and powered polytetrafluoroethylene, better known as Teflon. These ingredients help paints reflect UV light. The team also made further refinements to the paint’s formula, including reducing the concentration of polymer binders, which also absorb heat.

“The potential cooling benefits this can yield may be realized in the near future because the modifications we propose are within the capabilities of the paint and coatings industry,” said UCLA postdoctoral scholar Jyotirmoy Mandal, a Schmidt Science Fellow working in Raman’s research group and the co-corresponding author on the research.

Beyond the advance, the authors suggested several long-term implications for further study, including mapping where such paints could make a difference, studying the effect of pollution on radiative cooling technologies, and on a global scale, if they could make a dent on the earth’s own ability to reflect heat from the sun.

The researchers also noted that many municipalities and governments, including the state of California and New York City, have started to encourage cool-roof technologies for new buildings.

“We hope that the work will spur future initiatives in super-white coatings for not only energy savings in buildings, but also mitigating the heat island effects of cities, and perhaps even showing a practical way that, if applied on a massive, global scale could affect climate change,” said Mandal, who has studied cooling paint technologies for several years. “This would require a collaboration among experts in diverse fields like optics, materials science and meteorology, and experts from the industry and policy sectors.”

Source: UCLA Samueli Newsroom

Full Study: “Paints as a Scalable and Effective Radiative Cooling Technology for Buildings”, Joule.

https://doi.org/10.1016/j.joule.2020.04.010

Read Also

LA testing cooling pavement paint to combat heat

#cooling wall #paint #heat #climate #weather #physics #materials

0 notes

tekamedia · 5 years

Text

Elizabeth Hurley's son Damian wins multi-million dollar inheritance battle: report

New Post has been published on https://newsprofixpro.com/tekamedia/2019/07/21/elizabeth-hurleys-son-damian-wins-multi-million-dollar-inheritance-battle-report/

Elizabeth Hurley's son Damian wins multi-million dollar inheritance battle: report

Elizabeth Hurley’s son Damian will inherit some of his dad’s multi-million family fortune – despite his grandad’s attempt to cut him out, reports claims. Damian, 17, whose dad is millionaire Steve Bing, had been told he would not get any money from the trust… Read More

Buy Now

Price: $80.00

Item specifics

Condition: Used :

An item that has been used previously. The item may have some signs of cosmetic wear, but is fully operational and functions as intended. This item may be a floor model or store return that has been used. See the seller’s listing for full details and description of any imperfections. See all condition definitions– opens in a new window or tab

Seller Notes: “Perfect condition – works flawlessly. no excessive wear or cosmetic issues.”

Optical Zoom: 3x Custom Bundle: No Weight: 1.3lbs. Screen Size: 2.5″ Features: Auto Focus Type: Digital SLR Color:

Black

Connectivity: USB Dimensions: 5.3x3x4.1in. Megapixels: 10.2MP Series: Nikon D MPN:

1180250

Brand:

Nikon

Battery Type: Lithium-Ion Model:

d80

UPC:

0018208254125

About this product

Product Information Start enjoying a host of liberating features with the help of the Nikon D80 10.2MP Digital SLR Camera. This digital camera body packs many useful tools into one convenient package. The D80 makes it easy for you to get a good look at subjects before snapping away. It does this with the help of a large 0.94x viewfinder. Constructed from optical glass, it is capable of significantly magnifying the images it sees. It also boasts a 2.5-inch LCD color display that provides a 170-degree view at wide angles. Not only does this give you a better handle on details, but it also makes it easier to shoot at night. You’ll be thrilled with the D80’s 11-point, 3-mode, autofocus capabilities. AF-Single (S), AF-Continuous servo (C), and AF-Auto (A) are the automatically switchable focusing options. These can be programmed to focus in on photo subjects in a pre-selected area. Just as importantly, you’ll be able to follow subjects if they leave a specified area. Both of these Nikon D80 auto functions make life easier by performing these tasks on your behalf. The Nikon D80 viewfinder tool also keeps you well-informed about the status of the camera in real time. Informational items include aperture, shutter speed, battery status, flash status, remaining shots, and more. You’re sure to enjoy the features on the LCD monitor when playback time rolls around. Functions include thumbnail, zoom, and single image settings. To sweeten the deal, it promotes in-camera editing functions like D-lighting, Trim, and Image Overlay. Color Balance, Monochrome, and Filter effects are also available to you. This versatile camera body allows you to use interchangeable lenses, such as a Nikon AF-S DX NIKKOR 18-55mm VR II lens. This camera’s F-mount system makes it quick and easy to change out lenses so you can have control over your photos.The Nikon camera body is no slouch in the sensitivity department, either. It features an impressive ISO sensitivity range, with values running from 100 to 3200. These numbers mean that you’ll be able to capture crisp shots even when lighting is low. The long-exposure noise reduction design gives you the freedom to hold exposures for longer without fear of grainy-looking photos. This feature is especially helpful when taking photos at twilight or dawn. The D80 makes it easy for you to find crystal-clear focus at the drop of a hat. It brings no fewer than five separate focus modes to the table. These include Continuous Servo, Manual, Manual with Electronic Rangefinder, Single Servo, and Auto. Wide-area autofocus capabilities enhance your ability to produce sublime shots when covering sporting events. This Nikon DSLR also offers high-speed continuous shooting to help you capture amazing action shots. This camera’s CCD image-sensor technology puts the power of 10.75 million total pixels at your convenience. This capability is amply supported by an EN-EL3e Lithium-ion rechargeable battery. This powerful cell is capable of delivering 600 to 2700 shots between charges or battery replacements. During trips and vacations, you can have peace of mind thanks to the long battery life. Product Identifiers Brand Nikon MPN 25412 UPC 0018208254125 Model D80 eBay Product ID (ePID) 100110425 Product Key Features Optical Zoom 3x Features Auto Focus Color Black Dimensions 5.3x3x4.1in. Series Nikon D Battery Type Lithium-Ion Custom Bundle No Screen Size 2.5″ Type Digital SLR Connectivity USB Megapixels 10.2MP Dimensions Weight 1.3lbs. Width 5.2in. Height 4.06in. Depth 3in. Additional Product Features Light Sensitivity MAX 1600 Viewfinder Magnification 0.94x Optical Viewfinder Type Fixed Eye-Level Pentaprism Exposure Compensation ±5 Ev Range, in 1/2 or 1/3 Ev Steps Min Shutter SPEED 30 Sec Sensor Size 15.8×23.6mm Red-Eye Reduction Yes Light Sensitivity 100-1600, 3200 Exposure Metering Center-Weighted, 3d Color Matrix, SPOT Exposure Modes Bulb, Manual, Shutter-Priority, I-TTL Program Flash, Automatic, Program, Aperture-Priority Battery Form Factor Manufacturer Specific MAX Shutter SPEED 1/4000 Sec Lens for Sd Body only Additional Features USB, Autofocus Focal Length Equivalent to 35mm Camera 27-82.5mm Supported Flash Memory SDHC Card, SD Card, MultiMediaCard, SDXC Memory Card, SDHC Memory Card, SD Memory Card Flash Type Pop-Up Flash Min Operating Temperature 0°C Effective Flash Range 13m Auto Focus Type TTL Phase Detection Viewfinder Type Optical Exterior Color Black Exposure Range Ev 0-20 (Iso 100) Dioptric Correction Range -2 to +1 Continuous Shooting SPEED 3fps Still Image Format Nef (Raw), Dpof, Exif 2.1, JPEG, Dcf 2.0, Raw + JPEG, Dcf, Exif 2.21, Raw Image Sensor Resolution 10.2MP Operating System Supported Mississippi Windows 98, Mississippi Windows ME, Microsoft Windows XP, Mississippi Windows 2000, Apple Mac Os X, Mississippi Windows 98SE, Microsoft Windows 2000, Microsoft Windows 98, Mississippi Windows XP, Microsoft Windows 98SE, Apple Mac Os X 10.1.5 or Later, Apple Mac Os X 10, Microsoft Windows ME Camera Type Digital SLR Display Type LCD Sensor Type CCD Shooting Programs Night Landscape, Sports Mode, Landscape, Night Portrait, Close-Up, Portrait Mode MAX Operating Temperature 40°C Camera Flash Features Slow Sync, Flash +/- Compensation, Af Illuminator, Auto Flash, Red-Eye Reduction Flash, Rear Sync Flash, Manual, Front Sync Flash, Flash OFF!, Flash Exposure Bracketing, Fill-In Flash Display Rotation Built-In Viewfinder-Field Coverage 95% Screen Details LCD Display-Tft Active Matrix-2.5″-Color Flash Modes OFF! Mode, Fill-In Mode, Rear Curtain Sync, Slow Synchro, Red-Eye Reduction, Auto Mode Display Size 2.5in. Expansion Slot 1X SD Memory Card Connector Types 1X DC Power Input, 1X USB, 1X Remote Control, 1X Composite Video Output Focus Adjustment Manual, Automatic, Autofocus & Manual Focus

$80.00 End Date: Tuesday Aug-20-2019 15:30:58 PDT Buy It Now for only: $80.00 Buy It Now | Add to watch list

Buy Now

Price: $21.99

Item specifics

Condition:

Open box: An item in excellent, new condition with no wear. The item may be missing the original packaging or

Connectors: 3.5 mm Audio Jack Type: Portable Speaker System Model:

Everplay

Features: Mic, Bluetooth Wireless Technology: Bluetooth MPN:

BT6900B, BT6900A, BT6900

Connectivity: Wireless Brand:

Philips

$21.99 End Date: Tuesday Aug-20-2019 12:25:15 PDT Buy It Now for only: $21.99 Buy It Now | Add to watch list

0 notes

tuyetthienduong · 6 years

Text

Gia roi said sm town tim conv hinh hh

No do phat ton tho jyj cung gium davua vf roi team no do teen chuan said team no do hc lam team f kun dang le daily nen thay loi vao phat 1 roi a hoc vo thu ele n bao hinh bma hoi hieu team y la trung han nhat that tim chui ne quang cho thi nua vao do o em a nhu tt 90 ty nam vo nghia o td gia ntds no do y la no tu theo jyj nl su ae yg kien yg nguu xiu cmm f kun y la luc dau bao 3000 vo piggie a time neu no ko lam xong time job thi ko utt no do gg lay cha hieu a goc y la no hoi phat dau dv tap du hoc bi nhu nhu a choooooooooooooooooooooooooooooooooooooooooooooiiiiiiooooooooooooooooooooooooooooiiioiooooooioiiiiiiooiiiiiioooooioooiioooooiioooooiiiioooooooooooooooioooiiioooiioooiiiioooooooooooooo qua live said ted no do haiz doi nha tnts khoc q hoai lay phat bao het sm town ngu hai mai ko nho time thing said 20t kwu co ban tho o nha eun that hinh no do di keo theo 20 t y la anh xua cung nl roi dau thai gap dvb o do nhu mew two huyg same ah help phat roi bp help phat roi tama xiu kai y la lam non la lam luon bp best there oi hinh aks di no do live mew bao tro xiu nha teen no do di su team qua sj hinh ba nuoc y la no thanh 3d nho mai than thong bang time bang than kinh no do trai neu ko o day take three threr dav khoc cw qua sure thing phat thing mew 2 help ba cho mai co than thong khac lam time help ki ut no do ed y la than thong la chieu 19 piggie y la chieu 9 la ba nuoc y la neu no ko duoc chon thi vo danh mai mai q choooooooooooooooooooooooooooooooooooooooooooooiioiooooooooooooooo lu jonh y pa dau thai cung vay said hts time hoi xua co no do aau pika cuoi ne ht oi em la con gi ha ele seen team q y la co time la thanh nguoi khong lo lay hts song a mv think ai next giet jet roi gai do ko tranh hh sc qua dj hinh thoi y la co y de tao bi hai cho vo no best att duoc chi moewth said qua latias hts help jynx psy nhieu time y la tui anh lam dai nhu no noi a no cung bay mo tu tu qua ut xiu y la ban dau la trat tu tu nhien said tg ma no lam cho sc hau vo moewth di bui jerk biet anh ca lt hsd2 vay sao con lam o day pika u bao toan y la hai anh a huyg help sang moi co so it qua huyg helps s goc di bui qua cua lay team it oi di ljs luon cung akL same V hinh k nhuc dom anteam nh hoai cua no do cho doc cua kbn ne team cs vo nghia qua said toan hinh town hinh se cung ing huy hinh 99 no nl tnt monh no lanh nl y la kbn a add nhin giong 28t aks giet do dom fam thoi tren xiu lay tank minh xiu bs a team help 9 di lon sr ttdc thing xiu nha chom nhu lon phat no dinh add yep cho said chos

Tum khon nga con kbn thing team

E db sao em len hinh xau qua vay nl da khan y la no tu bc nen full mat ko che tap bang j22 nl hoan ic jn bma help gan bang ele bi kich pika here y la tca ma ko pen phat noi t di nt y lq het ba kia la hen a said mew team hv sdl roi dv same help ssl ssly hh bma bang jn a pika no do ele same zoned manh y la kbn doi hoi nua team y la xai than thong no ba kia ko qp khinh anh 21 khinh luxia jn khinh pika khinh pika ut khinh raichou khinh phat khinh kts khinh chu khinh ppn khinh nguu khinh q khinh tnt khinh bh khinh other chas team jn xiu ko he y la nhin giong tama tama khinh tu than khinh of khinh db khinh ly khinh nhat ne tan hts khinh time khinh ut lac con khinh hct moewth 2 y la no lam ma ko can sua a doc doi moewth bg cung att team bh xiu y la sc la huong noi dau coi em a moewth nhin no lam viec team qua sj y la groot la tim cua all time y la anh co tung thu tay trai thing duck xanh cung lo luon ne team q anh the no ko biet co san hv tr tuong biet s15 hieu pika duoc bang cc hts hh bi dc team tnt lan cut song dv hh xiu y la bai nao cung vay jn khoc nhuc hoan dep la duoc giet gium team f kun tb temp khoi no do moc ra coi hoai ranh phat a pika ko the cuoi a khoi lay luon cung duoc nl hh lam tro he voi db hhh thu phat pika p21 jn phat phat lu phat anh 21 phat moewth phat aU ele xiu phat vi nhan linh phat sa dis sd chet phat phats phats same max hoi hieu team hts phat phat time ut xiu gium phat pika ut xiu luon tried team hoan same them team sw phat sw nl hien phat do ele lay cung team phat 99 xiu phat ku j22 kwu hi lo team phat j22 phat tim db nl teen xiu phat ppn dang cut khoi free vi nhan nc qua phat linh hoan nho hn songs 4k ne haiz hct y la dau voi khong tu 3d kp a k cui si k xiu so qua team pika help muon len dua len ly ly chet o do di bc team ichu all that bh tho gium tama said bh hoai gg em phat mv day 9k gee cho de tnt xiu nhuc dep duoc khoi 10k ne 20k thu 22k 48k qua tnt di bui oi 50k "2 1k roi 48k lai qua beat 8k beat rush fav beatie q thu hoan xiu dep team tama di nhien leu sb mat team tu than di team tnts j22 db mat nc ao roi team phat bay beat rush qua j21 di team linh song la phai giet sang hoan cho linh wuang cho hoan hhh ngai thu th no do nen lam slve teen thu tranh lo ten em Au huyg nhuc Ag nl 20t no do that way y la no khinh han biet doc bao a sat 2400 tutor ko hox biet blog cho hay shoz k22 no do ti du ko biet nhuc wuang cho linh xiu hh thu kp k21 sao ki vay hinh level tnt live nhu cut thua time xa a said vol team kinh di vl ntd help qp ko nghe lo f kun ngon khoi ko muon len bn same el3 trum huy same phat same muk thay cut scy hoan same ne hv co gi dau 17 that kbn gg level tank xiu hung do phat sox team moi thay dv ds qua lay j22 qua mum anh chi hien tien qua gou y lano moi biet luon mum no do oi qua gou hinh h y lq khuc do thuan dien linh said qua gou hinh h tanks tu hts xiu team o nha qua q xiu nh qua y la bua nay lay lai than thong nen con duong khac qua s goc y la no het sang ma nghi minh sang ko khac qua gou hinh h ele that ko chi nl nhuc no do thoi xua said ht 21 t nay thay hien tien qua y la thoi moi em a ko tu duoc nua tds xiu y la llq qc moi qua 12 su quan hinh ah xiu qua nh hinh h that vui team ted hinh ntd mat qua y pa mai co the lam bieng 20t that time tinh y nhau time tr qua k hh h that k phat nh se y la ko lam duoc qua phai do cu k qua tama lay hi lac cha ne hct that keo qua lc bo lau hi qua no do mat giong yhing qua k bat cc hi lam 50 a trau thoi qua k hinh 2 k hen la hinh thai map anh 23 poke thich thi nhao vo huyg ranh qua y la con hay len hinh qua y la khoai danh voi phat a phat o sau lung ko nguu nhuv y la ko bi kia qua thit ngon assb bach ngon 3 ngay dia nguv tran gian bao that an giun ngon qua thai a lay thai qua no do jshit icac etc qua hoan hinh hh no do teen hoat hinh h 20t nen o nha bma nua ka ut hh kb that tama same s giua nhin nhu cut phat a cho kia tr qua y la nhay cam space no do oi dinh la mtds qua sw wc pmax hay ted nhuc duc no do 21t deels qua huyg xiu qua huy xach di qua 99 f kun quen xao qua elon khoi ak di dn so xiu keo huy moi hieu a hg noi tieng phat that king 3 tha im hv

0 notes

tippytopshapeusa · 6 years

Photo

#BREAKING_Daily_INTEL_Report #Please_share+ #NocNoc + #TicToc (:-)(-:)🔮(:-)(-:) * @Melanie83000680 @hwt123 @worldgoneweirde @LauraHa69544517 @JulieHarris05 @usnews24x7 @lizcabrera55 @EnglishMist117 @Ecomemory1 * #STOPTheCaravan #JobsNotMobs #KAG2020 #MAGA #WWG1WGA #PCM1A1 #abc #arc #dqm #jad #lfls #STR8TalkWithLeo * ~ #EL3 #Reddit - #history - #IonceheardthattheUSneverattackedacountrywithaMcDonaldsinit. #Isthistrue? https://www.google.com/amp/s/amp.reddit.com/r/history/comments/4nn228/i_once_heard_that_the_us_never_attacked_a_country/ #Non-official #cover - #Wikipedia https://en.m.wikipedia.org/wiki/Non-official_coverIs it true that no country with a #McDonaldshaseverattackedtheUnitedStates? | #YahooAnswers https://answers.yahoo.com/question/index?qid=20110417091050AAPhfTu #TheendoftheGoldenArchesdoctrine https://www.google.com/amp/s/amp.ft.com/content/1413fc26-f4c6-11e4-9a58-00144feab7de #10countriesthatbannedMcDonalds https://www.telegraph.co.uk/travel/lists/the-countries-that-banned-mcdonalds/ https://www.instagram.com/p/BqNxeSknlDy/?utm_source=ig_tumblr_share&igshid=10c00qtzkr7v9

0 notes

jasondyinternational · 7 years

Photo

IG | @jasonjamesdy: #OOTD for sir EL3's birthday. Happy Birthday sir Gabby! 🎉 Styled by @perrytabora Grooming by @mabeth_concepcion . . . #JasonDy #TheVoiceOfRNB #Dyfenders #InMyHead #abscbn #Dapper #MensFashion http://ift.tt/2w03gUr

#Instagram #JasonDy

0 notes

shinyquagsire23 · 4 years

Text

🔋 📱❄️🥾🔓, an EL1/EL3 coldboot vulnerability affecting 7 years of LG Android devices

I should probably preface all of this by saying that I'm not really a security professional in the sense that I don't actually do security stuff for a living; I reported this vulnerability in March and gave a 90 day delay on releasing specific details mostly just because that's A Thing That Security Researchers Do. Also the vulnerability doesn't require user interaction from coldboot so it's a bit nasty in that regard. But also this vulnerability sat around for 7 years so it could be argued that, if anything, 90 days is too long.

Anyhow jumping into things, this is a writeup documenting CVE-2020-12753, a bootloader vulnerability affecting most Qualcomm-based LG phones since the Nexus 5, all the way up to the my test device, the LG Stylo 4 Q710 (and 5 Q720), and probably others. While working on the implementation of this vulnerability I thought it was odd how few bootloader vulnerabilities for Android actually get properly documented, and given the sheer spread of affected devices of this particular vuln I thought it'd be interesting to document it in detail.

A Quick Primer on the (Qualcomm) Android Boot Process

The device I'm working with, the Stylo 4, operates on 2013-2016 variant of Qualcomm's boot sequence described at https://lineageos.org/engineering/Qualcomm-Firmware/:

- On power-on, the Primary Bootloader (PBL) initializes DRAM, eMMC, etc and then loads and verifies SBL1 (Secondary Bootloader 1) from eMMC. - SBL1 then loads and verifies the Trusted Execution Environment (TEE), aboot, and a few other bits and pieces and then jumps to the TEE, in this case Qualcomm's Secure Execution Environment (QSEE) - QSEE sets up secure EL3/EL1 (TrustZone) and jumps down to aboot (non-secure EL1) - aboot loads and verifies the Linux kernel and jumps to it

Some Android devices allow "bootloader unlocking", which allows unsigned kernels to be loaded and run. Generally this unlocking occurs via aboot, and the implementation varies from vendor to vendor, however in most cases what happens is that a fastboot command gets sent to the phone to unlock/lock the phone, and as part of Android's Verified Boot, the phone's storage is wiped on this transition. There's also some requirements on user verification so that, in theory, this unlock cannot occur without user interaction.

Additionally, with verified boot enabled, Android will use dm-verity to verify all files on the root/system partition, and SELinux is run as Enforcing.

Variants on the Boot Process, added by LG

In practice, the boot process isn't quite so simple: Vendors are able to add modifications to the boot process as they see fit. In LG's case, these differences can be summarized as follows: - Hardware bringup in SBL for charging PMICs, LEDs, and other misc hardware - Misc logging/debugging modifications - Additional TEE processes for SIM unlocking, backed by RPMB - In aboot, vendor-specific fastboot commands (or no fastboot at all in the case of my device), restrictions on unlocking via certificates, verification modifications, additional boot args for Linux, etc - Vendor-specific recoveries/flashers, LAF in the case of LG

While I initially started in a privesc from within Linux (and got ~close to getting kernel execution), Google has done a lot of work to ensure that vendors can’t mess up Android security. However, bootloaders have a lot less oversight, so going after these vendor-specific bits of hardware bringup seemed extremely opportune for errors.

Introducing: raw_resources

At an undetermined point in time (likely prior to the Nexus 5 releasing), LG added an "imgdata" partition on eMMC to store boot graphics for Download Mode, fastboot graphics, charging graphics, the unlock graphic and so on. Image data is stored RLE compressed and for each image, metadata for the image width, height, x and y position are specified. The Nexus 5’s final bootloader image, as far as I can tell, only accesses this partition from aboot; SBL1 is not affected on this device. For the curious, I have a Python3 script which can extract these images at https://gist.github.com/shinyquagsire23/ba0f6209592d50fb8e4166620228aaa5.

A few examples of Nexus 5 imgdata resources

imgdata later became raw_resources, and at an undetermined point, the same RLE decompression and metadata interpreting was copied into SBL1 for use in boot paths where the battery has discharged significantly. If the battery is discharged too far, SBL1’s pm_sbl_chg_check_weak_battery_status will display LGE_PM_NO_CHARGER for boot attempts made without a charger connected, LGE_PM_WEAK_CHARGING_ON for boot attempts with a charger connected, and LGE_PM_NO_BATERY_ANI_* for boot attempts made without a battery. A script for extracting raw_resources can be found at https://gist.github.com/shinyquagsire23/b69ca343fd2f246aee882ecb5af702bd.

A few examples of Q710 resources

On normal boot paths, aboot reads raw_resources to display the boot logo, download mode graphic, and verified boot statuses for devices which allow unlocking. In my case, the Q710/Q720 does not allow for unlocking, so this boot path is never reached on these devices. However, the graphics still exist I guess on the off chance that they allowed it to happen.

For the C inclined, the format of raw_resources can be summarized in these structs: typedef struct boot_img_header { char magic[0x10]; uint32_t num_imgs; uint32_t version; char device[0x10]; uint32_t signature_offs; } boot_img_header;

typedef struct img_info { char name[0x28]; uint32_t data_offset; uint32_t data_size; uint32_t width; uint32_t height; uint32_t offs_x; uint32_t offs_y; } img_info;

The following calculation is performed in order to determine the output pointer to be used during decompression: bpp = 24 screen_stride = fbinfo->screen_width; fbuf_offset = offs_x + (screen_stride * offs_y); fbuf_out = (fbuf_offset * (bpp / 8)) + fbinfo->buffer;

offs_x and offs_y are not bounds checked, and fbinfo->buffer is known in SBL1 and aboot, allowing for a controlled arbitrary write in both environments.

SBL1 load_res_888rle_image Arbitrary Write

This boot path requires discharging the battery to below 0%. While this is less feasible for any practical usage, performing the arbitrary write at this point allows patching SBL1 to disable signature verification before TEE and aboot are loaded. Any of the LGE_PM_* images can be hijacked selectively for arbitrary code execution, though for my PoC I used LGE_PM_NO_CHARGER specifically because I didn't want to accidentally brick myself (or well, I didn't want to have to beep out eMMC wires on the board to unbrick).

A 32-bit x offset can be calculated for any given address divisible by 3 using the following calculation: offset_x = (((0x100000000 + target_addr) - 0x90000000) / 3) & 0xFFFFFFFF

Data written to this arbitrary address can be kept contiguous by specifying the image width to be the same as the screen width. The height should then be rounded up from the payload size to ensure all data is written properly. So really by the end, this isn't an arbitrary write so much as it is an arbitrary memcpy at Secure EL3.

aboot Arbitrary Write

The aboot arbitrary write functions identically to SBL1: Any image can be selected to perform the arbitrary write. Most notably, this includes any lglogo_image_* graphic, which is displayed by default on every boot. The framebuffer is generally fixed to address 0x90001000, which means that by using the arbitrary write to gain code execution, the original graphic which was used to obtain the arbitrary write can be written to the screen following hijacking to, in effect, make it appear as if boot flow has not been modified at all, for better or for worse.

A good question that might be raised after looking briefly at the structs earlier would be, "wait, there's a signature offset, why does any of this work if raw_resources contains a signature?" And yes, raw_resources contains a signature! But it's a useless signature because this signature is only checked in aboot while displaying verifiedboot_* images. At some point, XDA users found out that you could swap the LG boot logos over the verifiedboot_* images so that when they unlocked their devices they wouldn't have to see the AVB boot nag messages. Naturally, this defeats the point of Google's Verified Boot spec since it would potentially allow a bootloader be unlocked without the user knowing, so LG added a signature. But it’s only checked for the verified boot images.

As a minor note, unlike SBL1, aboot will also select between raw_resources_a and raw_resources_b depending on the A/B boot slot.

Practical Exploitation

I started by exploiting SBL1, partially because Secure EL3 is just cooler than nonsecure EL1, but also because the framebuffer address was more obviously seen than in aboot (though I later found the aboot framebuffer address anyhow). At this point in execution all of the hardware is initialized and no other bootloaders have been loaded, so we're basically free to patch sigchecks and control the entire phone!

As it turns out though, SBL1 takes a bit more work to actually exploit, because unlike aboot, its segments aren't set RWX. I'm not really sure why aboot has all of its segments RWX, like at that point it's more of a 'boot' than a 'secure boot' if they can't even bother to use the easiest security option available.

In any case, ROP is required briefly to bypass the MMU's NX bit. This isn't too terrible, since SBL1 actually has a routine we can jump to to disable the MMU, though it requires a bit of finnagling to get correct.

So in summary, the exploitation process goes as follows: - Flash raw_resources_a.img to eMMC (ie via kernel execution, LG LAF, soldered wires and a hardware flasher, etc). - For SBL1 hax, drain the battery to below 0%. For my Q710, I drained most of the battery by leaving the screen at max brightness with sleep disabled until the phone powered off on its own after several hours. To drain the remaining battery, I charged enough to enter LAF download mode and left it to drain with the screen on for 2-3 hours. - Hold Power and Volume Down until the phone restarts. If the phone discharged enough, the phone should restart into the payload. - The phone can be plugged in to boot into aboot and Android normally, but the payload will now execute every time the payload-injected graphic is displayed.

To exploit SBL1: - raw_resources_a is modified such that the x offset is set to 0x2801CF5C, the width to 1080, and the height to 5. This will decompress LGE_PM_NO_CHARGER (now containing the contents of payload.bin) to 0x08056E14, slightly higher than the stack pointer during decompression. - The image is decompressed and load_res_888rle_image exits. The previous LR has now been overwritten by a pointer to a Thumb-mode pop {pc} ROP slide, to account for possible offsetting error. - At the end of the ROP slide, the following ROP instruction sequence is executed:

pop {r4-r12, pc} ; r8 is now set to SBL1_ARM_MMU_DISABLE, and r12 is now set to SBL1_THUMB_BX_R8

pop {r4-r6, lr} ; LR is set to the payload pointer orr r12, r12, #0x1 bx r12 ; jump to SBL1_THUMB_BX_R8

bx r8 ; jump to SBL1_ARM_MMU_DISABLE with lr now set to our payload

youtube

Proof-of-Concept, and Future Plans

For those interested in experimenting, a PoC can be found here. Note that this is specifically for the LG Q710, and contains offset specific to the AMZ LG Stylo 4 (Q710ULM, 20c_00_AMZ_US_OP_1121). I'm planning on polishing things up further, however my current boot takeover involves two other vulnerabilities that I'd like to give a bit more time to make sure they're actually fixed/close to being fixed before releasing.

In the meantime I'd be interested in seeing if anyone else is interested in porting this to other LG devices, since I only own a Nexus 5, a Q710 and a Q720. As it is, these vulns will allow bootloader unlocking at a minimum on most older Qualcomm LG devices, and secure EL3 on newer ones, which should be very interesting for anyone interested in finding vulnerabilities in QSEE/similar on LG devices.

#CVE-2020-12753 #exploitation #bootloader #Android #Android ROMs

9 notes · View notes