What is "asd" process?

[Yota]

@zitev @brendanp

I reported the GPL version to them in feedback, and told them that the GPL was provided to the Merlin author by Asus in advance.

The GPL version is: 386_50757

Your spam should be sent this way too.

I have a few diskwrite log for this /usr path on iOS 16.2

The asd (ASUS Security Daemon) we're talking about here has absolutely nothing to do with iOS or any other operating system.

But by the way, how do you check diskwrite log on that directory on your iOS? I don't think normal users can view that directory at all without jailbreaking.

asd scanned them and deleted all files of the form crt*[...]even though asd is supposed to be antimalware software, it is malware...

That's why they should never bother with user partitions, Asus doesn't know what files a user puts there, maybe a certain user is a malware collector. what annoys me the most is that they designed the malware to delete it without even getting confirmation from the user, which is extremely intrusive behavior.

The only solution is to not give execute permissions to the user partition, so that the user partition does not have to be scanned, or worry that there's enough malware stored there.

 

[D0m3L]

I wonder if this rm -fr feature apply to stock asus fw, or asus dev students does not fully trust 3rd party mods. Was looking on asd binary and there is merlin mentioned just a single line below 'rm -rf'.
By the way, it seems it can also delete whole directory.

 

[Tech9]

To be honest: The only reason I upgraded was to get rid of the blinky-"!" saying there was a new version available.

hosts.add file

0.0.0.0 fwupdate.asuswrt-merlin.net

No more blinky "!"

 

[Yota]

I wonder if this rm -fr feature apply to stock asus fw, or asus dev students does not fully trust 3rd party mods. Was looking on asd binary and there is merlin mentioned just a single line below 'rm -rf'.
By the way, it seems it can also delete whole directory.

No, the binary doesn't have newlines, but it does look like it has the ability to delete directories.

Since the asd binary is precompiled, you can actually download the asd binary located in 386_48966/386.7_2 here and replace it on 386.9 firmware using the command below:

wget -O "/jffs/asd_7_2" "https://raw.githubusercontent.com/RMerl/asuswrt-merlin.ng/46e3fb0bb25ba0edb4c98dd68f83d228cf592b18/release/src/router/asd/prebuild/$(nvram get model)/asd"
killall asd
mount --bind /jffs/asd_7_2 /usr/bin/asd

For each boot, create a service-start script like this:

#!/bin/sh
if [ "$(mount | grep -c asd)" = "0" ]; then
killall -q asd
mount --bind /jffs/asd_7_2 /usr/bin/asd
fi

 

[D0m3L]

No, the binary doesn't have newlines, but it does look like it has the ability to delete directories.

Since the asd binary is precompiled, you can actually download the asd binary located in 386_48966/386.7_2 here and replace it on 386.9 firmware using the command below:

wget -O "/jffs/asd_7_2" "https://raw.githubusercontent.com/RMerl/asuswrt-merlin.ng/46e3fb0bb25ba0edb4c98dd68f83d228cf592b18/release/src/router/asd/prebuild/$(nvram get model)/asd"
killall asd
mount --bind /jffs/asd_7_2 /usr/bin/asd

For each boot, create a service-start script like this:

#!/bin/sh
if [ "$(mount | grep -c asd)" = "0" ]; then
killall -q asd
mount --bind /jffs/asd_7_2 /usr/bin/asd
fi

Thank you for the instruction, it is helpful.

Anyway, I would rather make a script named asd with a 'sleep 99999999999999' inside, as my trust in any precompiled asus asd binary is now close to 0.

 

[Yota]

Anyway, I would rather make a script named asd with a 'sleep 99999999999999' inside, as my trust in any precompiled asus asd binary is now close to 0.

hahaha, I have tried to replace the asd with an ordinary script, it will only lead to the cycle of rc waking up asd, consuming a lot of CPU (50%).

There shouldn't be any harm in using older versions of asd on 386.9 firmware, asd will still run fine and won't cause high CPU load.

