[Discussion] Google Pay Magisk Discussion Thread

[Fry-kun]

I expanded the trigger SQL a bit. The app that checks the attestation state (GMS toolbox by @Freshek) is looking at a different table in a different db (Wallets in android_pay) as opposed to the method by @BostonDan which is looking at main in dg.db.
[...]

Applied this to my phone, but Pay still doesn't let me set up a card to use in store. Is there a step I'm missing other than applying the sql commands?
I've verified with sqlite3 that the fields are updated as per script.

 

[hanneshoch3]

Try setting it read-only, that's the only way it works for me as well. Neither the script nor manual changes do the trick without it being read-only. Make sure to have set the fields to 0 before you make it r/o. However, sometimes the terminal still declines the card after some time, even though gpay says it worked fine. Then I have to remove gms folder and do the same procedure again so I can setup PayPal again.

 

[jcmm11]

Applied this to my phone, but Pay still doesn't let me set up a card to use in store. Is there a step I'm missing other than applying the sql commands?
I've verified with sqlite3 that the fields are updated as per script.

Some feedback seems to say that setting dg.db RO allowed you to add cards. Feedback also states you can change it back to RW after adding the cards

 

[Xx-Ness-xX]

In your script:

CREATE TRIGGER IF NOT EXISTS fails_attestation_update AFTER UPDATE OF fails_attestation
ON Wallets WHEN (NEW.fails_attestation <> 0)

isn't the bold font supposed to be OLD?

P.S. I don't know much about sql programming but I am just trying to make sense out of it

Thanks,

I expanded the trigger SQL a bit. The app that checks the attestation state (GMS toolbox by @Freshek) is looking at a different table in a different db (Wallets in android_pay) as opposed to the method by @BostonDan which is looking at main in dg.db.

So I created triggers for both tables. There's 2 sql files in the attached zip file. One will set any non-zero attestation values to zero and also create both insert and update triggers for both tables.
The second file drops (removes) the triggers from both tables, but doesn't change any values.

This solution doesn't need any permission changes and should, in theory, be good for any updates going forward - unless they change the table structure. If it works it's apply and forget.

I strongly recommend using the Magisk Mod for SQLite. To apply these files feed them into the sqlite3 binary. Assuming you have them in the root of sdcard, and using attest.sql as the example just run, as root

sqlite3 < /sdcard/attest.sql

If you've already applied the previous files I posted these won't hurt anything, you can apply these over those with no problems. Contents of attest.sql

.open /data/data/com.google.android.gms/databases/dg.db
UPDATE main SET c='0' WHERE a LIKE '%attest%';

CREATE TRIGGER IF NOT EXISTS attestation_insert AFTER INSERT 
ON main WHEN (NEW.a LIKE '%attest%' AND NEW.c <> 0)
BEGIN
UPDATE main SET c = 0 WHERE ROWID = NEW.ROWID;
END;

CREATE TRIGGER IF NOT EXISTS attestation_update AFTER UPDATE OF c 
ON main WHEN (OLD.a LIKE '%attest%' AND NEW.c <> 0)
BEGIN
UPDATE main SET c = 0 WHERE ROWID = OLD.ROWID;
END;
.schema main

.open /data/data/com.google.android.gms/databases/android_pay
UPDATE Wallets SET fails_attestation=0 WHERE fails_attestation <> 0;

CREATE TRIGGER IF NOT EXISTS fails_attestation_insert AFTER INSERT 
ON Wallets WHEN (NEW.fails_attestation <> 0)
BEGIN
UPDATE Wallets SET fails_attestation = 0 WHERE ROWID = NEW.ROWID;
END;

CREATE TRIGGER IF NOT EXISTS fails_attestation_update AFTER UPDATE OF fails_attestation 
ON Wallets WHEN (NEW.fails_attestation <> 0)
BEGIN
UPDATE Wallets SET fails_attestation = 0 WHERE ROWID = OLD.ROWID;
END;
.schema Wallets
.quit

