Database Info

Spains got it!

Software Update version 2.2 for Milestone Android
Introduction
We are pleased to announce the launch of the Android ™ Software Update 2.2 (Froy) for users of Motorola Milestone. The Android software update 2.2 (Froy) includes many new features, shortcuts and improvements. Upgrade your version now and get the best performance.
For more information on Support for Motorola Milestone Motorola, visit www.motorola.com / mymilestone.
You can find additional support for Milestone in http://www.motorola.com/Support/GB-EN/Country-Selector/Milestone.
Users can use this version
ALL users of Motorola Milestone
After downloading and installing the Android software update 2.2 (Froy), enjoy:
Improvements:
•
Improved web browsing with support for Adobe ® Flash ® Player 10.1, currently available for download from Android Market
•
Improving the performance of the browser to load faster JavaScript heavy pages.
•
New security features include remote wipe, device lock, complex passwords and minimum number of characters per password.
•
Improved performance and 3G Mobile Hotspot.
•
New tips, shortcuts and assistance from a widget on the home screen to help users better navigate the phone.
•
Possibility to easily switch between applications used the last eight.
•
Voice dialing via Bluetooth ® shows and repeats his instructions.
•
Switching between letters, numbers and symbols by sliding your finger on the touch screen.
•
Improved performance and Wi-Fi connectivity.
•
Screen rotation 270 degrees to work with applications in any direction.
•
Managing contacts with the backup wizard to date.
•
Easy editing MMS message attachments after video.
•
Protection of applications and settings to the role of backup and restore Google.
Improvements:
•
Improved security options complex numeric and alphanumeric passwords.
•
Improved sound quality.
•
Viewing PDF files and Microsoft ® Office sent from email accounts Outlook ® 2003, Yahoo ® and Outlook Express, and TXT attachments from email accounts.
•
Keep the original locations of the icons on the main screen after the update via your mobile connection.
•
Easy shortcuts to the phone, start the tool and the browser application from any of the five main screens.
•
Management password policies for Microsoft Exchange administrators in all devices.
•
Synchronize your Exchange account and automatically fill in your e-mail addresses of the recipients.
•
Highest level for tones and notifications.
•
Edit Calendar Corporate meetings that are repeated a large number of guests.
•
Home Screen with shortcuts.
•
Improving the management of images to photographs sent to the phone via Bluetooth Milestone.
•
Improved Hotmail ® account synchronization with a large number of messages.
•
Optimized efficiency in Microsoft Exchange Active Sync ®
Improve communication with intelligent functions Android 2.2
•
Android 2.2 mobile organizational power and response time. Specific shortcuts can easily access the phone, start the tool and the browser applications from any of the five main screens. Get enhanced security with password options numeric and alphanumeric.
•
Now Microsoft Exchange administrators can manage the password policies on all devices to ensure the security of company information. Android 2.2 lets you use Exchange calendars in the Calendar application. In addition, use voice dialing via Bluetooth for handsfree phone calls and listen to your instructions to ensure accuracy.
Instructions for installing the update
Instructions on updating (United States) - Instructions on updating http://www.motorola.com/repair (other countries) - http://www.motorola.com/update
Installation Assistance Update
Click here to go to the customer www.motorola.com / support or to receive help from other users in our online community at https: supportforums.motorola.com.
Some services, functions and applications are network dependent and may not be available in all areas, it is possible to apply other terms, conditions and rates. The specific functions and features of each version of Android software may vary. For more information, check with your carrier.
MOTOROLA and the Stylized M logo are trademarks or registered trademarks of Motorola Trademark Holdings, LLC. The Bluetooth trademarks are property of their respective owners and are used under license. Google, Android and Android Market are trademarks of Google Inc. All other product or service names are the property of their respective owners. © 2010 Motorola Mobility, Inc. All rights reserved.
Regards, PK

Is it an OTA update?

confirmed! is there!
lets the development begin!

sileshn said:
Is it an OTA update?
Click to expand...
Click to collapse
It's a downloadable update.
On the right hand side bar (on the Spain site) there is a direct link.
Sent from my Milestone

motorator said:
It's a downloadable update.
On the right hand side bar (on the Spain site) there is a direct link.
Sent from my Milestone
Click to expand...
Click to collapse
Can you post the link here.

sileshn said:
Can you post the link here.
Click to expand...
Click to collapse
My mistake, it was a link to a PDF upgrade guide, not the actual upgrade.
Sent from my Milestone

motorator said:
My mistake, it was a link to a PDF upgrade guide, not the actual upgrade.
Sent from my Milestone
Click to expand...
Click to collapse
That's ok. Flashing 2.1. lets see if i get an OTA update.