Thank you for the instruction, it is helpful.

I'd rather give a worthwhile reply

 

[dabbleduck]

...

Anyway, I would rather make a script named asd with a 'sleep 99999999999999' inside, as my trust in any precompiled asus asd binary is now close to 0.

I tried something like that and the [mtdblock3] and one other process were taking up a lot more time than they should have.
I used the following as my /jffs/scripts/services-start script instead.

#!/bin/sh

asdproc=$( ps|grep " asd$"|grep -v  grep )
if [ $( echo "$asdproc" | wc -l ) -ne 1 ] ; then
  exit
fi
pid=$(echo $asdproc | awk '{print $1}')
status=$(echo $asdproc | awk '{print $4}')
if [ "$status" != "T" ] ; then
  kill -19 $pid
fi

That leaves the asd process suspended. I have not yet checked when USB drives that are plugged in at boot time are mounted. That could be important since on my system asd is running 6 to 9 seconds before services-start is run.

 

[zitev]

@zitev @brendanp

Visszajelzésben jeleztem nekik a GPL verziót, és elmondtam, hogy a GPL-t előre az Asus biztosította a Merlin szerzőjének.

A GPL verzió: 386_50757

A spameket is így kell elküldeni.




Az asd-nek (ASUS Security Daemon), amelyről itt beszélünk, semmi köze az iOS-hez vagy bármely más operációs rendszerhez.

De mellesleg hogyan lehet ellenőrizni a lemezírási naplót abban a könyvtárban az iOS-en? Szerintem a normál felhasználók egyáltalán nem tudják megnézni azt a könyvtárat jailbreak nélkül.




That's why they should never bother with user partitions, Asus doesn't know what files a user puts there, maybe a certain user is a malware collector. what annoys me the most is that they designed the malware to delete it without even getting confirmation from the user, which is extremely intrusive behavior.

The only solution is to not give execute permissions to the user partition, so that the user partition does not have to be scanned, or worry that there's enough malware stored there.

I tried something like that and the [mtdblock3] and one other process were taking up a lot more time than they should have.
I used the following as my /jffs/scripts/services-start script instead.

#!/bin/sh

asdproc=$( ps|grep " asd$"|grep -v  grep )
if [ $( echo "$asdproc" | wc -l ) -ne 1 ] ; then
  exit
fi
pid=$(echo $asdproc | awk '{print $1}')
status=$(echo $asdproc | awk '{print $4}')
if [ "$status" != "T" ] ; then
  kill -19 $pid
fi

That leaves the asd process suspended. I have not yet checked when USB drives that are plugged in at boot time are mounted. That could be important since on my system asd is running 6 to 9 seconds before services-start is run.

I just simple did add a line to the end of /jffs/scripts/post-mount: /usr/bin/killall -STOP find

It looks like working after reboot...

 

[dabbleduck]

I just simple did add a line to the end of /jffs/scripts/post-mount: /usr/bin/killall -STOP find

It looks like working after reboot...

This may work if you have a USB drive that is plugged into the router all the time, but it is not a definitive solution. Here are the possible and actual problems I see with that.

Even if you have a USB drive permanently attached, can you be sure a a file will not be found and deleted between the time asd starts the find process and the time the kill command stops the process from the post-mount script?

In the case of nfs mounts from the command line, the post-mount script is never called. This may be the case for other types of command line mounts as well.

If you want to remove a USB drive, you will not be able to easily unmount it since find will still have files open on it.

I have moved on to replacing the asd binary before it is ever started. I compile the following code to produce an asd dummy.

#include <unistd.h>
#include <limits.h>

int main(){
  while (1)
    sleep(INT_MAX);
}

Move the binary to /jffs/bin/asd(the /jffs/bin directory may have to be created). Then use the following as /jffs/scripts/init-start.

#!/bin/sh
mount -o bind /jffs/bin/asd /usr/bin/asd