Contents of drop_attest.sql

.open /data/data/com.google.android.gms/databases/dg.db
DROP TRIGGER IF EXISTS attestation_insert;

DROP TRIGGER IF EXISTS attestation_update;
.schema main

.open /data/data/com.google.android.gms/databases/android_pay
DROP TRIGGER IF EXISTS fails_attestation_insert;

DROP TRIGGER IF EXISTS fails_attestation_update;
.schema Wallets
.quit

 

[irony_delerium]

In your script:

CREATE TRIGGER IF NOT EXISTS fails_attestation_update AFTER UPDATE OF fails_attestation
ON Wallets WHEN (NEW.fails_attestation <> 0)

isn't the bold font supposed to be OLD?

Nope. It's checking the updated row (alias NEW), not the original row (which would be OLD). If GMS sets Wallets.fails_attestation to anything non-zero, the trigger executes after the update statement is finished.

 

[Clark789]

Hi,

yesterday at first with Magisk 19.0 (OP3T, stock OOS 5.0.8) my payment with Google Pay didn't want to work. After i have made an update to Magisk 19.2, it worked without any issues. Just for information...

Regards
Clark

 

[GryphonBR]

I used the script method to set the values to 0.

Still don't know which script you're referring to, since there are at least two solutions floating around: one that has a longer SQL script, and AFAIK keeps dg.db R/W, and another that should be somewhat shorter and sets dg.db RO. I use the latter with a Termux script I adapted to allow for a widget creation through Termux:Widget and I've had no issues using GPay - I received an update for the app yesterday but was still able to make a purchase without hiccups last night.

 

[Nekromantik]

Still don't know which script you're referring to, since there are at least two solutions floating around: one that has a longer SQL script, and AFAIK keeps dg.db R/W, and another that should be somewhat shorter and sets dg.db RO. I use the latter with a Termux script I adapted to allow for a widget creation through Termux:Widget and I've had no issues using GPay - I received an update for the app yesterday but was still able to make a purchase without hiccups last night.

I used the longer SQLscript that keeps db file RW.
one quoted above by people.

 

[GryphonBR]

I used the longer SQLscript that keeps db file RW.
one quoted above by people.

That might just be the issue; I haven't used the one keeping dg.db R/W and I have not had any problems since using the alternate script that keeps it RO.

If you want, here's a copy of the script I'm currently using, and as an extra piece of info I have SQlite installed from Termux:

am force-stop /data/data/com.google.android.apps.walletnfcrel
chmod 777 /data/data/com.google.android.gms/databases/dg.db
/sbin/sqlite3 /data/data/com.google.android.gms/databases/dg.db "update main set c='0' where a like '%attest%';"
chmod 440 /data/data/com.google.android.gms/databases/dg.db

 

[Nekromantik]

That might just be the issue; I haven't used the one keeping dg.db R/W and I have not had any problems since using the alternate script that keeps it RO.

If you want, here's a copy of the script I'm currently using, and as an extra piece of info I have SQlite installed from Termux:

am force-stop /data/data/com.google.android.apps.walletnfcrel
chmod 777 /data/data/com.google.android.gms/databases/dg.db
/sbin/sqlite3 /data/data/com.google.android.gms/databases/dg.db "update main set c='0' where a like '%attest%';"
chmod 440 /data/data/com.google.android.gms/databases/dg.db

will try that thanks

 

[dardack]

I left it as read-only. I was able to add a brand new card to GPay and use the added cards without any concerns - besides, the past couple of times I had the "can't pay in store" message (which were before the SQL patching), the cards were still available on GPay, but I never found a solution before where I could simply keep GPay as was. If it happens again, I'll update this.
.

So just after having a few days to test in store and what not. The attest.sql works great for setting the 0, but doesnt' seem to fix the trigger issue or some other issue. dg.db NEEDS to be Read only for adding cards and for in store payment. It had worked once for me as r/w but went to another store and kept getting error trying to pay, changed to r/o boom worked right away same terminal/store/card. Shrug.

 