sileshn said:
That's ok. Flashing 2.1. lets see if i get an OTA update.
Click to expand...
Click to collapse
i'm without battery could you please confirm if you have it avalible?

boto said:
i'm without battery could you please confirm if you have it avalible?
Click to expand...
Click to collapse
I didn't have the 2.1 sbf. I am downloading atm. Will let you know if i am successful.

Update
No OTA update. No update via software update as well.

Vaporware

sileshn said:
I didn't have the 2.1 sbf. I am downloading atm. Will let you know if i am successful.
Click to expand...
Click to collapse
i was saying OTA update, but you already answer me on the next post.
dammed! we will need for some SBF avalible.

I have SBF flashed and connect through Moto software update but it said No update available. I am from Singapore.

everyone flashed yet?
what kernel using in this fw?

That PDF has been posted for several days already!!!

Any updates on this ?

shreyas99 said:
Any updates on this ?
Click to expand...
Click to collapse
Yes, here:
http://forum.xda-developers.com/showpost.php?p=10851254&postcount=32

I was just passing an English translation of a Spanish release and forgot to give credit where do: Link (to Spanish pdf) originally Posted by DiaboluZ (here) View Post From nadbalak/comments homepage...
I only know now the puff in the piece is probably a little premature but it seems worth checking back frequently. When it does materialize it would be nice to squeeze an sbf out of it... and off to the boys in the kitchen.
PK

pk2 said:
I was just passing an English translation of a Spanish release and forgot to give credit where do: Link (to Spanish pdf) originally Posted by DiaboluZ (here) View Post From nadbalak/comments homepage...
I only know now the puff in the piece is probably a little premature but it seems worth checking back frequently. When it does materialize it would be nice to squeeze an sbf out of it... and off to the boys in the kitchen.
PK
Click to expand...
Click to collapse
???
DiaboluZ post: 23 th Jan 08:03 PM
My post: 21st Jan 10:08 AM

I have a Milestone A853 from Venezuela which uses 850/1900MHz for 3G.
Is it possible to flash the RTEU sbf and then apply the LatAm baseband through OR???
I want to flash that ROM and check for updates.
Cheers!

Researchers warn over OTA Exploits of Baseband Processors (radio firmware)

Thom Holwerda at Real-Time Embedded OS specialized website OSnews reports about vulnerabilities that lurk in closed-sourced radio chips.
The second operating system hiding in every mobile phone
The insecurity of baseband software is not by error; it's by design. The standards that govern how these baseband processors and radios work were designed in the '80s, ending up with a complicated codebase written in the '90s - complete with a '90s attitude towards security. For instance, there is barely any exploit mitigation, so exploits are free to run amok. What makes it even worse, is that every baseband processor inherently trusts whatever data it receives from a base station (e.g. in a cell tower). Nothing is checked, everything is automatically trusted. Lastly, the baseband processor is usually the master processor, whereas the application processor (which runs the mobile operating system) is the slave.
(...)
With this in mind, security researcher Ralf-Philipp Weinmann of the University of Luxembourg set out to reverse engineer the baseband processor software of both Qualcomm and Infineon, and he easily spotted loads and loads of bugs, scattered all over the place, each and every one of which could lead to exploits - crashing the device, and even allowing the attacker to remotely execute code. Remember: all over the air. One of the exploits he found required nothing more but a 73 byte message to get remote code execution. Over the air.
Click to expand...
Click to collapse
Source, via HN
Comments at HN are also worth reading, I think.
Do note, that the study run on some old generation of MSM chips.
Here is a counter argument for instance:
Comment by OsQar
by OsQar on Wed 13th Nov 2013 09:51 UTC
I'm not a security expert at all, but I've been working on mobile radio access technologies for several years, so I feel quite confident to say that some or your claims are wrong. E.g:
"The standards that govern how these baseband processors and radios work were designed in the '80s, ending up with a complicated codebase written in the '90s - complete with a '90s attitude towards security."
Well, GSM's baseband was developed from late 80's to early 90's, UMTS' from late 90's to early 00's, and LTE's can be now be considered almost finished. I know that GSM is not secure at all now (it was when it was released, but now it has been cracked), but I'm not so sure about UMTS (CDMA is very hard to demodulate, so cracking is even worse) and LTE (OFDMA is quite a headache).
"What makes it even worse, is that every baseband processor inherently trusts whatever data it receives from a base station (e.g. in a cell tower). Nothing is checked, everything is automatically trusted."
This is NOT TRUE. At all. Even from GSM times. Handheld devices run a bunchload of ID checks to know what basestation is sending data; and basestations also carefully allocate and check mobile ID's. This is especially true in UMTS (where you have to discriminate interferring users by using pseudorandom codes) and LTE (where you even need angle-of-arrival information to reach more users).
So, I'm not claiming that mobile basebands are inherently secure, but they're definitively not based on 80's security technology.
On the other hand, I agree with your viewpoint that the closed implementations and the huge standards are not the best way to allow the community to check for security bugs. But manufacturers are the main supporters of actual standardization bodies, so it's quite complicated to fight against it.
Click to expand...
Click to collapse

MediaTek FOTA reverse engineering

So, I decided to have a look at how my Cat B15Q actually recieves OTA updates. Turns out the lifting is done by two apk's in /system, FWUpgrade.apk and FWUpgradeProvider.apk.
Notes taken during reverse engineering:
the entire upgrade mechanism runs over plain HTTP, so you can use tools like fiddler or wireshark to listen and manipulate the entire mechanism (just imagine deploying a malicious proxy with ettercap on a conference wifi and pwning all mediatek devices)
mediatek seems to supply handset manufacturers with a set of PHP scripts for providing OTA upgrades.
the whole code is littered with typos ("onHandsakeAuthentication", "downlaod" and more), commented-out code and other stuff which makes me wonder just how it works, but well I always have that feeling when I have to read Mediatek source code
an old version of the client-side source, written for another mediatek device, is at https://github.com/kupyxa4444/baoxu...a/src/com/mediatek/GoogleOta/HttpManager.java
something in the core methods apparently messes up both JD-GUI and Procyon decompilers
the core mechanism for obtaining a download/checkversion token is just a md5sum (fixed "tag string" 15811375356 + server-sent "rand"); funny enough that this "tag string" is sent as "serial number" during login and is apparently totally hardcoded.
at least in this 2012 ROM dump, the endpoint addresses are stored in res/values/address.xml, however this is not present in "my" apk, nor in /data/data/com.fw.upgrade. Looks like the new version uses SharedPreferences, but there is no backing store in /data/data/com.fw.upgrade either.
Because I don't really like unknown parties being able to link together my SIM and IMEI (especially any random wifi snoop, this thing is a background service), I have killed off the OTA service and wrote me a little script to check and fetch updates: https://gist.github.com/msmuenchen/c3fb276f264058b8d51e
By the way, I don't know what the ... the guys at mediatek are smoking, but that code... it is sufficient to say that it would be trivial to thoroughly **** up any OTA distribution, up to the point of distributing malware and rootkits. To top it off, some guy even dumped a boatload of internal mediatek stuff to github, and the horrors I have seen there are beyond imaginable.

Security risks by staying on Android 4.4.4

Hi fellow hammerheads,
I'm running the last kitkat milestone of liquidsmooth on my nexus 5 and have it so perfectly customized that I hesitate to upgrade.
It doesn't help that a substantial number of users are unhappy with lollipop, i.e. battery drain, memory leaks, various bugs, cumbersome notifications etc. Besides the fact that liquidsmooth is not officially maintained for lollipop, the lack of xposed would be problematic because I've grown to rely on xprivacy, amplify battery extender, YouTube adaway and a few other modules.
Most importantly though is that Android 4.4.4 has a few vulnerabilities ranked high by belarc security advisor and which have been patched in lollipop.
I don't know enough to gauge whether these security holes are actually serious enough to warrant an upgrade, or if they are something that is unlikely to be used to compromise my phone.
Thanks in advance.
Here are the results of a scan by belarc security advisor:
Security Advisor v1.0.25
Last scan: Mar 21, 2015 3:02:50 PM
Vulnerable software: 2
Total Vulnerabilities: 5
Vulnerable Software
Android OS / version 4.4.4
Vulnerabilities: 4
Severity: 3 High, 1 Low
Severity: 7.5, CVE-2014-8507
Multiple SQL injection vulnerabilities in the queryLastApp method in packages/WAPPushManager/src/com/android/smspush/WapPushManager.java in the WAPPushManager module in Android before 5.0.0 allow remote attackers to execute arbitrary SQL commands, and consequently launch an activity or service, via the (1) wapAppId or (2) contentType field of a PDU for a malformed WAPPush message, aka Bug 17969135.
Severity: 7.2, CVE-2014-7911
luni/src/main/java/java/io/ObjectInputStream.java in the java.ibjectInputStream implementation in Android before 5.0.0 does not verify that deserialization will result in an object that met the requirements for serialization, which allows attackers to execute arbitrary code via a crafted finalize method for a serialized object in an ArrayMap Parcel within an intent sent to system_service, as demonstrated by the finalize method of android.os.BinderProxy, aka Bug 15874291.
Severity: 7.2, CVE-2014-8609
The addAccount method in src/com/android/settings/accounts/AddAccountSettings.java in the Settings application in Android before 5.0.0 does not properly create a PendingIntent, which allows attackers to use the SYSTEM uid for broadcasting an intent with arbitrary component, action, or category information via a third-party authenticator in a crafted application, aka Bug 17356824.
Severity: 3.3, CVE-2014-8610
AndroidManifest.xml in Android before 5.0.0 does not require the SEND_SMS permission for the SmsReceiver receiver, which allows attackers to send stored SMS messages, and consequently transmit arbitrary new draft SMS messages or trigger additional per-message charges from a network operator for old messages, via a crafted application that broadcasts an intent with the com.android.mms.transaction.MESSAGE_SENT action, aka Bug 17671795.
XDA Free / version 3.9.8 / com.quoord.tapatalkxda.activity
Vulnerabilities: 1
Severity: 1 Moderate
Severity: 5.4, CVE-2014-5681
The XDA-Developers (aka com.quoord.tapatalkxda.activity) application 3.9.8 for Android does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

Bump to the top for increased visibility.

This is not specific to the Nexus 5 so I would suggest you the Security forum: http://forum.xda-developers.com/general/security

[Kernel][patch] Meltdown/Spectre processor (CPU sec vuln.) mitigation discussion

LineageOS / 3.4 kernel security vulnerability patch / change
Posting this here, since this is in everyone's interest to reduce attack surface to these kind of attacks to a minimum
Quoting:
https://blog.barkly.com/meltdown-spectre-patches-list-windows-update-help
Meltdown and Spectre Overview
Before we dive in, here's a quick recap of what Meltdown and Spectre are all about. For more in-depth details see our post, The Meltdown and Spectre CPU Bugs, Explained.
Meltdown (CVE-2017-5754)
Meltdown is a CPU vulnerability that allows a user mode program to access privileged kernel-mode memory. It affects all out-of-order Intel processors released since 1995 with the exception of Itanium and pre-2013 Atoms. A list of vulnerable ARM processors and mitigations is listed here. No AMD processors are affected by Meltdown.
Of the two bugs, Meltdown is the easier one to fix, and can largely be addressed with operating system updates.
Spectre (CVE-2017-5753, CVE-2017-5715)
Spectre isn't so much a specific vulnerability as it's a new class of attack. It's enabled by the unintended side effects of speculative execution (something processors do to speed things up by predicting what instructions they're about to recieve and executing them ahead of time).
There are two flavors of Spectre — variant 1 (bounds check bypass, CVE-2017-5753) and variant 2 (branch target injection, CVE-2017-5715). Both can potentially allow attackers to extract information from other running processes (ex: stealing login cookies from browsers).
Intel, ARM, and AMD processors are all reportedly affected by Spectre to some degree, and it poses significant patching problems. While operating system and browser updates have helped mitigate the risk of Spectre to some degree, experts agree the only true fix is a hardware update. As such, Spectre is likely to remain an issue for years to come.
Meltdown-Spectre-comparison-table.png
Source: SANS / Rendition Infosec. See the full presentation here
It's important to note that both vulnerabilities put information disclosure at risk. Neither are remote execution vulnerabilities — in other words, they don't allow attackers to run malware.
Click to expand...
Click to collapse
Following Android's January 2018 security bulletin the following kernel change was rather eye-catching:
CVE-2017-13218 A-68266545* ID High High-precision timers
Click to expand...
Click to collapse
Unfortunately (or luckily for us, security by obscurity) - these kind of kernel changes aren't easy to find for quite some time
It turns out the change is the following:
clocksource: arch_timer: make virtual counter access configurable
The changes to be applied are made in the file drivers/clocksource/arm_arch_timer.c fortunately at first glance it doesn't exist in 3.4 kernels,
unfortunately "Enable user access to the virtual counter" is still (already) there, namely:
arch/arm/include/asm/arch_timer.h
So:
I ask the kernel devs to try out (read: "port back") that change to the 3.4 kernel for the Note 3 (or well, referencing this - all Android devices running 3.4 based custom kernels)
P.S.:
the following important ashmem fix (preventing memory corruption) also potentially is applicable to the 3.4 kernel source:
staging: android: ashmem: fix a race condition in ASHMEM_SET_SIZE ioctl

I haven't built a Note 3 kernel since ... ever - so haven't tested that change and if the resulting kernel would boot,
so I can't say if there's any adverse effects when disabling user(space) access to the virtual counter, in any case security should supersede convenience or even functionality