init-start is run early in the boot process before asd is ever started. This way, the original malware version of asd is never even run. For those without the ability to compile, you could try the following script as /jffs/bin/asd

#!/bin/sh
largeint=2147483647    # 2^31-1
while true ; do
  sleep $largeint
done

I have only tested the shell script version of the dummy asd for half an hour, but it seems to work well.

 

[zitev]

This may work if you have a USB drive that is plugged into the router all the time, but it is not a definitive solution. Here are the possible and actual problems I see with that.

Even if you have a USB drive permanently attached, can you be sure a a file will not be found and deleted between the time asd starts the find process and the time the kill command stops the process from the post-mount script?

In the case of nfs mounts from the command line, the post-mount script is never called. This may be the case for other types of command line mounts as well.

If you want to remove a USB drive, you will not be able to easily unmount it since find will still have files open on it.

I have moved on to replacing the asd binary before it is ever started. I compile the following code to produce an asd dummy.

#include <unistd.h>
#include <limits.h>

int main(){
  while (1)
    sleep(INT_MAX);
}

Move the binary to /jffs/bin/asd(the /jffs/bin directory may have to be created). Then use the following as /jffs/scripts/init-start.

#!/bin/sh
mount -o bind /jffs/bin/asd /usr/bin/asd

init-start is run early in the boot process before asd is ever started. This way, the original malware version of asd is never even run. For those without the ability to compile, you could try the following script as /jffs/bin/asd

#!/bin/sh
largeint=2147483647    # 2^31-1
while true ; do
  sleep $largeint
done

I have only tested the shell script version of the dummy asd for half an hour, but it seems to work well.

Indeed, I looked at it in the morning and the scanner was running, it probably starts with a delay. I'll keep the manual suspension for now.
--
..I refined the previous state a bit, added it to cron, as a process running every minute: cru a stopfind "1 * * * * /usr/bin/killall -STOP find"

 

[Mogsy]

The asd (ASUS Security Daemon) we're talking about here has absolutely nothing to do with iOS or any other operating system.

But by the way, how do you check diskwrite log on that directory on your iOS? I don't think normal users can view that directory at all without jailbreaking.

iOS Analytics. Toggled off and it's gone. Toggled on again plenty of networking topic report and mDNS wakesup_resource with correct

/usr/sbin/mDNSResponder

Interesting to see how Apple collect all the data for network etc. I disabled analytics again

Networking topic