[dimon222]

That might just be the issue; I haven't used the one keeping dg.db R/W and I have not had any problems since using the alternate script that keeps it RO.

If you want, here's a copy of the script I'm currently using, and as an extra piece of info I have SQlite installed from Termux:

am force-stop /data/data/com.google.android.apps.walletnfcrel
chmod 777 /data/data/com.google.android.gms/databases/dg.db
/sbin/sqlite3 /data/data/com.google.android.gms/databases/dg.db "update main set c='0' where a like '%attest%';"
chmod 440 /data/data/com.google.android.gms/databases/dg.db

attest.sql + this = works on my Huawei Mate 20 Pro :good:

 

[Itachisasuke]

Has anyone thought about turning the above scripts into a Magisk module that monitors one of the lines and runs automatically?

 

[jsylvia007]

I expanded the trigger SQL a bit. The app that checks the attestation state (GMS toolbox by @Freshek) is looking at a different table in a different db (Wallets in android_pay) as opposed to the method by @BostonDan which is looking at main in dg.db.

So I created triggers for both tables. There's 2 sql files in the attached zip file. One will set any non-zero attestation values to zero and also create both insert and update triggers for both tables.
The second file drops (removes) the triggers from both tables, but doesn't change any values.

This solution doesn't need any permission changes and should, in theory, be good for any updates going forward - unless they change the table structure. If it works it's apply and forget.

I strongly recommend using the Magisk Mod for SQLite. To apply these files feed them into the sqlite3 binary. Assuming you have them in the root of sdcard, and using attest.sql as the example just run, as root

sqlite3 < /sdcard/attest.sql

If you've already applied the previous files I posted these won't hurt anything, you can apply these over those with no problems. Contents of attest.sql

.open /data/data/com.google.android.gms/databases/dg.db
UPDATE main SET c='0' WHERE a LIKE '%attest%';

CREATE TRIGGER IF NOT EXISTS attestation_insert AFTER INSERT 
ON main WHEN (NEW.a LIKE '%attest%' AND NEW.c <> 0)
BEGIN
UPDATE main SET c = 0 WHERE ROWID = NEW.ROWID;
END;

CREATE TRIGGER IF NOT EXISTS attestation_update AFTER UPDATE OF c 
ON main WHEN (OLD.a LIKE '%attest%' AND NEW.c <> 0)
BEGIN
UPDATE main SET c = 0 WHERE ROWID = OLD.ROWID;
END;
.schema main

.open /data/data/com.google.android.gms/databases/android_pay
UPDATE Wallets SET fails_attestation=0 WHERE fails_attestation <> 0;

CREATE TRIGGER IF NOT EXISTS fails_attestation_insert AFTER INSERT 
ON Wallets WHEN (NEW.fails_attestation <> 0)
BEGIN
UPDATE Wallets SET fails_attestation = 0 WHERE ROWID = NEW.ROWID;
END;

CREATE TRIGGER IF NOT EXISTS fails_attestation_update AFTER UPDATE OF fails_attestation 
ON Wallets WHEN (NEW.fails_attestation <> 0)
BEGIN
UPDATE Wallets SET fails_attestation = 0 WHERE ROWID = OLD.ROWID;
END;
.schema Wallets
.quit

Contents of drop_attest.sql

.open /data/data/com.google.android.gms/databases/dg.db
DROP TRIGGER IF EXISTS attestation_insert;

DROP TRIGGER IF EXISTS attestation_update;
.schema main

.open /data/data/com.google.android.gms/databases/android_pay
DROP TRIGGER IF EXISTS fails_attestation_insert;

DROP TRIGGER IF EXISTS fails_attestation_update;
.schema Wallets
.quit

So I ran the attest.sql file from a root terminal. It appears to have applied. I then opened up Google Pay, and tapped "Set up in-store payments" on one of my cards. I was met with: "Couldn't finish setup to pay in stores -- This phone can't be used to pay in stores. This may be because it is rooted or altered in some way."

Is there something else that needs to be done in Magisk? Attestation now shows 0, so that's a plus.

 

[dimon222]

Has anyone thought about turning the above scripts into a Magisk module that monitors one of the lines and runs automatically?

Probably harder since it means monitoring Sqlite 24/7. However, the patch creating triggers can theoretically be incorporated in Magisk module. Not sure if it fits philosophy of Magisk tho, since its mainly dealing with non-modifying of such data.

So I ran the attest.sql file from a root terminal. It appears to have applied. I then opened up Google Pay, and tapped "Set up in-store payments" on one of my cards. I was met with: "Couldn't finish setup to pay in stores -- This phone can't be used to pay in stores. This may be because it is rooted or altered in some way."

Is there something else that needs to be done in Magisk? Attestation now shows 0, so that's a plus.

Check my post couple of messages up, chmods are required as well.

 

[jsylvia007]

Probably harder since it means monitoring Sqlite 24/7. However, the patch creating triggers can theoretically be incorporated in Magisk module. Not sure if it fits philosophy of Magisk tho, since its mainly dealing with non-modifying of such data.

Check my post couple of messages up, chmods are required as well.

So correct me if I'm wrong, BUT, the chmods prevent GMS, etc. from auto-updating, so I would need to be mindful of that, correct?

 

[GryphonBR]

So just after having a few days to test in store and what not. The attest.sql works great for setting the 0, but doesnt' seem to fix the trigger issue or some other issue. dg.db NEEDS to be Read only for adding cards and for in store payment. It had worked once for me as r/w but went to another store and kept getting error trying to pay, changed to r/o boom worked right away same terminal/store/card. Shrug.

Exactly as I originally suggested, RO allows for it to work.

That might just be the issue; I haven't used the one keeping dg.db R/W and I have not had any problems since using the alternate script that keeps it RO.

If you want, here's a copy of the script I'm currently using, and as an extra piece of info I have SQlite installed from Termux:

attest.sql + this = works on my Huawei Mate 20 Pro :good:

You don't need SQL plus the snippet I provided, it should be one or the other. So far, it seems keeping db.dg R/W as attest.sql does prevents GPay from working consistently.

So correct me if I'm wrong, BUT, the chmods prevent GMS, etc. from auto-updating, so I would need to be mindful of that, correct?

That's a supposition, so far. I've yet to see anything clearly stating that from a factual point of view.

 

[jsylvia007]

Exactly as I originally suggested, RO allows for it to work.


You don't need SQL plus the snippet I provided, it should be one or the other. So far, it seems keeping db.dg R/W as attest.sql does prevents GPay from working consistently.


That's a supposition, so far. I've yet to see anything clearly stating that from a factual point of view.

Confirming that all I needed to do was apply your script and I was able to add the cards successfully. Before applying I removed the SQL stuff. Won't be able to pay for a bit, but will test as soon as I can.

 

[GryphonBR]

Confirming that all I needed to do was apply your script and I was able to add the cards successfully. Before applying I removed the SQL stuff. Won't be able to pay for a bit, but will test as soon as I can.

You removed the SQL stuff because you had already used the attest.sql previously, right? If not, you won't be able to use GPay anyway - the SQL commands in the script are shared are needed to get GPay to a work state, then the permission change to dg.db is necessary to ensure the changes are persistent.

 

[jsylvia007]

You removed the SQL stuff because you had already used the attest.sql previously, right? If not, you won't be able to use GPay anyway - the SQL commands in the script are shared are needed to get GPay to a work state, then the permission change to dg.db is necessary to ensure the changes are persistent.

Correct. I had already used attest.sql and then you said in a post above that you either need one method or the other, not both. So I ran the file to remove what attest.sql had done and then created a script out of your commands and ran those.