Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connection lost during NFC Memory Dump #9

Open
hapvlz opened this issue Mar 20, 2021 · 5 comments
Open

Connection lost during NFC Memory Dump #9

hapvlz opened this issue Mar 20, 2021 · 5 comments

Comments

@hapvlz
Copy link

hapvlz commented Mar 20, 2021

Hi bro,

I am trying to perform memory dump of RF430TAL152H but unfortunately it keep failing at some point.
Looking at the android studio seems it hang on different sections each time.

Phone is near to the sensor, but it keep failing.

2021-03-20 13:34:27.471 25056-25056/com.kk4vcz.goodv D/GoodV: read(): address=@4678 len=8
2021-03-20 13:34:27.485 25056-25056/com.kk4vcz.goodv D/GoodV: read(): address=@4680 len=8
2021-03-20 13:34:27.499 25056-25056/com.kk4vcz.goodv D/GoodV: read(): address=@4688 len=8

Do you have any ideas? or maybe we can divide the memory into few parts?

@travisgoodspeed
Copy link
Owner

If the one sensor is unreliable, it might be a dead battery. RF430 devices can work without a battery, but they aren't very reliable about it, especially on a dead one.

Memory reads are done in transactions of 8 bytes, which is the smallest supported by the TAL without firmware patching. A better method might be some sort of a queue, so that you could break away from the tag and fill in the blanks on a later read.

@hapvlz
Copy link
Author

hapvlz commented Mar 21, 2021

Thank you for answer.
I already figured out why it failing.

I was trying to read the memory when near the sensor I had transmitter (Miao Miao 2) which during memory dump also accessed it. I assume when MiaoMiao did memory read (unlock -> lock) then it cut my memory read.

That would make sense :)
Anyway I've managed to read the memory from sensor that is not connected to my body :D

So I have the dump exported, but I'm having issues to import it back.
What I am trying to do is continue your project and find a way to bring sensor alive from 06 state.

I have the full dump export before the sensor went into 06 state and somehow deep inside me believe that importing the whole memory export might bring back the sensor to state when it was useable.

I'm experimenting :) i've tried your methods of overwrite early bytes, execute commands E0, E1, E2 but also as you underlined it doesn't bring back the sensor.

So going back to my question, when I am trying to import the whole dump I'm having error -

D/GoodV: Tag tapped to program.
V/GoodV: Writing 64 bytes to 0x1A00.
E/GoodV: No block number for address: 6656
    Illegal block adr.
I/om.kk4vcz.good: Background young concurrent copying GC freed 19516(892KB) AllocSpace objects, 6(376KB) LOS objects, 24% free, 4708KB/6263KB, paused 5.415ms total 24.345ms

I see it fail at function adr2block -

if (adr >= 0x1C00 && adr < 0x2C00) { ///SRAM
            /* Only available on stock rom by the Cx commands.*/
            return ((adr - 0x1C00) / blocklen) + 0x600;
        } else if (adr >= baseadr && adr < 0x10000) {
            // RF430FRL152H devices wrap into the next page after 0xF2,
            // so 0xFC34 is fetched from page 1, block 0.

            //Don't forget to set the page number!
            int block = ((adr - baseadr) / blocklen);
            if (block >= blockcount)
                block -= blockcount;
            return block;
        } else { //No block number.
            Log.e("GoodV", "No block number for address: " + adr);
            return -1;
        }

The beginning of dump has -

@1a00
03 03 e6 22 e6 81 67 9a 54 1f 44 62 00 a0 8b a6
0f 2c 8b 2f 14 1a e7 3e 56 05 80 00 13 0f c3 3c
82 bb 82 18 67 39 03 a0 9b db df 19 cf 64 10 dd
63 3d fc 08 78 0b 90 19 15 39 86 36 50 33 c5 0a

1a00 => 0x1A00
int baseadr = 0xF868; //F868 on stock ROM, F860 on CGM ROM.
it uses baseadr = f860 (taking it from NfcRF430TAL)

So it doesn't fit for the first if
if (adr >= 0x1C00 && adr < 0x2C00) { ///SRAM
also it doesn't pass trough second if
else if (adr >= baseadr && adr < 0x10000) {
so at the end it return else with value -1 that cause the import/write to crash.

I've tried to bypass it and start from next possible address which in the dump is:
@1c00

But then it gives different error -

D/TAGID: 541f446200a007e0
D/GoodV: Tag tapped to program.
V/GoodV: Writing 4096 bytes to 0x1C00.
D/GoodV: BASEADRf860
E/GoodV: Error writing block16 0x0600
E/GoodV: Error writing 8 bytes to 0x0600: 014b020000f81f87

Do you maybe have any ideas? or maybe you already tried to import full dump back to sensor and it didn't worked also?
So interesting topic but working alone is so frustrating :)

@hapvlz
Copy link
Author

hapvlz commented Mar 22, 2021

Thanks @gui-dos for response.
I've checked that part and seems I don't need to import this range since there are no many changes in this part before sensor corrupion and after. Most changes happened in FRAM which is from 0xF860 till 0xFFFF.

I think I'll start from this point. @gui-dos you were able to import dumped memory back to sensor?

@hapvlz
Copy link
Author

hapvlz commented Mar 22, 2021

@gui-dos Thank you very much for this explanation.

Indeed I also seen those videos from Russia where they assembly back sensor to injector to re-apply it, personally I would never attempt that, I am afraid to use fresh kit to apply it to my body and what about custom assembly back... :)

I've managed to re-write whole FRAM memory (around 1900 bytes) back to sensor. Re-writed data at first after import shows that CRC of each sections (header, data, footer, patch code) is correct, however after a moment sensor by itself change the CRC of Patch code block and make it incorrect.

read=7567 computed=7567
after a moment
read=aef9 computed=7567

I think this is the thing that for now make the sensor broke (status 0x06) if I understood correctly apart from sensor stage, worktime, history index/results it also check for the CRC's, so it's only one thing that do not match.

I've noticed also that you are talking about Libre 2, I am working currently on Libre 1 but definitely your response will help me further with Libre 2, I'll most likely move to it once I'm done with Libre 1. Also Libre 2 is not that much available for now in my country, so I need to wait :)

Anyway, thank you a lot for response.
I'll keep trying to understand what is happening in that sensor

@hapvlz
Copy link
Author

hapvlz commented Mar 22, 2021

Ok small update, seems I've corruped the sensor memory somewhere in the middle.
And the dump that I've used was already corruped so even after importing the FRAM memory it was giving 06 error.

After importing memory from different sensor it seems to be fully okay :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants