Tuesday, 11 June 2019

Candy clothes dryer and "Smart Touch" phone app

This post starts with the failure of an old trusty workhorse. Our old Hotpoint dryer finally gave up on us after more than 12 years doing it's job. Several replacement parts (thermal cut-out and heater element) but otherwise it did a great job.

So we were in the market for a new one, and buying a lot from AO I went with one of their "Exclusive" Candy products, with the catchy name "Candy Grand'O Vita CSVV9LG 9Kg Vented Tumble Dryer - White - C Rated". It claimed a decent 9kg load size, vented (Our previous was condensing, but as this was going in the garage I'd just fit a vent) and energy C rated (As we seem to eat energy in this house!).



The biggest attraction though came in the features:

"Sensors work out the perfect drying time"
and
"Monitor & add new drying cycles from your smartphone"
and
"Time to End of Programme - YES"

This sounded great, since the dryer was in the garage we never knew when it was done and had to keep going and checking on it, resetting it, etc (the old one).

Reading the blurb it sounded ideal:
"This model also has a Smart Touch feature, which lets you monitor the drying and even download new programmes using your smartphone."

Cool, so for the gadget family like ours, being able to remotely talk to it, check the drying state and set it sounded good to us.
So it arrived, on-time as usual from AO (I have to recommend them and their deliveries, they are on time, ring you before, let you track their delivery, etc, which is pretty good) and we got it all setup.

We then followed the instructions to download the app "Candy simply-Fi" and went through the setup. It was when it asked me to place my NFC enabled phone beside the dryer over a special panel I started to realise something. It doesn't use WIFI, it doesn't have a CAT5 socket... It used NFC to talk to your phone.



NFC (Near Field Communication) of course works up to around 10cm away, so this is the problem, it will ONLY talk to your phone, if you and your phone are stood in front of it, holding the phone against it.... Not exactly what we expected at all.
This seems to be common, as searching in the Google Play store at comments for the app, it's the same over and over again, pointless as you need to be in front of the machine, needs to be in front of the machine to work, can't see the point since you're stood in front of it you can SEE what it's doing.

So all in all, there seems to be a con when it comes to the wording. There are TWO products from Candy:
Smart Fi
Smart Fi+
See the subtle difference? The one with the + means WIFI equipped products, without the + it means NFC only.
I started searching and discovered that practically NO dryer (regardless of manufacturer) has WiFI equipped (Some heat pump dryers do, but they are almost 2-3 times the price and heat pump isn't a technology I wanted as seems very long drying times).

So the lesson of the day? Don't believe what they tell you (I should have learnt this by now), the "Smart" tech is STILL lacking in most appliances, despite it being such a simple thing to implement (I say simple, as I can buy a wifi equipped Arduino device for around £10 retail that could do exactly what I wanted if I could interface it to the appliance).

I'm unsure whether to raise this with AO.com as they aren't really doing anything wrong here, other than perhaps not clarifying some of the details on their product pages, we certainly don't think it's sufficient to return the product, especially as there isn't an alternative that would fit what we'd expected.
So for now I suspect we live with it, and potentially look into my retro-fitting of technology onto it, perhaps by using an Arduino and NFC board on the machine, see if I can read the NFC data it gives/do a handshake and get the information out of it, thereby converting it to a wifi enabled dryer!

Friday, 31 May 2019

Another cheap chinese Android phone adventure

Well, because I'm an idiot I've gone for another Chinese imported phone!
The reason? My last chinese phone has developed an annoying fault with it's USB charge port, seems the connector is damaged and only occasionally takes power and charges the phone, so it's no longer reliable.
So I decided to try another one.

I ordered this phone from China (via wish) as specs were high and it was worth a bit of a gamble. Stated specs/product:
Quote:
CPU: MTK6595 Octa Core
System: Android 9.1
ROM: 128GB
RAM: 6GB
Screen Type: 6.3 inch full
Touch Screen: Support Capacitive
Resolution:Front 800MA makes you more beautiful!
Network: 4G
Network mode: GSM/WCDMA
Network: Dual SIM Cards Support T Card
Camera typeual Rear Camera One Front Camera
Camera Pixel:
Front Camera:800 MP
Rear Camera: 16.0 MP
Software: Play Store, Air, Distance, Gesture, SmartWake,



And lots more impressive information.
The bits that made me look interested was 6Gb RAM and Android 9.1. Ignoring the usual Chinese rubbish about how good it was, and how it made me more beautiful I thought I'd try it. After shipping it was around 80UKP.




Arrival was within the stated time, but after starting to install apps and get used to the phone I found a few oddities. A few apps wouldn't install, saying not compatible with the phone, and it lagged at times quite badly for larger apps (facebook, whatsapp, etc).

I then thought I'd delve in deeper and see more info, checking the about page (and enabling developer mode) I saw the stats and a few bits didn't add up.
Android patch level seemed old for such a newly built kernel. Kernel was supposedly built April 2019.
So I fired up ADB and wow, I found some interesting facts!




The product listed itself as the P35_Pro product with an ID of LMY47I. The hardware is mt6580 which is an older Mediatek chipset.
Quote:
[ro.product.brand]: [Welcome]
[ro.product.cpu.abi2]: [armeabi]
[ro.product.cpu.abi]: [armeabi-v7a]
[ro.product.cpu.abilist32]: [armeabi-v7a,armeabi]
[ro.product.cpu.abilist64]: []
[ro.product.cpu.abilist]: [armeabi-v7a,armeabi]
[ro.product.device]: [P35_Pro]
[ro.product.locale.language]: [en]
[ro.product.locale.region]: [US]
[ro.product.manufacturer]: [alps]
[ro.product.model]: [P35 Pro]
[ro.product.name]: [P35_Pro]
And then the magic part, the android release, SDK and security_patch level:
Quote:
[ro.build.host]: [mht-15]
[ro.build.id]: [LMY47I]
[ro.build.product]: [P35_Pro]
[ro.build.tags]: [release-keys]
[ro.build.type]: [user]
[ro.build.user]: [android]
[ro.build.version.all_codenames]: [REL]
[ro.build.version.base_os]: []
[ro.build.version.codename]: [REL]
[ro.build.version.incremental]: [1555497787]
[ro.build.version.release]: [5.1]
[ro.build.version.sdk]: [22]
[ro.build.version.security_patch]: [2016-06-01]
So it's actually running Android 5.1 Lollipop with an SDK of 22, security patch from 2016! So nowhere near Android 9.1. So my guess is the about app in the phone is hard-coded to hide what's truly running.
Memory is also different to stated:
Quote:
Processor : ARMv7 Processor rev 3 (v7l)
processor : 0
BogoMIPS : 15.70
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 3

Processor : ARMv7 Processor rev 3 (v7l)
processor : 1
BogoMIPS : 15.70
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 3

Hardware : MT6580WP
Revision : 0000
Serial : 0000000000000000
shell@P35_Pro:/ $ cat /proc/meminfo
MemTotal: 2022700 kB
MemFree: 106920 kB
Buffers: 6436 kB
Cached: 599428 kB
SwapCached: 268 kB
Active: 912156 kB
Inactive: 588852 kB
Active(anon): 620728 kB
Inactive(anon): 276328 kB
Active(file): 291428 kB
Inactive(file): 312524 kB
Unevictable: 1424 kB
Mlocked: 4 kB
HighTotal: 1555456 kB
HighFree: 27680 kB
LowTotal: 467244 kB
LowFree: 79240 kB
SwapTotal: 163836 kB
SwapFree: 16 kB
Dirty: 40 kB
Writeback: 0 kB
AnonPages: 896404 kB
Mapped: 310784 kB
Shmem: 484 kB
Slab: 48328 kB
SReclaimable: 20672 kB
SUnreclaim: 27656 kB
KernelStack: 16976 kB
PageTables: 28424 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 1175184 kB
Committed_AS: 31332204 kB
VmallocTotal: 499712 kB
VmallocUsed: 102800 kB
VmallocChunk: 131012 kB
So only 2Gb of memory.



Now, I don't need a lecture about buying from Chinese sites/etc, I expected there to be problems, etc, but maybe not quite this level! I'm going to complain and see if I get anything, I doubt it. Otherwise it's a functioning phone, seems OK. I'll be watching it closely to see what else unusual I find with it.

(All images at: https://imgur.com/a/u1OZo4A)

Friday, 17 May 2019

gmail/google mail sending from Postfix

Here's a nasty little change that google/gmail sneaked in over the past couple of months in 2019, adding further authentication/authorisation checks for sending emails to anyone on a google hosted domain/gmail account.

The problem? Mails sent to google hosted/gmail accounts get bounced with a not very clear message:

relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c09::1b]:25, delay=0.62, delays=0.08/0/0.26/0.28, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[2a00:1450:400c:c09::1b] said: 550-5.7.1 This message does not have authentication information or fails to pass 550-5.7.1 authentication checks. To best protect our users from spam, the 550-5.7.1 message has been blocked. Please visit 550-5.7.1   https://support.google.com/mail/answer/81126#authentication for more 550 5.7.1 information.

So like a good user, you go to the url and lookup the address, which you're told all about bulk messages, mailing list best practices and pretty much it. It doesn't actually address the reasons specifically behind this error.
I suspect this is because it's a generic failure message that google are using, generally rejecting mail that they don't want to accept.

Now in this case, it's from an SMTP mail gateway/relay that several hundred people are behind it, this is a mail relay for an ISP connection, so the users behind it are of varying tech background, but are all on a known connection and various protection mechanisms are already in place to avoid spam and junk going over that connection. Therefore we believe the connection isn't generally junk/blacklisted. SORBS (urgh) and all the other mail checks show the server as clean and not listed, so WHY has google blocked/rejected mail?
Also to add to it. It's not all emails, just some get bounced like this. Send to the same recipient and sometimes it'll get through, sometimes it won't. No real recognition of why, different google gateways/IPs do the same. IPv4 or IPv6 just the same, so no real connection between which ones fail and which ones succeed.

The first thing to add was to create SPF records for the top-level mail relay server, and then get clients sending through it to add an include on their DNS records. This didn't appear to make any difference. Again some rejected some succeeded.
The only last option was to implement DKIM to the relay. This is kinda tricky as DKIM wasn't exactly designed for this scenario. Multiple sending domains, IPs, etc, all going via one mail relay. So the mail relay would need to add the DKIM signature based on it's own signing regardless of who sent it (Since we authenticate/verify senders via the server, we KNOW when an email is accepted to be relayed that it's legit).

To implement, first we have the current setup:
Postfix accepting on 25 for relaying mail out.
Multiple domains/IPs sending via Postfix, we don't KNOW all domains/IPs sending through us.
Debian/Ubuntu standard Postfix install/setup for mail relaying.


The first parts are standard installation steps for DKIM:
apt-get install opendkim opendkim-tools
Then you need to configure the base opendkim package:
/etc/opendkim.conf
/etc/default/opendkim

Configuration here is pretty basic, the key parts you need though are:
/etc/opendkim.conf:
Syslog                  yes
SyslogSuccess yes

LogWhy yes
Canonicalization        relaxed/simple
Mode                    s
SubDomains              yes
KeyTable        /etc/postfix/dkim_key_table
SigningTable    refile:/etc/postfix/dkim_signing_table
ExternalIgnoreList      refile:/etc/postfix/opendkim-TrustedHosts
InternalHosts   refile:/etc/postfix/opendkim-TrustedHosts

So the above sets Syslog to log success and failure reasons. We set Canonicalization to relaxed/Simple as this relaxes the signing. Mode is set to sign and not verify (We only relay outbound via this server, we don't want to check mail coming in for DKIM signatures/validation).
Then the Keytable, SigningTable, ExternalIgnoreList and InternalHosts contain the main parts to allow us to sign any mails going through.

/etc/postfix/dkim_key_table:
mail  serverrelay.mydomain.com:mail:/etc/postfix/dkim.key
Set "mail" as our signing name (keep it consistent throughout), define our servers name "serverrelay.mydomain.com" is our FQDN for our sending server. Again set our signing name and the path to our key.
(We'll generate the dkim.key file in a moment)

/etc/postfix/dkim_signing_table:
*  mail
This sets the domain/entries we want to sign, so the * means anything/all and again "mail" is our signing name setup above.

/etc/postfix/opendkim-TrustedHosts:
127.0.0.1
0.0.0.0/0
This defines what IPs are "trusted", i.e. allowed to be DKIM signed by us. In our instance we've set this to localhost and then to anything. This means that anything postfix is allowed to relay is allowed to be DKIM signed too. (Here we are assuming trust from postfix not being an open relay)

/etc/postfix/opendkim-TrustedHosts:
^^^ points to the above file as it's the same thing.

/etc/default/opendkim
Edit this and set the SOCKET to listen locally, by setting:
SOCKET="inet:8891@localhost"

As we want to use this to simplify our link into postfix (Since postfix is generally chroot'ed and using unix sockets/paths can get complex), easiest to use a tcp listen port.

Now we generate our signature:

cd /etc/postfix;opendkim-genkey -t -s mail -d serverrelay.mydomain.com

As above, "mail" is our signing name and our fqdn is at the end. This generates the files mail.private and mail.txt in the "current" directory, hence changing to /etc/postfix first. Then copy the files to be the ones you defined above in the config:
cp /etc/postfix/mail.private /etc/postfix/dkim.key
The /etc/postfix/mail.txt contains the DNS record you'll need to add to your DNS. So ours generated:

mail._domainkey IN TXT "v=DKIM1; k=rsa; t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKjCZppULxQyiblah+blah+blah" ; ----- DKIM key mail for serverrelay.mydomain.com

So create that in your DNS. I created it under the subdomain "serverrelay.mydomain.com" and the TLD "mydomain.com" to be sure.

Restart opendkim (service opendkim restart) and check it's running and listening on port 8891.
Then we can integrate into postfix:

milter_protocol = 2
milter_default_action = accept
milter_connect_macros = j {daemon_name} v {if_name} _
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = $smtpd_milters

Add this to your /etc/postfix/main.cf to incorporate the milter/opendkim into your install. If you already have other milters then append the inet line onto the end.
Restart postfix and then watch the mail logs for the opendkim signing taking place.

You should see:

May 17 10:48:59 serverrelay opendkim[24500]: 2A9823C156C: DKIM-Signature header added (s=mail, d=serverrelay.mydomain.com)

For each email sent through the server.

Good luck and hopefully that has helped you out! This was a combination of information I gleaned from several sources as none seemed to join all the parts together for this particular mail relaying scenario.

Monday, 15 October 2018

Junkendriven - New car related content only on Youtube

My new series is coming to Youtube shortly, named #junkendriven

Don't miss out, subscribe to my youtube channel https://www.youtube.com/andybrown21/ and be ready for the new series to start soon!


Tuesday, 11 September 2018

UniFi APs and time scheduling

UniFi has been my choice for WIFI access points for a while, I've put quite a few in now in large and small installations. The smallest being at home where I have two APs.
One in the house and one in the garage to cover the drive, garden, etc. They work pretty well and I get good coverage generally. I've gone with setting them both to the same channel for the same SSID. In some ways this is frowned upon as you get overlap and arguing over channels, but I find it works really well and some of my older devices quite happily shift between access points.
They're the older 11N/B/G units so nothing amazing, but for home use pretty good.



The biggest problem I have is their configuration. UniFi APs have no way of configuring them directly, they require the "UniFi controller" which is a java (Urgh... Really... Urgh) web control panel that drives it all. The panel is actually pretty good, shows client connections, signal strength, number of APs, nearby channels, lets you control guest access, etc. Here is where UniFi is nice and "just works", you can setup guest wifi hotspots, with doorway pages, terms to agree to, or just limit how long people can spend on the AP. You can also set wifi access times (Times of the day/week that the Wifi SSID is broadcast/available), block/permit MAC addresses, use VLANs and other clever parts that are all just built in.
As mentioned before, the issue is their configuration. Their method of the APs being remote to the controller means after making most changes to the controller the APs have to re-provision to then take the new configuration. This re-provision causes them to STOP traffic/drop the SSID's, update and then come back online. This is a major headache as means after each change your entire wireless network drops, configures then comes back. Not really good for production use that! There isn't a clear indicator as to what changes cause a wifi drop either, so you're sometimes left guessing whether wifi will drop or not.

WiFi access times - This is a feature I really wanted, it'd allow me to control my guest and kids wifi network, whilst leaving my own alone.

Here you can see it setup to only allow access 8am-6pm 7 days a week. Firstly, you'll see you can't have multiple schedules per day, only one ON and OFF per day.
There was another issue with this, if you want to make a one-off quick change to the schedule you can't really, you have to modify the time or disable/enable WLAN schedule (WARNING: If you disable it, when you go back to re-enable it, the times are all reset back to defaults). So this doesn't give you the option for dynamic changes to add time if needed, etc.

At present this feature has been continuously requested from Unifi but no success. I've therefore been looking for alternatives, and at the moment have only a partial fix to this.
There is a PHP class that provides access to the UniFi controller through scripts (https://github.com/Art-of-WiFi/UniFi-API-client) that I've used for a quick script that allows me to switch on and off the relevant SSID's on demand.
The problem is that this makes a change to the controller, and so in turn all the APs go back through provisioning and cause all wifi clients to drop!

No solution to that at the moment, so I'm open to suggestions, even if that might be to move to an alternative wifi product (Microtik maybe?).

Thursday, 9 August 2018

Xgody D24 and the nasty background app

As my previous blog posting mentioned, I decided to get a cheap (less than £100) android phone from ebay, it's a chinese import and it's the Xgody D24 Pro. It's a really nice phone and I'm liking it, it's fast enough, designed well and other than poor battery life has been great.

That is until around 2 weeks of ownership and then it seems to cause problems. It gets really hot at the back top (I'm assuming where the CPU is), battery life starts to suffer and then it starts switching wifi OFF.
This was the biggest pain for me, as switching to my limited 4G data service wasn't ideal, so why was it switching wifi OFF. Annoyingly searching Android and permissions it seems the ability to turn wifi on and off is not a system/secured function and so pretty much any app can do this. I wanted to see if I could spot the app doing it so started to use adb to debug and view the logs from the phone. This is trival on most Android devices. Get into debug mode by going to about the phone and clicking 7 times on BUILD NUMBER, and you get the developer options. Enable USB debugging and you can then start using adb shell, logcat and others. This is good as we can now see debug output from the phone and get a shell.
Unfortunately root doesn't seem an option at the moment as none of the traditional Mediatek methods of rooting work so far, so I'm still hunting for this.

Anyway, back to debugging and nothing showed the wifi getting switched off, other than the android system messages showing the wifi trigger to switch off had occurred. So this didn't give me anything useful unfortunately. So I then wondered what the phone was doing, why did it want to switch wifi off, and why did it hate my wifi so much! It's not my WIFI as loads of other devices in the house were happy, so to me the phone was deciding to switch it off and move to 4G.
I therefore started to capture what traffic the phone was doing, and in doing so got quite alarmed. I did this firstly by just capturing what DNS queries were being made, I run my own caching dns at home as I then filter out known dodgy websites, adverts, etc, so this was my biggest thought. Some app on my phone didn't like that I was stopping their ad revenue and circumventing my block! So looking at the DNS queries should help, here is a small extract:

08-Aug-2018 18:17:36.176 client -redacted-#37694 (ajax.googleapis.com): view internal-view: query: ajax.googleapis.com IN A + -redacted-
08-Aug-2018 18:17:36.245 client -redacted-#46380 (ajax.googleapis.com): view internal-view: query: ajax.googleapis.com IN A +T -redacted-
08-Aug-2018 18:17:54.151 client -redacted-#61674 (edge-mqtt.facebook.com): view internal-view: query: edge-mqtt.facebook.com IN A + -redacted-
08-Aug-2018 18:17:54.198 client -redacted-#41326 (edge-mqtt.facebook.com): view internal-view: query: edge-mqtt.facebook.com IN A + -redacted-
08-Aug-2018 18:18:05.719 client -redacted-#41059 (ad.gadmobe.com): view internal-view: query: ad.gadmobe.com IN A + -redacted-
08-Aug-2018 18:18:06.490 client -redacted-#47730 (www.kaka-games.com): view internal-view: query: www.kaka-games.com IN A + -redacted-
08-Aug-2018 18:18:07.553 client -redacted-#62811 (www.serving.d6f887.bid): view internal-view: query: www.serving.d6f887.bid IN A + -redacted-
08-Aug-2018 18:18:58.558 client -redacted-#37185 (trcklead.justmob.mobi): view internal-view: query: trcklead.justmob.mobi IN A + -redacted-
08-Aug-2018 18:18:58.660 client -redacted-#39907 (gameofads.com): view internal-view: query: gameofads.com IN A + -redacted-
08-Aug-2018 18:18:58.963 client -redacted-#40249 (www.wathspap.com): view internal-view: query: www.wathspap.com IN A + -redacted-
08-Aug-2018 18:18:59.497 client -redacted-#44690 (tango-deg.com): view internal-view: query: tango-deg.com IN A + -redacted-
08-Aug-2018 18:20:01.643 client -redacted-#53189 (track.miadx.net): view internal-view: query: track.miadx.net IN A + -redacted-
08-Aug-2018 18:20:02.847 client -redacted-#42812 (traffic.tc-clicks.com): view internal-view: query: traffic.tc-clicks.com IN A + -redacted-
08-Aug-2018 18:20:03.019 client -redacted-#34487 (mediaxds.fuse-ad.com): view internal-view: query: mediaxds.fuse-ad.com IN A + -redacted-
08-Aug-2018 18:20:03.198 client -redacted-#55749 (a1152.secureleadstrack.com): view internal-view: query: a1152.secureleadstrack.com IN A + -redacted-

So these weren't great, but I can see how they were working, tracking on various software, phone-home stuff, click trackers. Not things I like seeing, but I can kind of see why, there are some googleapis in there, some facebook stuff, so unsurprising.
But then the ones that worried me came along:
08-Aug-2018 18:20:53.374 client -redacted-#11447 (t1.contentfall.com): view internal-view: query: t1.contentfall.com IN A + -redacted-
08-Aug-2018 18:20:53.599 client -redacted-#4099 (t1.trackingfall.com): view internal-view: query: t1.trackingfall.com IN A + -redacted-
08-Aug-2018 18:20:53.829 client -redacted-#21446 (mobi.neweives.com): view internal-view: query: mobi.neweives.com IN A + -redacted-
08-Aug-2018 18:20:54.132 client -redacted-#23448 (smartoffer.site): view internal-view: query: smartoffer.site IN A + -redacted-
08-Aug-2018 18:20:54.517 client -redacted-#26753 (cdn.identies.com): view internal-view: query: cdn.identies.com IN A + -redacted-
08-Aug-2018 18:20:54.789 client -redacted-#27880 (identies.com): view internal-view: query: identies.com IN A + -redacted-
08-Aug-2018 18:20:55.167 client -redacted-#18179 (ws021.coinhive.com): view internal-view: query: ws021.coinhive.com IN A + -redacted-

The last one was the one I was concerned about. What was coinhive? Cryptomining was the answer that google provided, and it was a method of embedding mining into websites, apps, in fact almost anywhere you could hide one. This was starting to sound a bit suspicious, why would my phone be mining? Well it's obvious when you stop and think.
Cheap phone, potentially cheaper than cost of manufacture, how do you subsidise the cost? Get it to click on banner ads, and mine cryptocurrencies when the user isn't using it! At least that's my guess. So now I have an idea what's going on, the phone is doing this in the background and of course needs to phone home to upload it's progress, completion, etc. Well my DNS at home is blocking this (sending it to loopback) so it can't do that, so next option? Try to switch to 4G and go that way.

This would also account for the hot CPU, as cryptomining uses CPU cycles to do the work, so that is also contributing to the battery running down so fast and as mentioned the heat generated. So now finding it should be straight forward, just wait for the thing to get hot and look at what process is using the CPU. It didn't take long to find it:

User 95%, System 3%, IOW 0%, IRQ 0%
User 796 + Nice 0 + Sys 29 + Idle 12 + IOW 0 + IRQ 0 + SIRQ 0 = 837

  PID USER     PR  NI CPU% S  #THR     VSS     RSS PCY Name
 5515 system   16  -4  91% S    93 1300280K 190604K  bg com.mediatek.factorymode
  834 system   20   0   3% S   114 1253876K 118232K  fg system_server
 6170 shell    20   0   1% R     1  12588K   1596K  fg top


Here you can see the CPU is at 95% use (the phone was sat with screen off, idling here) and the process at the top was a strange background process "bg com.mediatek.factorymode". Which is again odd as the phone wasn't in "factory mode" or anything like that, it was in normal operation. So that was the suspect. Occasionally when I unlock the phone that process went away (I'm guessing it lowered its cpu use accordingly) and then when idle again popped straight back up. So this one I think is the problem.

It's stored into the heart of the factory ROM, as I did a factory reset and this didn't remove it. The APK is stored at /system/vendor/framework/mediatek-res/mediatek-res.apk (SEE NOTE BELOW, I REALISE THIS IS WRONG!)
However without root, I'm struggling to stop it from running. Ideally with root you'd stop the apk from being called at boot time and that would stop it in it's tracks, but without root this gets tricky.

Luckily I've found what is currently (as I type) working, and so far the app hasn't restarted itself. I'm unsure if it will and how it is called, so only time will tell.
I've used the Android developer tools themselves to help here.
Go into Settings and Developer options. Down to "Running services" and click "Show cached processes" to see as much as you can. I then went down the list and found:
"FactoryTest" showing 1 process and 1 service.
Clicking it shows a service called "Vmaezz" which is a bit unknown so I hit STOP on it.
I then had to also find "FactoryMode" when showing cached services and you can hit STOP on that too. When I did that, the process went away.

So what you look for is:

system    10762 345   1146172 155852 futex_wait 00000000 S com.mediatek.factorymode

And once I stopped those processes that went away. Whilst that app isn't running, the wifi didn't switch off and the cpu idled away at pretty low values.

The problem? What causes the app to run, there is probably another app somewhere that calls it, or schedules it to run, so no doubt it'll be back, so I really need to get onto the bigger challenge and find out how to root and kill this app.

In the meantime, I'm going to extract and try to reverse engineer mediatek-res.apk to discover what I can about it and see if I can spot the triggers, etc.



NOTE1:
Wherever you saw me referring to mediatek-res.apk please note this is WRONG information! Don't break mediatek-res.apk as you'll get a bootloop which is evil on these no-name chinese phones!

I did further discovery and found the key apk:
/system/priv-app/FactoryMode/FactoryMode.apk

So that was the one to focus on.

I went ahead and used an online analyser of the APK to see what it said:



Two interesting things appeared here in the services section. The first is that it had a wifistatelistener, so that makes me think it could check wifi. Second is the Vmaezz class which was the one I killed in android developers, so that does indicate that's the main process/class that's running this. Curiously this didn't report the app as malicious, but it depends on what this scanner was looking for.

As of now, I killed the app around 20 minutes ago and it's not come back yet, and wifi has remained on, so hopefully this is the "solution" for now until I can dig further into it and extract the code from the apk.

To try and get into the code, I've found that the .apk is a compile-at-boot type, so that produces an .odex file. In combination with the devices own "boot.oat" I then extracted the DEX and from that the majority of sourcecode. Viewing it with jadx-gui shows something interesting:


What looks like the factory (Mediatek factorymode) code is at the top with the normal attribute names and definitions.
There is then an unusual one added below, so almost like a second program hiding within the first. This second program:
 com.p005a.p006y.kv
I'd guess is what we want to investigate, so opening some of the source up reveals:


Sure enough, there is our vmaezz code that we keep killing off.

I now started looking through the code for what looked to be interesting code. I found quite a few things, udplistener events, trigger and http download events, and this one which watches the network changes taking place:

So this lets the app recognise when a wifi state change happens, so this looks potential as if it watches for this change perhaps it also influences it.
Couple that with the handler:


I think we can see that it likes to watch and take action on changes to this state.

I've also discovered from adb I can stop the application "automatically" by calling
adb shell am force-stop com.mediatek.factorymode
So as a short-term solution I've written a small shell script:
#!/system/bin/sh

while [ /system/bin/true ]; do
/system/bin/am force-stop com.mediatek.factorymode
sleep 1
done

Uploaded it to /data/local/tmp and set executable. Then ran it with & to background it. It appears to stay running and does kill the process before it finishes starting. It's not very elegant but it'll work for now.

Slowly, I'll figure out how to kill this thing off!

--UPDATE-- 13/08/2018
I've found that the script above is working great, killing the process off the moment it tries to start (It works in my favour that it takes a few seconds to start up fully as it has to de-odex itself). So my shell killer is working. However battery life has reduced, I'm guessing because my shell script isn't letting the phone go to sleep.
I'd also installed Blokada which is an interesting blocking method for non-rooted phones. It creates a local VPN (to itself) and then blocks known ad networks, etc. It seems to be working REALLY well, and added to the previous fixes seems good. I'm not sure if this is also eating my battery, but it seems worth it.

I've just improved on my shell script killer:

#!/system/bin/sh
while [ /system/bin/true ]; do
if /system/bin/pgrep "com.mediatek.factorymode" >/dev/null
then
/system/bin/am force-stop com.mediatek.factorymode
else
echo "Not running"
fi
sleep 10
done
I'm not sure how long I can push the sleep timer to, so might experiment further on this.

--UPDATE2--
I've had Xgody reply to my queries, I'd opened discussion on them over the process using 100% CPU and if there was an updated ROM/firmware. They've flatly said there is no ability to update the ROM at all, but have now offered a partial refund of the cost of the phone which is an odd offer. I'm probably not going to take them up on this though.
 

Friday, 13 July 2018

Xgody D24_Pro android 4g phone

My latest "basic" phone is the Xgody D24_Pro, which runs android 7.0 (Kernel 3.18.35) with baseband MOLY.LR9.W1444


(PS the photos are stock ones, as it's difficult to take a photo of it, using itself as that's the only decent camera-phone I currently own!)

This phone was purchased for under £100 as a temporary phone due to another phone being on order as I need something that did 4G and run latest android apps. It was bought from an ebay seller who seemed to be the Chinese importer of these, so as usual registered address was in China, but it's some UK shipping address, so it arrived after 2 days and it looks really good!
The outside on mine was a blue metallic on the rear, and a lightly curved full front screen without bezel.
It comes with the usual cheap power usb charger (1amp), charge lead, rubber casing and screen protector. This edition has the removable back revealing the battery, two sim card slots and memory card slot.. Taking the protective tape off the battery and connecting it to charge it showed a worrying 1% initial charge so I left it for 24hrs on charge to let it fill up and go happy.
Powering it on, it's the usual android thing, setup, add google play credentials, go online, etc, and it was working great, really fast going through the setup and no apparent issues.

The screen was very clear, if anything a little too bright/high brightness and the automatic brightness control seems to always prefer to be brighter than what I'm used to, but that's probably my preference.
The phone boasts a fingerprint sensor on the back, headphone slot and usual high-def screen. Inside it's got a quad-core processor at 1.3Ghz and a decent 2Gb of RAM along with internal 16Gb storage for the o/s, apps, etc. I always put an SD-card in for photos and all the other stuff.
Cameras aren't bad, rear 13MP is decent, if a little sluggish at waking up and focusing (processor?) and at first I was worried as the previewed photos looked poor quality, but after looking at them on a laptop they are really good. You also can use the UHD mode for really fine-grain detail. Front camera is 8MP which should do my snapchats decently (one for the kids there!).



The battery looks like it's the weak point, specs show only 2400mAh and I've started to notice that I don't get a full day's use out of it so ending up by around 5/6pm down to 30%, so I then pop it on charge again. It's also not equipped to use fast charge, so pulls current at around 0.8amps on charge, so full charge is around 2hrs something like that, which isn't too bad.

The buttons keep catching me out, but I think that's just because of what I'm used to.
On the side are (from top to bottom) volume up, volume down and power. I've always preferred power on the top, but that's from HTC phones! You can also wake it up by putting your fingerprint on the fingerprint reader which is nifty and works pretty accurately I've found.

Downsides:

  • Battery life/capacity/charging
  • No NFC (no android pay, etc)
  • charge port is at the top
  • Screen a little too high brightness (slightly whited out)
  • Camera slow to react
Upsides:
  • Price (Less than £100 for a VERY good android smartphone)
  • Fast - Processor and memory work well so keep android flying along despite all my apps
  • screen - slightly curved and really clear
  • weight - not too heavy at all, similar to most others
  • Camera - good front and rear cameras that take good photos
  • Android - 7 installed (updated Jan2018) and with NO bloatware installed, just raw android pretty much so it's very sleek
  • Good looking - I like the electric blue casing
  • Fingerprint - for unlock and in apps that support fingerprint unlock.
  • Removable battery - I always like the ability to remove the battery in case of problems, and in theory you can replace it (Not sure how easy that is with Xgody not being a popular/known brand)
So all in all, I'm really impressed with my "cheap" android phone buy!

Update: After a week, and it's still working great, battery life I've learned to live with, charger plugged in and it's fine. The screen is a little brighter than I'd like (Perhaps causing the poor battery) but running it almost constantly on lowest brightness seems fine in all conditions I've tried so far.
Fingerprint unlock is proving really good, I use that all the time now.

Saturday, 7 July 2018

Smart Watch - Bakeey HB08S

I've done it again, I've looked at smart watches, and again got confused and surprised by the range and prices they go for. Sure, you can spend several hundred pounds on a smart watch that looks amazing and does all sorts, but generally I'm not a watch wearer, I don't use it as a fashion statement, so my main requirements:

  • Alerts me of messages/chats on my watch and lets me see the contents/partial info
  • Easily adjustable for my tiny/thin wrists
  • Comfortable, not square and unweildy
  • Extra functions of stepcounter, heart-rate, etc, a nicety
  • Actually shows the time
  • Battery life longer than a couple of days
So not the biggest range of requirements, but enough to discount a lot of the cheaper brands that are in the low £10-30 it seems.
This is the one I've ended up with, the Bakeey HB08S which should normally cost £40 (In this case I got it free, as a free gift so non-sponsored item!).

The first thing that stands out is the strap, it's really quite impressive and I'd never seen this type before. It's a sort of chain-main strap, BUT with a twist, it uses a strong magnet to fasten, so simply slip it round to the right place and let the magnet catch any part of the strap. That's great for me, as no fixed fastening holes or positions, so you can get the comfort level just right, and let's you adjust it constantly, so for a non-watch wearer like me, getting used to it is easier.

Next is the watch face, it's not huge, it's rounded and actually looks OK. When the screen is on you can see the simplicity of it though, the screen is square and just goes into a round bezel, but it's clear and shows the info you need.


I prefer the first two options for display, I was a little disappointed there was no "classic" watch display graphic, but these do work and give you a few good bits of info just when the screen turns on:
  • Time and date (month-day fixed format)
  • Heart rate at last sample
  • Stepcount
  • Bluetooth status (not too reliable, or I kept reading it wrong!)

Next up is battery life. AMAZING, it lasted me for 5 days before needing a charge on my first test run (Which admittedly was without being paired to a phone), but so far whilst paired to a phone it's made it two days and battery still shows 90+% so that's good. Also the battery level indicator works well, full is 4 bars and they go down slowly, no sudden drops/jumps. That also takes me onto the charger. It's a nice neat little 'rest' charger, just place the watch onto it (you see the contact pins on it) and it charges, so far it's always just sat right on it and didn't move off, so again, really easy for charging.

The alert reminder goes with the app itself you install "iband" and out of most of the chinese applications, this one works really well! Setting it up and connecting to the watch was quick, and all the settings in the app seem to work without a crash or problems.
   

You can set how it wakes up (I set it when I turn my wrist, and it's surprisingly good at detecting when you lift your wrist and look at the screen!), medium brightness (It's fixed, so in bright light it can be difficult to see) and the various notifications so I get alerts based on txt messages, whatsapp, etc. You can't add all notifications to be alerted to, which is a shame, but they include the main ones.
The alerts are pretty clear, when you get a TXT message the watch vibrates and shows you the first 6 characters of the name of person sending and a letter icon. You then touch the watch to see the contents of the message, and it will scroll through each page of the message, which is really impressive! The text is very blocky, not very elegant, but it works well.

It's difficult to comment on the step count and heart rate as don't have a good frame of reference, but the step count does seem reasonably accurate based on me counting my steps and seeing how it increases on the watch, so it seems close enough for what I'd want! The sync back to the phone is regular and shows steps, activity, sleep cycles, heart rate over monitored period (It does periodic checks), blood pressure (Unsure on this one!) and the last one, SP02 in percent (No idea!).

So in summary, I'm liking the watch, it's not stylish or particularly clever but it does the job really well and compared to a lot of the Chinese "smart" watches I think this one is really impressive.

One problem: I'm not sure how, but I managed to crack the plastic casing of it, which meant the front watch face was starting to come off. Taking a peak inside I could see the battery li-ion package is glued to the base and the screen with the circuit is attached to the face, so if you do prise it apart, you need to disconnect the thin ribbon that joins the two before you lift the screen too far. Prising it from the bottom of the face looks the best option! I used a few dots of superglue to put it back together, hopefully it will hold.


Saturday, 9 June 2018

Draytek router hacks and odd DNS

This is quite a common thing when you work in IT, you hear about exploits, hacks and malware doing the rounds. In fact you get slightly immune to it over the years, you hear so much about it, so many hacks and general attacks going on you start to ignore it all as noise. Risky? Yes, but unfortunately part of the territory.

Well, I'm in such a situation, I've seen so many releases about exploits or denial of service to Cisco, HP, Windows, Linux, Android and various hardware that I now don't often read them or if I do it's glancing due to workload and lack of time! So it had to be the case I'd be bitten by that lack of attention.
In this particular case it's due to a Draytek exploit, but I didn't know that at first. The issue? My HIVE home heating system wasn't connecting to the outside world, so I couldn't control my heating/hot water remotely!
Not exactly earth shattering, but being a techie I had to figure it out. So I started looking at the units (rebooted them all, obviously!), checking why they couldn't talk, and nothing seemed right, they looked fine, I could see them on my local network.

So I went to plan-B, change the gateway of the hive hub in my house to my server IP and then sniff the traffic it was sending and receiving to see if that gave any clues.
After changing the gateway for the device in my DHCP server and restarting the service, I watched the logs to see the hive unit get a new IP to confirm it had moved.
I then started to see something odd, complaints about NAK and an alternative DHCP server giving replies. I checked the IP and it was my Draytek router.



Now on my network, the draytek router does very little, it does FTTC to Ethernet conversion, does the PPP auth and then sends all the raw public stuff to my server. So why it would be handling DHCP is an odd question.
A while back when having DSL issues I did temporarily use it for DHCP whilst BT checked out problems, but I was sure it was set back!
So checking the web interface for the Draytek it revealed it DID have DHCP enabled, and then I spotted an odd DHCP DNS server address.
38.134.121.95
What is that address, not one I recognised. The secondary was my normal secondary DNS but that primary was odd.

I simply switched DHCP off to let my server do the work, suddenly the HIVE started to work. So it looks like it was that DNS entry to blame. I decided to search for it and then all the security advisories came up! I've pasted a couple here for info:

https://www.bleepingcomputer.com/news/security/draytek-router-zero-day-under-attack/
https://www.draytek.co.uk/support/security-advisories/kb-advisory-csrf-and-dns-dhcp-web-attacks
https://www.ispreview.co.uk/index.php/2018/05/dns-vulnerability-strikes-popular-draytek-broadband-isp-routers.html

Not good, so it appears somebody had hacked my router, switched DHCP back on and set this rogue DNS server. But it's an odd thing to do. You can glean a certain amount of information from this hack, you can see what websites are being visited, and you can do a redirect to try and grab sensitive information.
For example, say our rogue server gave out their OWN IP address for something like your banks website, presented a fake banking website and got you to enter your details.
Now think of this on a larger scale, they'd only be able to re-create SOME banking websites, SOME online account websites on their hack servers, so it's quite a limited attack depending on what they're targeting and trying to achieve.

Now I suspect I've been lucky here, being in the UK there are fewer websites I suspect the attackers will have re-created or redirected. I'm also curious what their aim was, but nobody seems to know much about it.
The IP is innocent enough, hosting webspace in the USA, so I suspect it will have been shutdown quite some time ago, and checking DNS queries today to it fail, so looks like it's been stopped. But even so, that's odd, and how long was it sniffing my traffic?

My guess is it's been a couple of weeks for me. That's when I had "odd" behaviour, the HIVE hub stopped connecting, etc.

The answer? PATCH, I went to Draytek and updated my firmware, which is something we all have to start getting used to. Keep updating, keep patching, etc.
What a chore! Maybe there is a better way, but for now we have to be aware, and watch for this sort of thing and not let it wash over us!

Saturday, 19 May 2018

Cheap car radio antenna

For a while my car radio reception has been pretty poor. I suspect it's a poor ground somewhere on the aerial, the aerial itself is a loop in one of the rear windows, so all sorts of problems are potentially there. Also with it being a large car, the wiring run will be long too which won't help.

So rather than fix the problem (!) I decided to look for alternatives, as I know you can buy cheap antennas that fix to windscreens, hidden away, etc, and have an amplifier in it too.
So I trawled various websites and there is very little on reviews on what is good and bad! So I decided to take a look and take a chance on a cheaper powered unit.

This was what I thought I'd try, as it was cheap but still had powered circuitry in it and from a UK seller.

It arrived quickly which was good, so I fitted it into the car. It arrived looking like this:

Two wires marked red and black were for 12v power to it, then it had the standard round connector for antenna into the radio.
I wired it up, and placed it on top of the dashboard, powered on.

Signal was TERRIBLE, really bad. To be honest a bit of wire was probably about the same quality. I'm not sure why it was so pathetic, but it really wasn't working at all.
I checked connections, power, etc, to be sure but no it just was a pile of junk.

So after removing it and swapping back I thought I'd take a look inside the boxes. To my surprise there was actually electronics in there (I was half expecting an empty box!)


I'm going to take a look a the components and circuit as I'm not sure exactly what it's doing. From what I can see there are a few resistors and a couple of either gates or diodes on there, so i'm going to try and figure the circuit out and see what it was trying to do!

The other end looked pretty unremarkable:



I should have known better really!

Sunday, 29 April 2018

Fitting an Android head unit into a Vauxhall Corsa D (2011)

This came about when I tried to fit an aftermarket stereo into my Wife's Vauxhall Corsa (An Xtrons, see the blog post here http://www.thebmwz3.co.uk/2018/02/xtrons-3-single-din-car-radio.html ).



However after just a short amount of use it turned out to be a really poorly made unit, and so I was looking for an alternative to fit that wouldn't cost much. Luckily a friend at work was selling his old android double-din head unit so I bought that off him.

It's a typical cloned android head unit, but had the advantage of having various physical buttons, and I knew it to work well from my friend at work, so I bought it, not really thinking it through. Got it home and take a look at the size:


Here you can see the xtrons unit still in, with it's plastic surround and the new unit. You'll notice the Vauxhall panel is tapered at either side, so it isn't a straight rectangular fit, so this may prove difficult!

First steps were to remove the old xtrons unit, this just clips in so just pull it out and the bracket came with it. Disconnected all the power and audio connections from it so we've got it free (Apart from the power cables which were wired in, due to the Vauxhall radio connector not having an ignition power wire, more on that later).

So now I got the chance to see what the fit might start to look like:


So it did start to fit in the hole, but this was as far as it went at first. On each side of the head unit there were the mounting brackets with clips, luckily these were just screwed into place, so removing those and the unit slid all the way back:



Not exactly a perfect fit though, and so make it fit flush would mean taking the Dremel to the dashboard. I had considered this, since it's something I've done in my Chrysler, however in this case that plastic bezel around it is actually almost the entire lower section of dashboard, so to replace would mean replacing almost the whole plastic dashboard trim, not something I wanted to pay out for, nor do should I want to return it to factory for when it gets sold.

Therefore I thought we'd just live with it not being flush, and work to mounting it as securely as possible. In this case the only solution would be either from the top or bottom of the radio. Luckily there were a few screw holes in the top of the unit, so these would act as our securing points.

So to get to the top of the radio, above the radio is the air vent, door lock and passenger air-bag cancel button unit (in silver on this edition), so this needed to come off.

***WARNING : Before you do this DISCONNECT the battery. I didn't and when you disconnect the airbag disable button it triggers the airbag warning system which needs an SRS code reader/reset to remove!***

** EXTRA NOTE - After almost 2 months the airbag light has gone out of it's own accord, so it does reset, it just takes a VERY long time **


To remove this panel the first thing you do is remove the small speaker grill from the top (This has the lump that looks like an alarm sensor), that pops out using a thin screwdriver. Once out you'll see a single hex screw. Once that's undone you gently prise and pop the clock display piece out. You'll see from the photo above the clock display is separate to the silver vent housing, so that clips out (It folds upwards towards the windscreen). The clock has a clip connector behind it, so does the speaker. The speaker is a pop/plug connector that just pulls out. The clock connector has a mini lever on it you press and turn to disconnect.

Once that's out you can then remove the further 3 hex screws which hold the air vent unit in, this again is clipped in at either side of the vents and then with two clips downwards towards the radio position. This whole unit then comes out, again the connector at the back for the airbag, etc, is a mini lever that once you release the clip on it, turning the lever will disconnect it and let you remove it. REMEMBER: DISCONNECT BATTERY FIRST!
You can see the connector in the middle of this photo:


That's the unit removed, so now we have the plastic surround that the radio sits against (It's the piece with the connector sitting on it, so that's the top of our radio mount). In this case I thought the easiest was to drill two small holes into this, and then use a screw through this plastic piece and into the radio to hold it in place.



Once the screws were in and tested I turned to the wiring. Luckily the connector Vauxhall uses is almost identical to the one used by Ford, so this was just a clip in plug.

The above is similar to what I used, you need the antenna power/can unit for the Vauxhall Corsa. Clipping the main block into the factory car connector was easy, however as I found before, there is NO ignition switched power on this factory connector (It uses the CANBUS car network to control it), therefore the alternative wire I'd put in from elsewhere was needed again. This was a separate wire I put in that provided power from the ignition, and so would control the radio on/off, etc. So I cut the wires that went to the connector and wired these into my ignition. Wired in the power to the antenna amplifier block (the silver can), and added the rear reversing camera connections to it (Already fitted a while ago). Turned the ignition on and it all powered up perfectly! Audio was good, and actually really loud for the car, using only 4/5 volume setting and it was perfect.

To fit it back in I fastened the two screws in place that holds the radio in, then refitted the silver fascia and then the top clock/plastic. Something else I found, the silver fascia was a difficult fit back in, due to the radio being slightly larger, so potentially this might not fit properly in future, will keep an eye on it and see if it pops back out!
There is also the heater/blower vents at the back which are soft plastic, make sure you check at the back and line them up as they can easily be squashed when you push the fascia back in if it's not fully lined up.

However, not a bad piece of work and the results are pretty good, even though it sticks out a bit!






Tuesday, 24 April 2018

Daylight running LEDs (DRL) and indicator signals on Chrysler

This is a short post on fitting daylight running LEDs to my Chrysler Grand Voyager 2.8CRD. This should work with most editions of the GV, I'd expect right up to the newer facelift editions, so right through to 2007/2008 I believe.

So the first step is ordering the right DRLs, I went for ones that have DRL and indicator function built in, as some information suggests when indicators are on the DRL should switch off to avoid confusion to oncoming drivers, I also like this 'look' where the DRL goes off, the indicator flashes and when indicators are cancelled then the DRL will come back on. This needs units with a little electronics but you can buy these for around £10 easily in the UK. I went for the longer 60cm lights, and went with the light 'bar' type where the LEDs are inside a plastic diffuser to give a more even illumination.
The next job was how to connect into the indicators, I took the headlight unit out (3 flathead screws at the top of the headlight assembly), undid one bolt that holds the plastic facia of the bumper around them for easier access and the headlight comes out. Checking the connector I identified the wire and spliced a wire into it using push/crimp connectors.
That connection goes to the orange wire on the DRL for that side, you then run two other wires, one is ground to either the nearest grounding point, or a post on the battery terminal. The other needs to feed back to an ignition switched live, I went for in the fusebox a small piggy-back fuse splitter and connected this to the cigarette lighter/acc socket fuse. This allows the DRLs to be on whenever the ignition switch is on (Remember the DRLs are very low current draw).

Fitting them, I had the option of above or below the existing lamp, both are relatively easy, but to squash the led bar in nicely I went for underneath, which gives good results, the light actually shines a little through the existing lens so it partially lights the main light up in duller weather.

Results were good.
Here you can see the position of the LED tubes underneath the lens.


It took a little pushing/pulling to get in the right place, I'm not 100% happy as they're not even over the whole headlight lens but I'm going to fix that by moving them around and possibly using dots of superglue to hold them against the headlight.

These are pretty bright when on and give off a nice glow:


And when the indicator is on the white DRLs go out and replaced by a flashing (in time with your indicator flash) orange bar:

(Catching the flash was difficult, here you can see the 'off' part of the sequence, hence it's not as bright as it actually looks!)




All in all for £10 and an hours work it went really well!