< 00003400: 0000 8843 0000 8843 4000 0000 0000 1100 ...C...C@.......
> 00003400: 4523 6113 9978 4644 4000 0000 0000 1100 E#a..xFD@.......
Can you see where I changed a frequency from 438.8MHz to 136.12345MHz?
Also 438.8 to 444.67899
@M0YNG 0x45236113 = 13612345; 0x99784644 = 44467899 when interpreted as unsigned 32bit. ;) I can recommend Okteta for hex file analysis
@sp6mr oo, now that makes a lot of sense.
I was wondering what weird format the numbers were in because it seems that the bits are out of order.
thanks for the tip :D
@M0YNG Seriously, Okteta from #KDE is the best thing since sliced bread when you have a binary file for analysis. Also you can define your own data structures using XML or JS, and everything will show up as a nice tree structure with highlighting of the interesting parts in the data view.
This is one of the most underrated tools I know about, and it's fully open source 😁
This is with a value of 11111111
0001f060: ffff 5445 5354 5445 5354 5445 5354 5445 ..TESTTESTTESTTE
0001f070: 5354 ffc7 8aa9 04ff ffff 3331 3120 5441 ST........311 TA
This is with 11111112
0001f060: ffff 3331 3020 5441 4300 0000 0000 0000 ..310 TAC.......
0001f070: 0000 ff37 0100 04ff ffff 3331 3120 5441 ...7......311 TA
And 11111113
0001f070: 5354 ffc9 8aa9 04ff ffff 3331 3120 5441 ST........311 TA
@sp6mr thanks for the tip, I'm making some progress trying to find stuff by making one change, running diff, and then inspecting it in Okteta.
Any thoughts on this though?
Changing the call ID for a contact causes a change, but it’s not clear how the data is stored, it doesn’t appear to be unsigned 32bit. Here I’ve changed the ID from 310 to 111
< 0001f070: 0000 ff36 0100 04ff ffff 3331 3120 5441 ...6......311 TA
---
> 0001f070: 0000 ff6f 0000 04ff ffff 3331 3120 5441 ...o......311 TA