{"postTime":1674278916578.5068,"events":[{"uptime":6551018930176,"com.apple.network.activity.supermetric":13,"clientId":0,"eventType":"networkingHealthSummary","com.apple.network.flow-hardfail":12,"lastUploadTime":1665153535602,"product":"iPhone OS","topic":"xp_swe_network_perf","eventTime":1674278915576.5161,"com.apple.network.activity.supermetric-hardfail":150,"com.apple.network.flow":1,"hard_failure_count":496,"com.apple.network.nwconnectionreport":10,"modelid":"iPhone14,2","com.apple.network.nwconnectionreport-hardfail":334,"eventLinkID":"265BB157-B556-4B6A-ADC7-229DB25C0A1E","build":"20C65"},{"interfaceCellularViaIndependentFallback":false,"interfaceUnknown":false,"wiredBytesIn":0,"interfaceConstrained":false,"topic":"xp_swe_network_perf","interfaceExpensive":false,"attributedEntity":"geod","clientId":0,"eventLinkID":"265BB157-B556-4B6A-ADC7-229DB25C0A1E","eventTime":1665162000820.677,"hasWiredTraffic":false,"eventType":"com.apple.network.flow","isNonAppInitiated":false,"interfaceLoopback":false,"interfaceWiFi":true,"hasLocalDestination":false,"interfaceWired":false,"hasNonLocalDestination":false,"type":"udp-sflow4","hasTraffic":false,"isTracker":false,"processName":"mDNSResponder","eventClass":1,"wifiBytesOut":0,"interfaceAWDL":false,"wiredBytesOut":0,"interfaceCompanionLink":false,"appStateIsForeground":false,"trafficClass":0,"interfaceCellular":false,"build":"20A380","receiveBufferUsed":0,"interfaceCellularViaSlowFallback":false,"cellularBytesOut":0,"packetsIn":1,"hasWiFiTraffic":false,"wifiBytesIn":0,"interfaceLLW":false,"delegateName":"mDNSResponder","duration":0.010678625000000001,"product":"iPhone OS","attributedEntityIsBundleName":false,"isDaemon":true,"startAppStateIsForeground":false,"cellularBytesIn":0,"attributedEntityIsProcessName":true,"interfaceCellularViaPreferredFallback":false,"bytesOut":44,"startScreenStateOn":false,"hasCellularTraffic":false,"usesChannels":false,"receiveBufferSize":786896,"isIPv4":true,"interfaceCellularViaFastFallback":false,"packetsOut":1,"isIPv6":false,"attributionReason":"reason-procnm",

 

[Yota]

iOS Analytics

I see, thanks for the explanation

 

[RMerlin]

There is a bigger problem with asd then just hammering attached drives with scans. asd is actually destructive. I mounted an nfs share that contained some fortunately now unused nfsroot filesystems. asd scanned them and deleted all files of the form crt*. This makes asd seem like a rather blunt instrument. All these files on the mount were either i686 or x86_64 binaries, which could not have been used to link executables that would run on the router. Sure, these files could be used to link malware on other machines, but how hard would it be to store these C runtime files using a different name. I would never have known about this if I hadn't tried to unmount the share and had the request denied because asd had open files on it.

Do you still have the log file generated in /jffs/asd.log? If so, Asus would be interested in having a look at it. Email it to router_feedback@asus.com, tell them I told you to mail it to them.

 

[RMerlin]

BTW, the issue with find waking up HDDs is already fixed for the next major update to the ASD daemon, however they are considering in the meantime possibly resolving this in a signature update for the current version.

 

[Pabla]

Ive been trying to figure out why my CPUs on my AC3100 running 386.9 have been high. Having a look at the top processes and looks like ASD CPU usage is constantly at 50%. I have a 4tb HDD connected and according to this thread looks like it's a malware scan being performed. Never saw this on previous FWs. Is this something to be worried about or just wait for an update as Merlin wrote above

 

[zitev]

Ive been trying to figure out why my CPUs on my AC3100 running 386.9 have been high. Having a look at the top processes and looks like ASD CPU usage is constantly at 50%. I have a 4tb HDD connected and according to this thread looks like it's a malware scan being performed. Never saw this on previous FWs. Is this something to be worried about or just wait for an update as Merlin wrote above

kick the running process and wait for the solution!

 

[brendanp]

Is this something to be worried about or just wait for an update as Merlin wrote above

By now, any files that meet the criteria of the asd search are already deleted ... so if you had any that meet the criteria (listed in previous posts) they're gone.

For me, I just don't want my hdd spinning and seeking non-stop ... it's annoying to listen to, and it reduces the lifespan of the drive ... (there's a reason manufacturers developed the spin-down and idle states...)

There are a few great fixes in this thread you could implement, or, do what I did: Roll back to the previous version.

 

[Pabla]

I guess I will let ASD do its thing until the patch is released, I have my HDD constantly spinning anyways. The noise it creates bc of ASD is annoying though lol

 

[RMerlin]

(there's a reason manufacturers developed the spin-down and idle states...)

It's for power saving reasons. The spindown/spinups are more damaging to an HDD than having it run 24/7. That's why catastrophic drive failures almost always occur on power up.

 

[zitev]

It's for power saving reasons. The spindown/spinups are more damaging to an HDD than having it run 24/7. That's why catastrophic drive failures almost always occur on power up.

This is generally true for server drives, but not true for HDDs used in archiving systems, they are designed for intermittent operation, continuous operation drastically reduces the lifespan.