So many of us have the Obi1xx series devices that recently stopped connecting to google servers due to a certificate update. This thread is intended to discuss the possibility of modifying the firmware to update the certificate and let these devices work with Google Voice again.

These devices are based on a MIPS-X processor similar to the Sipura ATAs and there is not a lot of tools/docs out there about them except for a Yahoo Group mostly related to DVD player chipsets. The venerable DogFace05 who was an expert with these types of devices once posted that he was able to extract this firmware sucessfully. Not sure if he is still around. Anyone else familiar with this architecture?

It seems that the place to start looking is the end of the firmware update file which contains some kind of table. Then there seems to be a loader section which presumably decompresses one or more other sections and loads them to RAM before executing the firmware.

So the questions are:
Can we extract, modify, and repack the firmware and create proper checksums/signatures?
Where is the certificate stored and in what format?
Can we drop in a new certificate without messing up other things (e.g. if the length of the certificate has changed) or do we need to move the certificate and patch the code pointing to it?
Is updating the certificate enough or is the codebase missing support that is necessary (e.g. if key length has changed)?

Anyone who wants to participate please post your thoughts.

Thanks

Interesting project, though not for me personally, because:

1. IMO An ATA is a crude compromise solution. If I were to add an enhancement to a VoIP device, it would most likely be an IP phone. I do own an OBi110, but only the Line port is in use.

2. IMO GV is a mediocre service that happens to be priced at zero, only a little less expensive than some good ones.

3. My 70+ year old brain can no longer simultaneously hold many details about assembly code for an unfamiliar architecture. Reverse engineering (for me) requires detailed documentation of each step, which I find very tedious.

Some concerns:

The SPA firmware has two integrity checks, MD5 and a proprietary one that preprocesses each byte with a 'secret' algorithm and takes MD5 of the result. If the OBi does something similar, one would have to find the relevant code and decompile it well enough to understand the algorithm. Worse, I am guessing that they instead use a real (cryptographic) signature. Since it's probably not possible to (legally) obtain the private key, one would need to find a vulnerability that permits loading unsigned code.

I'm guessing that several devices will be bricked in the course of development. It's of course possible to unbrick a device by saving the flash before the experiment and restoring it afterwards. However, I don't know whether that's possible by JTAG or other simple method, or whether removal of the flash chip is needed.

Some rays of hope:

On a wired broadband connection, an MITM attack is unlikely, so merely disabling the failing certificate check may be an adequate fix. There is likely a place in the code where toggling a single bit will suffice, certainly by changing one byte. This may be much easier than the proper mod.

One may be able to find a 'remote code execution' vulnerability that can be used to make the patch (either one byte, or the proper one). This would eliminate the need to satisfy the integrity checks.

I assume that ITSPs have a way to present config files by HTTPS, using a cert that the OBi can verify. With that private key, one could write a simple MITM script that would sit between Google and the device, accepting or ignoring the Google cert and presenting the OBi with an acceptable one.

Many years ago, I did a crude MIPS-X disassembler in perl. If you get past decryption / decompression and can't find anything better online, I'll try to find it on an old backup.

Maybe reach out to the guy who wrote this blog article.

»randywestergren.com/reve ··· -part-1/

Might have some insight on how to accomplish this.

Thanks, this is really powerful stuff.

Though not directly applicable (OS, architecture and format are all different), the source code of the OBi-specific apps is probably very similar. So, you can work with the 200 stuff in a pleasant environment, find a suitable vulnerability, then check whether it's present in the 110 version.

I tried to get a serial console from the UART on my obi110 today. No luck yet. Guessing at baudrates with my shitty soldering skills and no scope sucks.

There's an SPI port also which might help if we need to bypass any webadmin validation checks and read/write directly to the flash.

Thanks for your replies. Yes the SPI port is broken out to a header so it is easy to read and write the flash chip directly. I think there is only one other testpoint on the board.

If we look at the 2886 firmware update, the firmware bundle starts at 0xF3CEE and has a 1KB header including a version string. The first section has a 34 byte header. The next section starts at 0x1E3CEE. The next section starts at 0x213CEE and it has the text "Goodbye! Reboot Now" at the end so seems like a loader/updater. These are the first 34 bytes of each of those sections.

00 00 04 00 00 7F 81 C4 00 00 00 53 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 04 00 00 7F F6 C4 00 00 00 30 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 12 22 07 0C FF 13 CC 00 00 00 06 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E7 7B FF 30

There are also some tables at the end of each of the memory ranges which are unchanged across firmware versions and one example is:

E0 08 00 09 96 C4 87 E0 48 C8 42 41 96 C8 87 E0 E0 04 00 FF 96 C4 40 08 E0 04 00 3D 96 C4 81 14 E0 04 01 00 96 C4 88 28 E0 04 00 11 48 04 22 41 E0 84 01 FF 96 C4 84 1C 96 C0 86 1C E0 12 1C FF 48 12 92 41 E2 52 FF FC 82 52 00 00 60 00 00 19 82 54 00 04 60 00 00 19 82 56 00 08 60 00 00 19 60 00 70 19 82 86 00 00 E0 04 00 01 08 86 00 16 60 00 00 19 60 00 00 19 E0 04 00 02 08 86 00 27 60 00 00 19 60 00 00 19 E0 04 00 03 08 86 00 3B 60 00 00 19 60 00 00 19 E0 04 00 05 08 86 00 33 60 00 00 19 60 00 00 19 E0 04 00 06 08 86 00 2B 60 00 00 19 60 00 00 19 E1 CE 00 01 E2 94 00 10 29 D6 FF E7 60 00 00 19 60 00 00 19 82 9A 00 04 82 98 00 08 82 8C 00 0C 60 00 00 19 08 0C FF F5 60 00 00 19 60 00 00 19 83 44 00 00 60 00 00 19 60 00 00 19 93 04 00 00 60 00 00 19 E3 5A 00 04 E3 18 00 04 E1 8D FF FF 29 80 FF F6 60 00 00 19 60 00 00 19 08 00 FF E7 60 00 00 19 60 00 00 19 82 9A 00 04 82 8C 00 08 60 00 00 19 08 0C FF E1 60 00 00 19 60 00 00 19 93 40 00 00 60 00 00 19 E3 5A 00 04 E1 8D FF FF 29 80 FF FA 60 00 00 19 60 00 00 19 08 00 FF D7 60 00 00 19 60 00 00 19 82 B2 00 04 08 00 FF D3 60 00 00 19 60 00 00 19 82 B0 00 04 08 00 FF CF 60 00 00 19 60 00 00 19 82 9A 00 04 60 00 00 19 E0 3A 00 20 48 3B D2 41 C3 40 00 00 60 00 00 19 60 00 00 19 E0 02 00 C3 D0 40 00 01 E0 36 20 00 48 37 B2 41 E0 06 00 0C 48 06 32 41 E0 C6 25 3E 96 C6 40 04 E0 04 00 0F 48 04 22 41 E0 84 84 04 96 C4 81 00 E0 04 2C 0E E0 86 03 00 96 C6 40 00 96 C4 40 00 E0 06 0E 01 48 06 32 41 E0 04 00 01 48 C4 22 41 96 C4 87 E0 E0 04 00 11 48 C4 22 41 96 C4 87 E0 E0 04 00 05 48 C4 22 41 96 C4 87 E0 08 00 FF 7C 60 00 00 19 60 00 00 19 60 00 00 19 0C FF 00 00

The flash layout ends up looking like:

0x0 - OBI_PARAM_PT section length 0x20000
0x20000 - OBI_PARAM_PT section length 0x20000
0x40000 - blank
0x60000 - OBI_PARAM_PT section length 0x10000
0x70000 - call logs length 0x10000
0x80000 - OB100_DPT section (web files)
0x2D000 - Firmware Start
0x3C000 - Firmware Section 2
0x3E000 - OB100 UNIT INFO
0x3F000 - Firmware Section 3 (loader?)

Maybe something jumps out to someone who has stared at this stuff before.

If you provide the layout of the PIN headers dor this SPI port, it may help others to participate the hack. Also, it would be nice to provide what equipment and/or interface you use.

As it turns out the "tables" at the end of each firmware section are valid MIPS code (60 00 00 19 is a nop), the loader section is valid MIPS code, and few more code sections mixed in as well. mipsxdis seems to work fine, just need some brains that can effectively parse disassembly output.

If one was able to get a root shell, you can do nearly anything...

If the flaw was fixed, downgrade the firmware to a version that it works on...

The hard part is being able to make the desired changes, once you get a root shell, the 'hard' part is done.

What OS does the 1xx run? (I'm reasonably certain it's not Linux.)
Does it have the concept of 'root', or even of 'shell'?

I was basing it off of the article linked.

Next, I tried to start the telnet daemon but, after a few attempts, I found port 23 was specifically blocked by the appliance. I was eventually able to get a root shell running telnetd on another port:
GET /wifi?checkssid=$(telnetd -p 2280 &) 
 

Reading other parts, it appears to be BusyBox and Bash.

I would be shocked if there is a completely different OS on the OBi2 devices versus the OBi1 series.

I don't have an OBi1 device to test with.. Been looking at an OBi110, but the price of the OBi212 is very close or cheaper than I can find OBi110 units for.

In any case, I don't need it for GoogleVoice, just something to explore and figure out. :)

Hi mazilo, the spi header is labeled on the board already and I used a ft2232 based device with flashrom to dump the flash.

The obi 1xx/2xx will probably not have much in common at a binary level, though the 2xx firmware files may be useful in identifying and replacing the certificates.

Wanna post a link to mipsxdis (yahoo groups appears to not know about it anymore) and/or your dumped flash?

I have a 110 that suffers from periodic losses of IP for no apparent reason (other than perhaps old age), so it is relegated ye olde storage box. Willing to contribute it to the cause, PM me.

It is on the Yahoo group under PAP2 folder. You can run the disasm on the fw file too.

So the end of the firmware code is a routine to parse groups of 4 32-bit words.
If the first word is a 1, it does a memcpy from word2 to word3 with a count of word4
If the first word is a 2, it does a does a memset of 0 at word2 with a count of word3 (word4 ignored)
If the first word is a 3, it jumps (jspci?) to the location of word2
Then it grabs the next 4word record and repeats

Yes the loaders are very similar to what the pap2 does. The loader for section 3 is simple like you say but the loader for section 2 is more complex as it sets up registers and calls subroutines (probably gunzip). The overall memory layout is still confusing.

The bulk of the instructions in the third section (at 0x00213D1E) are an implementation of MD5: The sine of integers precomputed table is at 0x214FBE and the per-round shift amounts are hardcoded into the very repetitive lsr/lsl instructions.

Meanwhile, I need to find a computer with a parallel port to dump this flash unless someone sends me a link to theirs, wink wink.

37F3D0 - code
3BFCD0 - loader 1
3DB9A0 - code
3DFCD0 - loader 2
3F0030 - code (updater/md5)
3FFD44 - loader 3

3B81C4 - table 1
3DF6C4 - table 2
3FF13CC - table 3

It looks like for loader 1&2 which are the same that macro 8 (set r4) points to the start of the compressed section

If you copy 0x100 to 0x80000 and 0xF3CEE to 0x2D0000 then you will have the basic flash layout and we can reference flash addresses. The instruction to do this is at 0x50 in the firmware file. I can upload my flash dump after I remove the personal details if necessary.

The loader for section 2 starts at 0x3DFCD0 and the table is at 0x3DF6C4.

More than likely those other 2 code sections (they both the same) are an implementation of INFLATE. Some evidence: constants at (fw offset) 0x1a43b4 are the constant 'permutation of code lengths' from zlib's inflate.c, and signsrch claims theres more inflate-related consts around that address.

Maybe its time to just script trying INFLATE on various sections that we haven't already identified?

I like an ATA because it is possible to do isolation if you have an asterisk server be the only thing it can use to communicate. That kind of precludes this project though. Not necessarily. There could be something like u-boot on the device that allows for flashing unsigned firmware. So few embedded devices do signature verification that I doubt the obi100 does, but it is definitely possible.

The only problem is that binwalk produces nonsensical output on the obi100 firmware.

Congratulations. You have just found a GPL violation. With some luck, we could get Obihai to release at least some of the firmware source code for the Obi200 series. If we can find GPL code in the Obi100 series, we might be able to make the same case.

Does anyone know how much internal storage the obi100 has? If it is 4MB, maybe we could sequeeze LEDE with Asterisk onto the device so that we could have all of the sources and future changes by Google would be fixable. Otherwise, if Obihai discontinue support for configuring the obi100 devices for Google Voice remotely, people would have plenty of trouble working around that. LEDE+Asterisk would need people to develop a GUI too, but it might be worth considering.

Makes sense. I have sort of blindly tried ziprisc without success but will keep trying. Would have been really nice if pap2info source code was posted.

There appear to be 2 large (~40kb uncompressed) raw DEFLATE streams at (fw) 0x1a44c2 and 0x1aa7b6. The first one contains the string "talk.google.com" atleast...

I found 13 compressed sections, 4 of which fail to decompress with ziprisc due to length error. might be related to 09 macro value, padding?

Looking at the root certificates we find the Equifax 1024-bit SHA1 and so this is probably the deprecated certificate. There are other 2048-bit RSA certificates so we know that is supported. So maybe we can drop in the current Equifax 2048-bit RSA SHA1 certificate google is using but it expires in 9 months. Not sure whether OBI firmware supports SHA256.

By comparing the 3.1.1 and 3.2.1 firmwares for the Obi200 I was able to see that they added the GlobalSign R2 root certificate which is valid until 2021.

So I tried to insert the new certificate and hastily rebuild the firmware but got the christmas lights so probably it is checking checksums or hashes on each boot.

Mind moving slow today... help me with this math? 7C07CC --> 3807D4?

Well as mentioned the addressing is confusing but 7FFFFF = end of section, in this case 3BFFFF

How did you try injecting it? Remove an old cert and hope the deflate'd stream is smaller so as not to overwrite the next stream?

Yes when I tried to overwrite one certificate the stream became larger than original so I removed 2 certificates and added the other one and padded with 00. The certificates are all in a single null terminated string so should still be parsed correctly. The resulting stream was smaller than original so I padded with 00 to original length. Then I just flashed back to the device and got the red/green flashing led.

The streams that give ziprisc inflate length errors inflate fine, they just have length not multiple of 4 bytes and 2 byte padding is not consistent so may be garbage bytes.

Well, if it is inside a filesystem, then you just corrupted it. You need to replace just 1 larger certificate for that method to work. Not that I think that there is no checksum failure also occurring.

I don't think it is in a filesystem, just an embedded string.

There is an md5 hash at the beginning of the firmware section which covers the whole section (0x130000 bytes) and which is present in the update file. But when flashed to the device the unit info section of the flash falls within that range so would have to be ignored when verifying it. There is another 128bit value shortly following that md5 but I haven't been able to reproduce it.

Firmware section header

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
E3 93 51 9F EC 17 0C 8D 23 E7 32 E1 BF E8 1E 53 	MD5 of whole section
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
31 2E 33 2E 30 20 28 42 75 69 6C 64 3A 20 32 38	version string = 1.3.0 (Build: 2886) 
38 36 29 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 01 00 0F 3C EE 00 2D 00 00 00 13 00 00 	section index, file offset, flash offset, length
E8 1A D7 18 40 58 22 D1 23 BA CE F2 DE 7B 6C C3 	possible MD5??
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 

If it is an embedded string, you can change the length, but there likely are pointers to the string that follows it. Making it bigger than an existing string is a problem without understanding what references that area.

In the SPA firmware, there were two integrity checks in the firmware file. One was regular MD5. The other was MD5 of a byte stream. Each byte was the low 8 bits of the sum of the corresponding file byte and a variable that started at 0 and incremented by 13 (or maybe it was 0x13) for the next byte. I.e., 0 added to first byte, 13 added to second byte, 26 added to third byte, etc. Perhaps they are doing the same thing here, or something very similar.

If you are still having trouble when writing the flash directly, it may be useful to take smaller steps. First, write the flash with no mods at all to confirm that the process is working. Then, try modifying only one byte of a string that appears in the UI, chosen such that the deflated length does not change. Confirm that the modified string is displayed. If even this gives the flashing red/green, you can look for an integrity check. Is there a CRC associated with each deflate section, similar to a zip file?

Yes I preserved the size of the string with zero padding

Ok so I tried changing a single byte from the first MD5 in the header and the device booted. But when I changed a single byte from the second MD5 the christmas lights came back. So it seems the first MD5 is only checked during update (maybe?) but the second MD5 is checked at boot.

Wow that sounds anoying. There is a CRC at the end of each deflate section.

I'm posting the disassembly of the third section (which has the MD5 constants) in case anyone wants to look

 003F0030	 r29 -= 0x00D0
 003F0034	 (UI32)r29.0x00B0 = r16
 003F0038	 r16 = r29 +0x0098
 003F003C	 (UI32)r29.0x00C8 = r30
 003F0040	 (UI32)r29.0x00C4 = r21
 003F0044	 (UI32)r29.0x00B8 = r18
 003F0048	 (UI32)r29.0x00B4 = r17
 003F004C	 r18 = r4
 003F0050	 r17 = r29 +0x0040
 003F0054	 r21 = r5
 003F0058	 r4 = r16
 003F005C	 r5 = r25 -0x10000
 003F0060	 r30 = r6
 003F0064	 r6 = 0x0014
 003F0068	 (UI32)r29.0x00C0 = r20
 003F006C	 (UI32)r29.0x00BC = r19
 003F0070	 (UI32)r29.0x00CC = r31
 003F0074	 call (r24 + 0x044B)*4
 003F0078	 r4 = r17
 003F007C	 call (r24 + 0x00A3)*4
 003F0080	 r4 = r16
 003F0084	 call (r24 + 0x043E)*4
 003F0088	 r6 = r2
 003F008C	 r5 = r16
 003F0090	 r4 = r17
 003F0094	 call (r24 + 0x00AE)*4
 003F0098	 r20 = r29 +0x0030
 003F009C	 r5 = r21
 003F00A0	 r4 = r17
 003F00A4	 r6 = 0x0010
 003F00A8	 call (r24 + 0x00AE)*4
 003F00AC	 r21 += 0x0020
 003F00B0	 r4 = r17
 003F00B4	 r5 = r20
 003F00B8	 r6 = 0x0010
 003F00BC	 (UI32)r29.0x0030 = 0
 003F00C0	 (UI32)r29.0x0034 = 0
 003F00C4	 (UI32)r29.0x0038 = 0
 003F00C8	 (UI32)r29.0x003C = 0
 003F00CC	 r16 = r21 + r18
 003F00D0	 call (r24 + 0x00AE)*4
 003F00D4	 r19 = r29 +0x0010
 003F00D8	 r6 = r18 -0x0020
 003F00DC	 r5 = r21
 003F00E0	 r4 = r17
 003F00E4	 r21 = r16 -0x0020
 003F00E8	 call (r24 + 0x00AE)*4
 003F00EC	 r30 -= 0x0020
 003F00F0	 r5 = r21
 003F00F4	 r4 = r19
 003F00F8	 r6 = 0x0010
 003F00FC	 call (r24 + 0x044B)*4
 003F0100	 r18 = r30 - r18
 003F0104	 r5 = r20
 003F0108	 r4 = r17
 003F010C	 r6 = 0x0010
 003F0110	 call (r24 + 0x00AE)*4
 003F0114	 r21 = r16 -0x0010
 003F0118	 r30 = r18 +0x0010
 003F011C	 r16 = r29 +0x0020
 003F0120	 r6 = r30
 003F0124	 r4 = r17
 003F0128	 r5 = r21
 003F012C	 call (r24 + 0x00AE)*4
 003F0130	 r5 = r17
 003F0134	 r4 = r16
 003F0138	 call (r24 + 0x00E4)*4
 003F013C	 r4 = r19
 003F0140	 r5 = r16
 003F0144	 r6 = 0x0010
 003F0148	 call (r24 + 0x0478)*4
 003F014C	 r3 = r2
 003F0150	 r2 = 0x0000
 003F0154	 if (r3==0) goto $003F0180
 003F0158	 r31 = (UI32)r29.0x00CC
 003F015C	 r30 = (UI32)r29.0x00C8
 003F0160	 r21 = (UI32)r29.0x00C4
 003F0164	 r20 = (UI32)r29.0x00C0
 003F0168	 r19 = (UI32)r29.0x00BC
 003F016C	 r18 = (UI32)r29.0x00B8
 003F0170	 r17 = (UI32)r29.0x00B4
 003F0174	 r16 = (UI32)r29.0x00B0
 003F0178	 r29 += 0x00D0
 003F017C	 return
 003F0180	 r2 = 0x0001
 003F0184	 call (r24 + 0x004A)*4
 003F0188	 r2 = (UI32)-0xFFEC[r25]
 003F018C	 r29 -= 0x0118
 003F0190	 r2 -= r4
 003F0194	 (UI32)r29.0x0114 = r31
 003F0198	 (UI32)r29.0x0110 = r16
 003F019C	 r4 = (UI32)-0x0004[r2]
 003F01A0	 r3 = (UI32)-0xFFE8[r25]
 003F01A4	 r3 -= r4
 003F01A8	 r4 = (UI32)-0xFFE4[r25]
 003F01AC	 r5 = r2 - r3
 003F01B0	 r3 += r4
 003F01B4	 r4 = (UI32)-0xFFE0[r25]
 003F01B8	 r2 = 0x0000
 003F01BC	 if u(r4<r3) goto $003F0204
 003F01C0	 r7 = (UI32)*r5
 003F01C4	 r3 = (UI32)-0xFFDC[r25]
 003F01C8	 r16 = r5 - r7
 003F01CC	 r4 = r29 +0x0010
 003F01D0	 r6 = 0x0100
 003F01D4	 r5 = r16
 003F01D8	 if u(r3<r7) goto $003F0204
 003F01DC	 call (r24 + 0x044B)*4
 003F01E0	 r6 = (UI32)r29.0x00BC
 003F01E4	 r2 = (UI32)-0xFFD8[r25]
 003F01E8	 r5 = r16
 003F01EC	 r6 += r2
 003F01F0	 r4 = 0x00B0
 003F01F4	 call (r24 + 0x0000)*4
 003F01F8	 r3 = r2
 003F01FC	 if (r3==0) goto $003F0204
 003F0200	 r2 = 0x0001
 003F0204	 r31 = (UI32)r29.0x0114
 003F0208	 r16 = (UI32)r29.0x0110
 003F020C	 r29 += 0x0118
 003F0210	 return
 003F0214	 r29 -= 0x0020
 003F0218	 (UI32)r29.0x0014 = r17
 003F021C	 (UI32)r29.0x0018 = r31
 003F0220	 (UI32)r29.0x0010 = r16
 003F0224	 r17 = (UI32)-0xFFD4[r25]
 003F0228	 r27 = (UI32)-0xFFD0[r25]
 003F022C	 r22 = 0x0080
 003F0230	 r22 = r22 <<16
 003F0234	 r26 = 0x1D00
 003F0238	 r26 = r26 <<16
 003F023C	 r2 = r26 - r17
 003F0240	 r4 = (UI32)-0x0004[r2]
 003F0244	 r3 = (UI32)r27.0x3040
 003F0248	 r2 = r22 - r4
 003F024C	 r16 = r2 + r17
 003F0250	 r4 = r16
 003F0254	 call (r24 + 0x0056)*4
 003F0258	 if (r2==0) goto $003F0260
 003F025C	 r17 = r16
 003F0260	 r2 = r26 - r17
 003F0264	 r4 = (UI32)-0x0004[r2]
 003F0268	 r3 = r2
 003F026C	 r6 = r22 - r4
 003F0270	 r5 = 0x0000
 003F0274	 r3 -= r6
 003F0278	 if s(r5>=r6) goto $003F0294
 003F027C	 r2 = (UI32)*r3
 003F0280	 r5 += 0x0004
 003F0284	 (UI32)*r4 = r2
 003F0288	 r3 += 0x0004
 003F028C	 r4 += 0x0004
 003F0290	 if s(r5<r6) goto $003F027C
 003F0294	 r22 = 0x0080
 003F0298	 r22 = r22 <<16
 003F029C	 r22 = (signed)r22 >>2
 003F02A0	 r22 -= 0x0004
 003F02A4	 call (r22 + 0x0000)*4
 003F02A8	 r31 = (UI32)r29.0x0018
 003F02AC	 r17 = (UI32)r29.0x0014
 003F02B0	 r16 = (UI32)r29.0x0010
 003F02B4	 r29 += 0x0020
 003F02B8	 return
 003F02BC	 r2 = (UI32)-0xFF8C[r25]
 003F02C0	 r3 = (UI32)-0xFF88[r25]
 003F02C4	 (UI32)r4.0x000C = r2
 003F02C8	 (UI32)*r4 = r3
 003F02CC	 r2 = (UI32)-0xFF84[r25]
 003F02D0	 r3 = (UI32)-0xFF80[r25]
 003F02D4	 (UI32)r4.0x0004 = r2
 003F02D8	 (UI32)r4.0x0008 = r3
 003F02DC	 (UI32)r4.0x0014 = 0
 003F02E0	 (UI32)r4.0x0010 = 0
 003F02E4	 return
 003F02E8	 r29 -= 0x0028
 003F02EC	 (UI32)r29.0x001C = r19
 003F02F0	 (UI32)r29.0x0018 = r18
 003F02F4	 (UI32)r29.0x0014 = r17
 003F02F8	 (UI32)r29.0x0020 = r31
 003F02FC	 r17 = r4
 003F0300	 (UI32)r29.0x0010 = r16
 003F0304	 r2 = (UI32)r17.0x0010
 003F0308	 r18 = r6
 003F030C	 r4 = r18 <<3
 003F0310	 r3 = r2 + r4
 003F0314	 r2 = r2 >>3
 003F0318	 r6 = r2 & 0x003F
 003F031C	 (UI32)r17.0x0010 = r3
 003F0320	 r19 = r5
 003F0324	 if u(r3>=r4) goto $003F0334
 003F0328	 r2 = (UI32)r17.0x0014
 003F032C	 r2++
 003F0330	 (UI32)r17.0x0014 = r2
 003F0334	 r2 = (UI32)r17.0x0014
 003F0338	 r3 = r18 >>29
 003F033C	 r4 = 0x0040
 003F0340	 r2 += r3
 003F0344	 r16 = r4 - r6
 003F0348	 (UI32)r17.0x0014 = r2
 003F034C	 if u(r18<r16) goto $003F03B8
 003F0350	 r4 = r17 + r6
 003F0354	 r4 += 0x0018
 003F0358	 r6 = r16
 003F035C	 call (r24 + 0x042D)*4
 003F0360	 r5 = r17 +0x0018
 003F0364	 r4 = r17
 003F0368	 call (r24 + 0x00D2)*4
 003F036C	 r5 = r19 + r16
 003F0370	 r4 = r17
 003F0374	 r16 += 0x0040
 003F0378	 call (r24 + 0x010B)*4
 003F037C	 r2 = r16 +0x003F
 003F0380	 if u(r2<r18) goto $003F036C
 003F0384	 r6 = 0x0000
 003F0388	 r4 = r17 + r6
 003F038C	 r5 = r19 + r16
 003F0390	 r6 = r18 - r16
 003F0394	 r4 += 0x0018
 003F0398	 call (r24 + 0x042D)*4
 003F039C	 r31 = (UI32)r29.0x0020
 003F03A0	 r19 = (UI32)r29.0x001C
 003F03A4	 r18 = (UI32)r29.0x0018
 003F03A8	 r17 = (UI32)r29.0x0014
 003F03AC	 r16 = (UI32)r29.0x0010
 003F03B0	 r29 += 0x0028
 003F03B4	 return
 003F03B8	 r16 = 0x0000
 003F03BC	 call (r24 + 0x00D6)*4
 003F03C0	 r29 -= 0x0028
 003F03C4	 (UI32)r29.0x0018 = r16
 003F03C8	 r16 = r5
 003F03CC	 (UI32)r29.0x001C = r17
 003F03D0	 r6 = 0x0008
 003F03D4	 r5 = r16 +0x0010
 003F03D8	 r17 = r4
 003F03DC	 r4 = r29 +0x0010
 003F03E0	 (UI32)r29.0x0020 = r31
 003F03E4	 call (r24 + 0x0406)*4
 003F03E8	 r2 = (UI32)r16.0x0010
 003F03EC	 r3 = 0x0038
 003F03F0	 r2 = r2 >>3
 003F03F4	 r4 = r2 & 0x003F
 003F03F8	 r2 = 0x0037
 003F03FC	 r6 = r3 - r4
 003F0400	 if u(r2>=r4) goto $003F040C
 003F0404	 r2 = 0x0078
 003F0408	 r6 = r2 - r4
 003F040C	 r4 = r16
 003F0410	 r5 = r25 -0xFFCC
 003F0414	 call (r24 + 0x00AE)*4
 003F0418	 r5 = r29 +0x0010
 003F041C	 r4 = r16
 003F0420	 r6 = 0x0008
 003F0424	 call (r24 + 0x00AE)*4
 003F0428	 r4 = r17
 003F042C	 r5 = r16
 003F0430	 r6 = 0x0010
 003F0434	 call (r24 + 0x0406)*4
 003F0438	 r4 = r16
 003F043C	 r5 = 0x0000
 003F0440	 r6 = 0x0058
 003F0444	 call (r24 + 0x0437)*4
 003F0448	 r31 = (UI32)r29.0x0020
 003F044C	 r17 = (UI32)r29.0x001C
 003F0450	 r16 = (UI32)r29.0x0018
 003F0454	 r29 += 0x0028
 003F0458	 return
 003F045C	 r29 -= 0x0070
 003F0460	 (UI32)r29.0x006C = r31
 003F0464	 (UI32)r29.0x0058 = r18
 003F0468	 (UI32)r29.0x0054 = r17
 003F046C	 (UI32)r29.0x0050 = r16
 003F0470	 (UI32)r29.0x0068 = r30
 003F0474	 r16 = r4
 003F0478	 (UI32)r29.0x0064 = r21
 003F047C	 (UI32)r29.0x0060 = r20
 003F0480	 (UI32)r29.0x005C = r19
 003F0484	 r21 = (UI32)r16.0x0004
 003F0488	 r20 = (UI32)r16.0x0008
 003F048C	 r19 = (UI32)r16.0x000C
 003F0490	 r4 = r29 +0x0010
 003F0494	 r6 = 0x0040
 003F0498	 r30 = (UI32)*r16
 003F049C	 call (r24 + 0x0417)*4
 003F04A0	 r15 = (UI32)r29.0x0010
 003F04A4	 r3 =(~r21) & r19
 003F04A8	 r2 = r21 & r20
 003F04AC	 r2 |= r3
 003F04B0	 r2 += r15
 003F04B4	 r3 = (UI32)-0xFF7C[r25]
 003F04B8	 r2 += r30
 003F04BC	 r30 = r2 + r3
 003F04C0	 r4 = r30 >>25
 003F04C4	 r2 = r30 <<7
 003F04C8	 r30 = r2 | r4
 003F04CC	 r30 += r21
 003F04D0	 r3 =(~r30) & r20
 003F04D4	 r2 = r30 & r21
 003F04D8	 r2 |= r3
 003F04DC	 r3 = (UI32)r29.0x0014
 003F04E0	 r18 = (UI32)r29.0x001C
 003F04E4	 r2 += r3
 003F04E8	 r3 = (UI32)-0xFF78[r25]
 003F04EC	 r2 += r19
 003F04F0	 r19 = r2 + r3
 003F04F4	 r4 = r19 >>20
 003F04F8	 r2 = r19 <<12
 003F04FC	 r19 = r2 | r4
 003F0500	 r19 += r30
 003F0504	 r3 =(~r19) & r21
 003F0508	 r2 = r19 & r30
 003F050C	 r2 |= r3
 003F0510	 r3 = (UI32)r29.0x0018
 003F0514	 r13 = (UI32)r29.0x0024
 003F0518	 r2 += r3
 003F051C	 r3 = (UI32)-0xFF74[r25]
 003F0520	 r2 += r20
 003F0524	 r20 = r2 + r3
 003F0528	 r4 = r20 >>15
 003F052C	 r2 = r20 <<17
 003F0530	 r20 = r2 | r4
 003F0534	 r20 += r19
 003F0538	 r3 =(~r20) & r30
 003F053C	 r2 = r20 & r19
 003F0540	 r2 |= r3
 003F0544	 r2 += r18
 003F0548	 r3 = (UI32)-0xFF70[r25]
 003F054C	 r2 += r21
 003F0550	 r21 = r2 + r3
 003F0554	 r4 = r21 >>10
 003F0558	 r2 = r21 <<22
 003F055C	 r21 = r2 | r4
 003F0560	 r21 += r20
 003F0564	 r3 =(~r21) & r19
 003F0568	 r2 = r21 & r20
 003F056C	 r2 |= r3
 003F0570	 r3 = (UI32)r29.0x0020
 003F0574	 r10 = (UI32)r29.0x002C
 003F0578	 r2 += r3
 003F057C	 r3 = (UI32)-0xFF6C[r25]
 003F0580	 r2 += r30
 003F0584	 r30 = r2 + r3
 003F0588	 r4 = r30 >>25
 003F058C	 r2 = r30 <<7
 003F0590	 r30 = r2 | r4
 003F0594	 r30 += r21
 003F0598	 r3 =(~r30) & r20
 003F059C	 r2 = r30 & r21
 003F05A0	 r2 |= r3
 003F05A4	 r2 += r13
 003F05A8	 r3 = (UI32)-0xFF68[r25]
 003F05AC	 r2 += r19
 003F05B0	 r19 = r2 + r3
 003F05B4	 r4 = r19 >>20
 003F05B8	 r2 = r19 <<12
 003F05BC	 r19 = r2 | r4
 003F05C0	 r19 += r30
 003F05C4	 r3 =(~r19) & r21
 003F05C8	 r2 = r19 & r30
 003F05CC	 r2 |= r3
 003F05D0	 r3 = (UI32)r29.0x0028
 003F05D4	 r14 = (UI32)r29.0x0030
 003F05D8	 r2 += r3
 003F05DC	 r3 = (UI32)-0xFF64[r25]
 003F05E0	 r2 += r20
 003F05E4	 r20 = r2 + r3
 003F05E8	 r4 = r20 >>15
 003F05EC	 r2 = r20 <<17
 003F05F0	 r20 = r2 | r4
 003F05F4	 r20 += r19
 003F05F8	 r3 =(~r20) & r30
 003F05FC	 r2 = r20 & r19
 003F0600	 r2 |= r3
 003F0604	 r2 += r10
 003F0608	 r3 = (UI32)-0xFF60[r25]
 003F060C	 r2 += r21
 003F0610	 r21 = r2 + r3
 003F0614	 r4 = r21 >>10
 003F0618	 r2 = r21 <<22
 003F061C	 r21 = r2 | r4
 003F0620	 r21 += r20
 003F0624	 r3 =(~r21) & r19
 003F0628	 r2 = r21 & r20
 003F062C	 r2 |= r3
 003F0630	 r2 += r14
 003F0634	 r3 = (UI32)-0xFF5C[r25]
 003F0638	 r2 += r30
 003F063C	 r30 = r2 + r3
 003F0640	 r4 = r30 >>25
 003F0644	 r2 = r30 <<7
 003F0648	 r30 = r2 | r4
 003F064C	 r30 += r21
 003F0650	 r3 =(~r30) & r20
 003F0654	 r2 = r30 & r21
 003F0658	 r2 |= r3
 003F065C	 r3 = (UI32)r29.0x0034
 003F0660	 r11 = (UI32)r29.0x0038
 003F0664	 r2 += r3
 003F0668	 r3 = (UI32)-0xFF58[r25]
 003F066C	 r2 += r19
 003F0670	 r19 = r2 + r3
 003F0674	 r4 = r19 >>20
 003F0678	 r2 = r19 <<12
 003F067C	 r19 = r2 | r4
 003F0680	 r19 += r30
 003F0684	 r3 =(~r19) & r21
 003F0688	 r2 = r19 & r30
 003F068C	 r2 |= r3
 003F0690	 r2 += r11
 003F0694	 r2 += r20
 003F0698	 r20 = r2 -0xA44F
 003F069C	 r3 = r20 >>15
 003F06A0	 r2 = r20 <<17
 003F06A4	 r20 = r2 | r3
 003F06A8	 r20 += r19
 003F06AC	 r17 = (UI32)r29.0x003C
 003F06B0	 r3 =(~r20) & r30
 003F06B4	 r2 = r20 & r19
 003F06B8	 r2 |= r3
 003F06BC	 r2 += r17
 003F06C0	 r3 = (UI32)-0xFF54[r25]
 003F06C4	 r2 += r21
 003F06C8	 r21 = r2 + r3
 003F06CC	 r4 = r21 >>10
 003F06D0	 r2 = r21 <<22
 003F06D4	 r21 = r2 | r4
 003F06D8	 r21 += r20
 003F06DC	 r8 = (UI32)r29.0x0040
 003F06E0	 r3 =(~r21) & r19
 003F06E4	 r2 = r21 & r20
 003F06E8	 r2 |= r3
 003F06EC	 r2 += r8
 003F06F0	 r3 = (UI32)-0xFF50[r25]
 003F06F4	 r2 += r30
 003F06F8	 r30 = r2 + r3
 003F06FC	 r4 = r30 >>25
 003F0700	 r2 = r30 <<7
 003F0704	 r30 = r2 | r4
 003F0708	 r30 += r21
 003F070C	 r12 = (UI32)r29.0x0044
 003F0710	 r3 =(~r30) & r20
 003F0714	 r2 = r30 & r21
 003F0718	 r2 |= r3
 003F071C	 r2 += r12
 003F0720	 r3 = (UI32)-0xFF4C[r25]
 003F0724	 r2 += r19
 003F0728	 r19 = r2 + r3
 003F072C	 r4 = r19 >>20
 003F0730	 r2 = r19 <<12
 003F0734	 r19 = r2 | r4
 003F0738	 r19 += r30
 003F073C	 r6 = ~r19
 003F0740	 r7 = (UI32)r29.0x0048
 003F0744	 r3 = r6 & r21
 003F0748	 r2 = r19 & r30
 003F074C	 r2 |= r3
 003F0750	 r2 += r7
 003F0754	 r3 = (UI32)-0xFF48[r25]
 003F0758	 r2 += r20
 003F075C	 r20 = r2 + r3
 003F0760	 r4 = r20 >>15
 003F0764	 r2 = r20 <<17
 003F0768	 r20 = r2 | r4
 003F076C	 r20 += r19
 003F0770	 r5 = ~r20
 003F0774	 r9 = (UI32)r29.0x004C
 003F0778	 r3 = r5 & r30
 003F077C	 r2 = r20 & r19
 003F0780	 r2 |= r3
 003F0784	 r2 += r9
 003F0788	 r3 = (UI32)-0xFF44[r25]
 003F078C	 r2 += r21
 003F0790	 r21 = r2 + r3
 003F0794	 r4 = r21 >>10
 003F0798	 r2 = r21 <<22
 003F079C	 r21 = r2 | r4
 003F07A0	 r21 += r20
 003F07A4	 r3 = (UI32)r29.0x0014
 003F07A8	 r6 = r20 & r6
 003F07AC	 r2 = r21 & r19
 003F07B0	 r2 |= r6
 003F07B4	 r2 += r3
 003F07B8	 r3 = (UI32)-0xFF40[r25]
 003F07BC	 r2 += r30
 003F07C0	 r30 = r2 + r3
 003F07C4	 r4 = r30 >>27
 003F07C8	 r2 = r30 <<5
 003F07CC	 r30 = r2 | r4
 003F07D0	 r30 += r21
 003F07D4	 r3 = (UI32)r29.0x0028
 003F07D8	 r5 = r21 & r5
 003F07DC	 r2 = r30 & r20
 003F07E0	 r2 |= r5
 003F07E4	 r2 += r3
 003F07E8	 r3 = (UI32)-0xFF3C[r25]
 003F07EC	 r2 += r19
 003F07F0	 r19 = r2 + r3
 003F07F4	 r4 = r19 >>23
 003F07F8	 r2 = r19 <<9
 003F07FC	 r19 = r2 | r4
 003F0800	 r19 += r30
 003F0804	 r3 =(~r21) & r30
 003F0808	 r2 = r19 & r21
 003F080C	 r2 |= r3
 003F0810	 r2 += r17
 003F0814	 r3 = (UI32)-0xFF38[r25]
 003F0818	 r2 += r20
 003F081C	 r20 = r2 + r3
 003F0820	 r4 = r20 >>18
 003F0824	 r2 = r20 <<14
 003F0828	 r20 = r2 | r4
 003F082C	 r20 += r19
 003F0830	 r3 =(~r30) & r19
 003F0834	 r2 = r20 & r30
 003F0838	 r2 |= r3
 003F083C	 r2 += r15
 003F0840	 r3 = (UI32)-0xFF34[r25]
 003F0844	 r2 += r21
 003F0848	 r21 = r2 + r3
 003F084C	 r4 = r21 >>12
 003F0850	 r2 = r21 <<20
 003F0854	 r21 = r2 | r4
 003F0858	 r21 += r20
 003F085C	 r3 =(~r19) & r20
 003F0860	 r2 = r21 & r19
 003F0864	 r2 |= r3
 003F0868	 r2 += r13
 003F086C	 r3 = (UI32)-0xFF30[r25]
 003F0870	 r2 += r30
 003F0874	 r30 = r2 + r3
 003F0878	 r4 = r30 >>27
 003F087C	 r2 = r30 <<5
 003F0880	 r30 = r2 | r4
 003F0884	 r30 += r21
 003F0888	 r3 =(~r20) & r21
 003F088C	 r2 = r30 & r20
 003F0890	 r2 |= r3
 003F0894	 r2 += r11
 003F0898	 r3 = (UI32)-0xFF2C[r25]
 003F089C	 r2 += r19
 003F08A0	 r19 = r2 + r3
 003F08A4	 r4 = r19 >>23
 003F08A8	 r2 = r19 <<9
 003F08AC	 r19 = r2 | r4
 003F08B0	 r19 += r30
 003F08B4	 r3 =(~r21) & r30
 003F08B8	 r2 = r19 & r21
 003F08BC	 r2 |= r3
 003F08C0	 r2 += r9
 003F08C4	 r3 = (UI32)-0xFF28[r25]
 003F08C8	 r2 += r20
 003F08CC	 r20 = r2 + r3
 003F08D0	 r4 = r20 >>18
 003F08D4	 r2 = r20 <<14
 003F08D8	 r20 = r2 | r4
 003F08DC	 r20 += r19
 003F08E0	 r3 =(~r30) & r19
 003F08E4	 r2 = r20 & r30
 003F08E8	 r2 |= r3
 003F08EC	 r3 = (UI32)r29.0x0020
 003F08F0	 r5 = (UI32)r16.0x0008
 003F08F4	 r2 += r3
 003F08F8	 r3 = (UI32)-0xFF24[r25]
 003F08FC	 r2 += r21
 003F0900	 r21 = r2 + r3
 003F0904	 r4 = r21 >>12
 003F0908	 r2 = r21 <<20
 003F090C	 r21 = r2 | r4
 003F0910	 r21 += r20
 003F0914	 r3 =(~r19) & r20
 003F0918	 r2 = r21 & r19
 003F091C	 r2 |= r3
 003F0920	 r3 = (UI32)r29.0x0034
 003F0924	 r6 = 0x0040
 003F0928	 r2 += r3
 003F092C	 r3 = (UI32)-0xFF20[r25]
 003F0930	 r2 += r30
 003F0934	 r30 = r2 + r3
 003F0938	 r4 = r30 >>27
 003F093C	 r2 = r30 <<5
 003F0940	 r30 = r2 | r4
 003F0944	 r30 += r21
 003F0948	 r3 =(~r20) & r21
 003F094C	 r2 = r30 & r20
 003F0950	 r2 |= r3
 003F0954	 r2 += r7
 003F0958	 r3 = (UI32)-0xFF1C[r25]
 003F095C	 r2 += r19
 003F0960	 r19 = r2 + r3
 003F0964	 r4 = r19 >>23
 003F0968	 r2 = r19 <<9
 003F096C	 r19 = r2 | r4
 003F0970	 r19 += r30
 003F0974	 r3 =(~r21) & r30
 003F0978	 r2 = r19 & r21
 003F097C	 r2 |= r3
 003F0980	 r2 += r18
 003F0984	 r3 = (UI32)-0xFF18[r25]
 003F0988	 r2 += r20
 003F098C	 r20 = r2 + r3
 003F0990	 r4 = r20 >>18
 003F0994	 r2 = r20 <<14
 003F0998	 r20 = r2 | r4
 003F099C	 r20 += r19
 003F09A0	 r3 =(~r30) & r19
 003F09A4	 r2 = r20 & r30
 003F09A8	 r2 |= r3
 003F09AC	 r2 += r14
 003F09B0	 r3 = (UI32)-0xFF14[r25]
 003F09B4	 r2 += r21
 003F09B8	 r21 = r2 + r3
 003F09BC	 r4 = r21 >>12
 003F09C0	 r2 = r21 <<20
 003F09C4	 r21 = r2 | r4
 003F09C8	 r21 += r20
 003F09CC	 r3 =(~r19) & r20
 003F09D0	 r2 = r21 & r19
 003F09D4	 r2 |= r3
 003F09D8	 r2 += r12
 003F09DC	 r3 = (UI32)-0xFF10[r25]
 003F09E0	 r2 += r30
 003F09E4	 r30 = r2 + r3
 003F09E8	 r4 = r30 >>27
 003F09EC	 r2 = r30 <<5
 003F09F0	 r30 = r2 | r4
 003F09F4	 r30 += r21
 003F09F8	 r3 =(~r20) & r21
 003F09FC	 r2 = r30 & r20
 003F0A00	 r2 |= r3
 003F0A04	 r3 = (UI32)r29.0x0018
 003F0A08	 r2 += r3
 003F0A0C	 r3 = (UI32)-0xFF0C[r25]
 003F0A10	 r2 += r19
 003F0A14	 r19 = r2 + r3
 003F0A18	 r4 = r19 >>23
 003F0A1C	 r2 = r19 <<9
 003F0A20	 r19 = r2 | r4
 003F0A24	 r19 += r30
 003F0A28	 r3 =(~r21) & r30
 003F0A2C	 r2 = r19 & r21
 003F0A30	 r2 |= r3
 003F0A34	 r2 += r10
 003F0A38	 r3 = (UI32)-0xFF08[r25]
 003F0A3C	 r2 += r20
 003F0A40	 r20 = r2 + r3
 003F0A44	 r4 = r20 >>18
 003F0A48	 r2 = r20 <<14
 003F0A4C	 r20 = r2 | r4
 003F0A50	 r20 += r19
 003F0A54	 r3 =(~r30) & r19
 003F0A58	 r2 = r20 & r30
 003F0A5C	 r2 |= r3
 003F0A60	 r2 += r8
 003F0A64	 r3 = (UI32)-0xFF04[r25]
 003F0A68	 r2 += r21
 003F0A6C	 r21 = r2 + r3
 003F0A70	 r4 = r21 >>12
 003F0A74	 r2 = r21 <<20
 003F0A78	 r21 = r2 | r4
 003F0A7C	 r21 += r20
 003F0A80	 r2 = r21 ^ r20
 003F0A84	 r2 ^= r19
 003F0A88	 r2 += r13
 003F0A8C	 r3 = (UI32)-0xFF00[r25]
 003F0A90	 r2 += r30
 003F0A94	 r30 = r2 + r3
 003F0A98	 r4 = r30 >>28
 003F0A9C	 r2 = r30 <<4
 003F0AA0	 r30 = r2 | r4
 003F0AA4	 r30 += r21
 003F0AA8	 r2 = r30 ^ r21
 003F0AAC	 r2 ^= r20
 003F0AB0	 r2 += r14
 003F0AB4	 r3 = (UI32)-0xFEFC[r25]
 003F0AB8	 r2 += r19
 003F0ABC	 r19 = r2 + r3
 003F0AC0	 r4 = r19 >>21
 003F0AC4	 r2 = r19 <<11
 003F0AC8	 r19 = r2 | r4
 003F0ACC	 r19 += r30
 003F0AD0	 r2 = r19 ^ r30
 003F0AD4	 r2 ^= r21
 003F0AD8	 r2 += r17
 003F0ADC	 r3 = (UI32)-0xFEF8[r25]
 003F0AE0	 r2 += r20
 003F0AE4	 r20 = r2 + r3
 003F0AE8	 r4 = r20 >>16
 003F0AEC	 r2 = r20 <<16
 003F0AF0	 r20 = r2 | r4
 003F0AF4	 r20 += r19
 003F0AF8	 r2 = r20 ^ r19
 003F0AFC	 r2 ^= r30
 003F0B00	 r2 += r7
 003F0B04	 r3 = (UI32)-0xFEF4[r25]
 003F0B08	 r2 += r21
 003F0B0C	 r21 = r2 + r3
 003F0B10	 r4 = r21 >>9
 003F0B14	 r2 = r21 <<23
 003F0B18	 r21 = r2 | r4
 003F0B1C	 r21 += r20
 003F0B20	 r3 = (UI32)r29.0x0014
 003F0B24	 r2 = r21 ^ r20
 003F0B28	 r2 ^= r19
 003F0B2C	 r2 += r3
 003F0B30	 r3 = (UI32)-0xFEF0[r25]
 003F0B34	 r2 += r30
 003F0B38	 r30 = r2 + r3
 003F0B3C	 r4 = r30 >>28
 003F0B40	 r2 = r30 <<4
 003F0B44	 r30 = r2 | r4
 003F0B48	 r30 += r21
 003F0B4C	 r3 = (UI32)r29.0x0020
 003F0B50	 r2 = r30 ^ r21
 003F0B54	 r2 ^= r20
 003F0B58	 r2 += r3
 003F0B5C	 r3 = (UI32)-0xFEEC[r25]
 003F0B60	 r2 += r19
 003F0B64	 r19 = r2 + r3
 003F0B68	 r4 = r19 >>21
 003F0B6C	 r2 = r19 <<11
 003F0B70	 r19 = r2 | r4
 003F0B74	 r19 += r30
 003F0B78	 r2 = r19 ^ r30
 003F0B7C	 r2 ^= r21
 003F0B80	 r2 += r10
 003F0B84	 r3 = (UI32)-0xFEE8[r25]
 003F0B88	 r2 += r20
 003F0B8C	 r20 = r2 + r3
 003F0B90	 r4 = r20 >>16
 003F0B94	 r2 = r20 <<16
 003F0B98	 r20 = r2 | r4
 003F0B9C	 r20 += r19
 003F0BA0	 r2 = r20 ^ r19
 003F0BA4	 r2 ^= r30
 003F0BA8	 r2 += r11
 003F0BAC	 r3 = (UI32)-0xFEE4[r25]
 003F0BB0	 r2 += r21
 003F0BB4	 r21 = r2 + r3
 003F0BB8	 r4 = r21 >>9
 003F0BBC	 r2 = r21 <<23
 003F0BC0	 r21 = r2 | r4
 003F0BC4	 r21 += r20
 003F0BC8	 r2 = r21 ^ r20
 003F0BCC	 r2 ^= r19
 003F0BD0	 r2 += r12
 003F0BD4	 r3 = (UI32)-0xFEE0[r25]
 003F0BD8	 r2 += r30
 003F0BDC	 r30 = r2 + r3
 003F0BE0	 r4 = r30 >>28
 003F0BE4	 r2 = r30 <<4
 003F0BE8	 r30 = r2 | r4
 003F0BEC	 r30 += r21
 003F0BF0	 r2 = r30 ^ r21
 003F0BF4	 r2 ^= r20
 003F0BF8	 r2 += r15
 003F0BFC	 r3 = (UI32)-0xFEDC[r25]
 003F0C00	 r2 += r19
 003F0C04	 r19 = r2 + r3
 003F0C08	 r4 = r19 >>21
 003F0C0C	 r2 = r19 <<11
 003F0C10	 r19 = r2 | r4
 003F0C14	 r19 += r30
 003F0C18	 r2 = r19 ^ r30
 003F0C1C	 r2 ^= r21
 003F0C20	 r2 += r18
 003F0C24	 r3 = (UI32)-0xFED8[r25]
 003F0C28	 r2 += r20
 003F0C2C	 r20 = r2 + r3
 003F0C30	 r4 = r20 >>16
 003F0C34	 r2 = r20 <<16
 003F0C38	 r20 = r2 | r4
 003F0C3C	 r20 += r19
 003F0C40	 r3 = (UI32)r29.0x0028
 003F0C44	 r2 = r20 ^ r19
 003F0C48	 r2 ^= r30
 003F0C4C	 r2 += r3
 003F0C50	 r3 = (UI32)-0xFED4[r25]
 003F0C54	 r2 += r21
 003F0C58	 r21 = r2 + r3
 003F0C5C	 r4 = r21 >>9
 003F0C60	 r2 = r21 <<23
 003F0C64	 r21 = r2 | r4
 003F0C68	 r21 += r20
 003F0C6C	 r3 = (UI32)r29.0x0034
 003F0C70	 r2 = r21 ^ r20
 003F0C74	 r2 ^= r19
 003F0C78	 r2 += r3
 003F0C7C	 r3 = (UI32)-0xFED0[r25]
 003F0C80	 r2 += r30
 003F0C84	 r30 = r2 + r3
 003F0C88	 r4 = r30 >>28
 003F0C8C	 r2 = r30 <<4
 003F0C90	 r30 = r2 | r4
 003F0C94	 r30 += r21
 003F0C98	 r2 = r30 ^ r21
 003F0C9C	 r2 ^= r20
 003F0CA0	 r2 += r8
 003F0CA4	 r3 = (UI32)-0xFECC[r25]
 003F0CA8	 r2 += r19
 003F0CAC	 r19 = r2 + r3
 003F0CB0	 r4 = r19 >>21
 003F0CB4	 r2 = r19 <<11
 003F0CB8	 r19 = r2 | r4
 003F0CBC	 r19 += r30
 003F0CC0	 r2 = r19 ^ r30
 003F0CC4	 r2 ^= r21
 003F0CC8	 r2 += r9
 003F0CCC	 r3 = (UI32)-0xFEC8[r25]
 003F0CD0	 r2 += r20
 003F0CD4	 r20 = r2 + r3
 003F0CD8	 r4 = r20 >>16
 003F0CDC	 r2 = r20 <<16
 003F0CE0	 r20 = r2 | r4
 003F0CE4	 r20 += r19
 003F0CE8	 r3 = (UI32)r29.0x0018
 003F0CEC	 r2 = r20 ^ r19
 003F0CF0	 r2 ^= r30
 003F0CF4	 r2 += r3
 003F0CF8	 r3 = (UI32)-0xFEC4[r25]
 003F0CFC	 r2 += r21
 003F0D00	 r21 = r2 + r3
 003F0D04	 r4 = r21 >>9
 003F0D08	 r2 = r21 <<23
 003F0D0C	 r21 = r2 | r4
 003F0D10	 r21 += r20
 003F0D14	 r2 = ~r19
 003F0D18	 r2 = r21 | r2
 003F0D1C	 r2 = r20 ^ r2
 003F0D20	 r2 += r15
 003F0D24	 r3 = (UI32)-0xFEC0[r25]
 003F0D28	 r2 += r30
 003F0D2C	 r30 = r2 + r3
 003F0D30	 r4 = r30 >>26
 003F0D34	 r2 = r30 <<6
 003F0D38	 r30 = r2 | r4
 003F0D3C	 r30 += r21
 003F0D40	 r2 = ~r20
 003F0D44	 r2 = r30 | r2
 003F0D48	 r2 = r21 ^ r2
 003F0D4C	 r2 += r10
 003F0D50	 r3 = (UI32)-0xFEBC[r25]
 003F0D54	 r2 += r19
 003F0D58	 r19 = r2 + r3
 003F0D5C	 r4 = r19 >>22
 003F0D60	 r2 = r19 <<10
 003F0D64	 r19 = r2 | r4
 003F0D68	 r19 += r30
 003F0D6C	 r2 = ~r21
 003F0D70	 r2 = r19 | r2
 003F0D74	 r2 = r30 ^ r2
 003F0D78	 r2 += r7
 003F0D7C	 r3 = (UI32)-0xFEB8[r25]
 003F0D80	 r2 += r20
 003F0D84	 r20 = r2 + r3
 003F0D88	 r4 = r20 >>17
 003F0D8C	 r2 = r20 <<15
 003F0D90	 r20 = r2 | r4
 003F0D94	 r20 += r19
 003F0D98	 r2 = ~r30
 003F0D9C	 r2 = r20 | r2
 003F0DA0	 r2 = r19 ^ r2
 003F0DA4	 r2 += r13
 003F0DA8	 r3 = (UI32)-0xFEB4[r25]
 003F0DAC	 r2 += r21
 003F0DB0	 r21 = r2 + r3
 003F0DB4	 r4 = r21 >>11
 003F0DB8	 r2 = r21 <<21
 003F0DBC	 r21 = r2 | r4
 003F0DC0	 r21 += r20
 003F0DC4	 r2 = ~r19
 003F0DC8	 r2 = r21 | r2
 003F0DCC	 r2 = r20 ^ r2
 003F0DD0	 r2 += r8
 003F0DD4	 r3 = (UI32)-0xFEB0[r25]
 003F0DD8	 r2 += r30
 003F0DDC	 r30 = r2 + r3
 003F0DE0	 r4 = r30 >>26
 003F0DE4	 r2 = r30 <<6
 003F0DE8	 r30 = r2 | r4
 003F0DEC	 r30 += r21
 003F0DF0	 r2 = ~r20
 003F0DF4	 r2 = r30 | r2
 003F0DF8	 r2 = r21 ^ r2
 003F0DFC	 r2 += r18
 003F0E00	 r3 = (UI32)-0xFEAC[r25]
 003F0E04	 r2 += r19
 003F0E08	 r19 = r2 + r3
 003F0E0C	 r4 = r19 >>22
 003F0E10	 r2 = r19 <<10
 003F0E14	 r19 = r2 | r4
 003F0E18	 r19 += r30
 003F0E1C	 r2 = ~r21
 003F0E20	 r2 = r19 | r2
 003F0E24	 r2 = r30 ^ r2
 003F0E28	 r2 += r11
 003F0E2C	 r3 = (UI32)-0xFEA8[r25]
 003F0E30	 r2 += r20
 003F0E34	 r20 = r2 + r3
 003F0E38	 r4 = r20 >>17
 003F0E3C	 r2 = r20 <<15
 003F0E40	 r20 = r2 | r4
 003F0E44	 r20 += r19
 003F0E48	 r2 = ~r30
 003F0E4C	 r3 = (UI32)r29.0x0014
 003F0E50	 r2 = r20 | r2
 003F0E54	 r2 = r19 ^ r2
 003F0E58	 r2 += r3
 003F0E5C	 r3 = (UI32)-0xFEA4[r25]
 003F0E60	 r2 += r21
 003F0E64	 r21 = r2 + r3
 003F0E68	 r4 = r21 >>11
 003F0E6C	 r2 = r21 <<21
 003F0E70	 r21 = r2 | r4
 003F0E74	 r21 += r20
 003F0E78	 r2 = ~r19
 003F0E7C	 r2 = r21 | r2
 003F0E80	 r2 = r20 ^ r2
 003F0E84	 r2 += r14
 003F0E88	 r3 = (UI32)-0xFEA0[r25]
 003F0E8C	 r2 += r30
 003F0E90	 r30 = r2 + r3
 003F0E94	 r4 = r30 >>26
 003F0E98	 r2 = r30 <<6
 003F0E9C	 r30 = r2 | r4
 003F0EA0	 r30 += r21
 003F0EA4	 r2 = ~r20
 003F0EA8	 r2 = r30 | r2
 003F0EAC	 r2 = r21 ^ r2
 003F0EB0	 r2 += r9
 003F0EB4	 r3 = (UI32)-0xFE9C[r25]
 003F0EB8	 r2 += r19
 003F0EBC	 r19 = r2 + r3
 003F0EC0	 r4 = r19 >>22
 003F0EC4	 r2 = r19 <<10
 003F0EC8	 r19 = r2 | r4
 003F0ECC	 r19 += r30
 003F0ED0	 r2 = ~r21
 003F0ED4	 r3 = (UI32)r29.0x0028
 003F0ED8	 r2 = r19 | r2
 003F0EDC	 r2 = r30 ^ r2
 003F0EE0	 r2 += r3
 003F0EE4	 r3 = (UI32)-0xFE98[r25]
 003F0EE8	 r2 += r20
 003F0EEC	 r20 = r2 + r3
 003F0EF0	 r4 = r20 >>17
 003F0EF4	 r2 = r20 <<15
 003F0EF8	 r20 = r2 | r4
 003F0EFC	 r20 += r19
 003F0F00	 r2 = ~r30
 003F0F04	 r2 = r20 | r2
 003F0F08	 r2 = r19 ^ r2
 003F0F0C	 r2 += r12
 003F0F10	 r3 = (UI32)-0xFE94[r25]
 003F0F14	 r2 += r21
 003F0F18	 r21 = r2 + r3
 003F0F1C	 r4 = r21 >>11
 003F0F20	 r2 = r21 <<21
 003F0F24	 r21 = r2 | r4
 003F0F28	 r21 += r20
 003F0F2C	 r2 = ~r19
 003F0F30	 r3 = (UI32)r29.0x0020
 003F0F34	 r2 = r21 | r2
 003F0F38	 r2 = r20 ^ r2
 003F0F3C	 r2 += r3
 003F0F40	 r3 = (UI32)-0xFE90[r25]
 003F0F44	 r2 += r30
 003F0F48	 r30 = r2 + r3
 003F0F4C	 r4 = r30 >>26
 003F0F50	 r2 = r30 <<6
 003F0F54	 r30 = r2 | r4
 003F0F58	 r30 += r21
 003F0F5C	 r2 = ~r20
 003F0F60	 r2 = r30 | r2
 003F0F64	 r2 = r21 ^ r2
 003F0F68	 r2 += r17
 003F0F6C	 r3 = (UI32)-0xFE8C[r25]
 003F0F70	 r2 += r19
 003F0F74	 r19 = r2 + r3
 003F0F78	 r4 = r19 >>22
 003F0F7C	 r2 = r19 <<10
 003F0F80	 r19 = r2 | r4
 003F0F84	 r19 += r30
 003F0F88	 r2 = ~r21
 003F0F8C	 r3 = (UI32)r29.0x0018
 003F0F90	 r2 = r19 | r2
 003F0F94	 r2 = r30 ^ r2
 003F0F98	 r2 += r3
 003F0F9C	 r3 = (UI32)-0xFE88[r25]
 003F0FA0	 r2 += r20
 003F0FA4	 r20 = r2 + r3
 003F0FA8	 r4 = r20 >>17
 003F0FAC	 r2 = r20 <<15
 003F0FB0	 r20 = r2 | r4
 003F0FB4	 r20 += r19
 003F0FB8	 r2 = ~r30
 003F0FBC	 r3 = (UI32)r29.0x0034
 003F0FC0	 r2 = r20 | r2
 003F0FC4	 r2 = r19 ^ r2
 003F0FC8	 r2 += r3
 003F0FCC	 r3 = (UI32)-0xFE84[r25]
 003F0FD0	 r2 += r21
 003F0FD4	 r21 = r2 + r3
 003F0FD8	 r4 = r21 >>11
 003F0FDC	 r2 = r21 <<21
 003F0FE0	 r21 = r2 | r4
 003F0FE4	 r3 = (UI32)*r16
 003F0FE8	 r4 = (UI32)r16.0x0004
 003F0FEC	 r2 = (UI32)r16.0x000C
 003F0FF0	 r21 += r20
 003F0FF4	 r3 += r30
 003F0FF8	 r4 += r21
 003F0FFC	 r5 += r20
 003F1000	 r2 += r19
 003F1004	 (UI32)r16.0x000C = r2
 003F1008	 (UI32)r16.0x0004 = r4
 003F100C	 (UI32)r16.0x0008 = r5
 003F1010	 (UI32)*r16 = r3
 003F1014	 r4 = r29 +0x0010
 003F1018	 r5 = 0x0000
 003F101C	 call (r24 + 0x0437)*4
 003F1020	 r31 = (UI32)r29.0x006C
 003F1024	 r30 = (UI32)r29.0x0068
 003F1028	 r21 = (UI32)r29.0x0064
 003F102C	 r20 = (UI32)r29.0x0060
 003F1030	 r19 = (UI32)r29.0x005C
 003F1034	 r18 = (UI32)r29.0x0058
 003F1038	 r17 = (UI32)r29.0x0054
 003F103C	 r16 = (UI32)r29.0x0050
 003F1040	 r29 += 0x0070
 003F1044	 return
 003F1048	 r7 = 0x0000
 003F104C	 r8 = r4
 003F1050	 if u(r7>=r6) goto $003F1088
 003F1054	 r3 = (UI8)r5.0x0003
 003F1058	 r4 = r8 + r7
 003F105C	 (UI8)*r4 = r3
 003F1060	 r2 = (UI32)*r5
 003F1064	 r7 += 0x0004
 003F1068	 r2 = r2 >>8
 003F106C	 (UI8)r4.0x0001 = r2
 003F1070	 r3 = (UI16)*r5
 003F1074	 (UI8)r4.0x0002 = r3
 003F1078	 r2 = (UI8)*r5
 003F107C	 r5 += 0x0004
 003F1080	 (UI8)r4.0x0003 = r2
 003F1084	 if u(r7<r6) goto $003F1054
 003F1088	 return
 003F108C	 -
 003F1090	 r9 = r6
 003F1094	 r8 = 0x0000
 003F1098	 r10 = r5
 003F109C	 if u(r8>=r9) goto $003F10E0
 003F10A0	 r7 = r4
 003F10A4	 r2 = r10 + r8
 003F10A8	 r4 = (UI8)r2.0x0001
 003F10AC	 r3 = (UI8)*r2
 003F10B0	 r5 = (UI8)r2.0x0002
 003F10B4	 r6 = (UI8)r2.0x0003
 003F10B8	 r4 = r4 <<8
 003F10BC	 r3 |= r4
 003F10C0	 r5 = r5 <<16
 003F10C4	 r3 |= r5
 003F10C8	 r6 = r6 <<24
 003F10CC	 r3 |= r6
 003F10D0	 r8 += 0x0004
 003F10D4	 (UI32)*r7 = r3
 003F10D8	 r7 += 0x0004
 003F10DC	 if u(r8<r9) goto $003F10A4
 003F10E0	 return
 003F10E4	 r7 = 0x0000
 003F10E8	 r8 = r4
 003F10EC	 if u(r7>=r6) goto $003F1108
 003F10F0	 r2 = r5 + r7
 003F10F4	 r4 = (UI8)*r2
 003F10F8	 r3 = r8 + r7
 003F10FC	 r7++
 003F1100	 (UI8)*r3 = r4
 003F1104	 if u(r7<r6) goto $003F10F0
 003F1108	 return
 003F110C	 r3 = 0x0000
 003F1110	 if u(r3>=r6) goto $003F1124
 003F1114	 r2 = r4 + r3
 003F1118	 r3++
 003F111C	 (UI8)*r2 = r5
 003F1120	 if u(r3<r6) goto $003F1114
 003F1124	 return
 003F1128	 -
 003F112C	 r5 = r4 +0x0001
 003F1130	 r3 = r5
 003F1134	 if (r4==0) goto $003F1154
 003F1138	 r2 = (UI8)*r4
 003F113C	 r4 = r3
 003F1140	 if (r2==0) goto $003F114C
 003F1144	 r3++
 003F1148	 call (r24 + 0x0442)*4
 003F114C	 r2 = r3 - r5
 003F1150	 return
 003F1154	 r2 = 0x0000
 003F1158	 call (r24 + 0x0448)*4
 003F115C	 -
 003F1160	 r7 = r5
 003F1164	 if (r6==0) goto $003F119C
 003F1168	 if u(r4<r5) goto $003F11A4
 003F116C	 r2 = r5 + r6
 003F1170	 r3 = r2 -0x0001
 003F1174	 if u(r3<r4) goto $003F11A4
 003F1178	 r2 = r4 + r6
 003F117C	 r5 = r3
 003F1180	 r3 = r2 -0x0001
 003F1184	 r2 = (UI8)*r5
 003F1188	 r6--
 003F118C	 (UI8)*r3 = r2
 003F1190	 r5--
 003F1194	 r3--
 003F1198	 if (r6!=0) goto $003F1184
 003F119C	 r2 = r4
 003F11A0	 return
 003F11A4	 r5 = r7
 003F11A8	 r2 = r7 & 0x0003
 003F11AC	 r3 = r4
 003F11B0	 if (r2==0) goto $003F11E0
 003F11B4	 r6--
 003F11B8	 r2 = -0x0001
 003F11BC	 if (r6==r2) goto $003F119C
 003F11C0	 r7 = -0x0001
 003F11C4	 r2 = (UI8)*r5
 003F11C8	 r6--
 003F11CC	 (UI8)*r3 = r2
 003F11D0	 r5++
 003F11D4	 r3++
 003F11D8	 if (r6!=r7) goto $003F11C4
 003F11DC	 call (r24 + 0x045B)*4
 003F11E0	 r2 = r4 & 0x0003
 003F11E4	 if (r2!=0) goto $003F11B4
 003F11E8	 r2 = 0x0003
 003F11EC	 if u(r2>=r6) goto $003F11B4
 003F11F0	 r7 = 0x0003
 003F11F4	 r2 = (UI32)*r5
 003F11F8	 r6 -= 0x0004
 003F11FC	 (UI32)*r3 = r2
 003F1200	 r5 += 0x0004
 003F1204	 r3 += 0x0004
 003F1208	 if u(r7<r6) goto $003F11F4
 003F120C	 call (r24 + 0x0461)*4
 003F1210	 -
 003F1214	 if (r6==0) goto $003F1244
 003F1218	 r3 = (I8)*r4
 003F121C	 r2 = (I8)*r5
 003F1220	 if (r3==r2) goto $003F1234
 003F1224	 r2 = (I8)*r4
 003F1228	 r3 = (I8)*r5
 003F122C	 r2 -= r3
 003F1230	 return
 003F1234	 r4++
 003F1238	 r5++
 003F123C	 r6--
 003F1240	 if (r6!=0) goto $003F1218
 003F1244	 r2 = 0x0000
 003F1248	 call (r24 + 0x0480)*4
 

I tried to change the instructions at 3f1230 and 3f1240 to nop hoping it would bypass the md5 verification but then the board doesn't seem to boot at all, even with a valid md5. So either that is a bad patch or there is a checksum on that section too.

I thought they were just raw deflate streams. I was wrong.
It appears the stream is followed immediately by the CRC32 of the uncompressed data (but little endian) and the length of the uncompressed stream (but little endian). So like a gzip stream but without the gzip header.

Ok I see the length is there and I guess ziprisc complains about the length because it is not padded out to a 32bit value if it doesn't end on a 4 byte boundary.

Which byte range is "E3 93 51 9F EC 17 0C 8D 23 E7 32 E1 BF E8 1E 53" the MD5 of?

It's MD5 of the entire section, after zeroing where it is stored (0x10 through 0x1F).

I'm not sure how the firmware will treat the section from 3e0000-3effff when calculating the hash since in flash it does contain unique data. I have tried skipping, setting to 00/FF.

Anyone figured out how the addressing works?

Does this look right

*entrypoint*
psw = 0x00C3
r27 = 0x20000000
0x20004004 = 0x0C253E	RIFACE_WAIT_STATE
0x20008100 = 0x0F8404	BUSCON_DRAM_CONTROL
0x20004000 = 0x2F03	RIFACE_WIDTH
0x20004000 = 0x2C03	
0x200087E0 = 0x010E01	bus controller?
0x200087E0 = 0x110E01
0x200087E0 = 0x050E01
0x200087E0 = 0x050E01
0x200087E0 = 0x090E01
0x20004008 = 0x00FF	RIFACE_TURNOFF_DELAY 
0x20008114 = 0x003D	BUSCON_DRAM_SREFTIME 
0x20008828 = 0x0100	bus controller?
0x2000841C = 0x1101FF	bus controller?
0x2000861C = 0		bus controller?
r9 = 0x1CFFFFFC
r9 = 0x0CFF0000
r10 = 0x0CFF13CC	table start
r11 = 0x06 	table # entries
memcpy(0x0100,  0x0CFF124C, 0x60*4)	data
memcpy(0x040000, 0x0CFF0030, 0x487*4)	code
r24 = 0x110000
r25 = 0x010100
r29 = 0x200000
goto 0x40010079*4 = 0x0401E4 = 0x3F0214?
 

because dropping in at 0x3F0214 doesn't seem to be correct.

Math looks good to me. Why don't you like that as an entry point?

Well because none of the registers used in that section have been setup and the call at 3F0254 will seem to point to 0x440158 which I am not sure what is at that address.

[unless im smoking crack...]
r24 and r25 get set by the table3 loader macro which makes the loads at 0x3F0224 read from the data portion loaded at 0x100. (also works for the other loading of md5 constants from different offsets of same data section)

i have the jump at 3F0254 going to 3F0188 (0x56 words from the beginning of the code that got loaded at 0x40000)

If we jump in at 3F0214 we see r17,r31,r16 saved. None of these were previously set. It may not matter in this case since it is first entry to this section.

So call (0x00110000 + 0x056)*4 = call (0x00440158)

the last call we had call (0x000401E4). So can we ignore some of the MSB? This goes back to understanding the addressing.

Before the call we have

r29 = 0x1FFFE0
0x1FFFF4 = r17
0x1FFFF8 = r31
0x1FFFF0 = r16
r17 = *(0x12C) = 0x04881D05
r27 = *(0x130)
r22 = 0x800000
r26 = 0x1D000000
r2 = 0x1877E2FB
r4 = *(0x1877E2F7) ??
r3 = *(0x20003040) peripheral register?
 

I am still learning as I go.

Moderator Action
The post that was here (and all 3 followups to it), has been moved to a new topic .. »ObiHAI Obi100/Obi110 Google Voice Working again (DNS)

r17 = *(0x12c) = 0x00020000
r27 = *(0x130) = 0x20000000
(data was loaded at 0x100, so just a 0x2C/0x30 offset into it)

After accumulating md5s across like 6 different sections, the jspci at 3F0148 is a call to memcmp MD5s.
Might be easiest to replace that instruction with a faked successful comparison by just setting r2 directly to 0 (E0 04 00 00) instead.

Now if only I could make this fucking spi flash circuit work...

Limited success: flash works and I can modify the build# and ignore the md5s and still boot.

Obi100 lives!!

So it is working with the certificate patch but I am not sure how to tell whether I am hitting a server with the new certificate or not.

Thanks for pointing out my error with the offsets. I have patched the instruction at 3F1220 to 0x10C00003 aka if u(r3 >= 0) goto $003F1234 and now I am able to boot with a bad MD5, no christmas lights. Now I have to fix up the patched deflate section with the proper length value and try it.

VICTORY. It made me get a new oauth token, and voila. Connected.

Nice. Would you post a bpatch?

Also, is there any chance anyone would be willing to try to figure out how to make the md5 check pass for integrity purposes?

Nice! Can someone summarize the steps taken to accomplish this? Or are all the steps in the thread?

This is why I asked for a bpatch. That would simplify things and avoid possibilities for mistakes. Also, if a sha256 checksum for the patched firmware is provided alongside the bpatch, it would be possible to ensure that the result is really what it ought to be without distributing any of obihai’s intellectual property.

I am interested in the summary just to broaden my understanding how to do this. bpatch yes.

talkbot, it's your victory as much as mine. any objections to me dumping out a patch here for anyone stupid enough to attempt to flash it?

we should ask for payment of a FUCK YOU postcard to obihai for not taking the 10 minutes to do this themselves...

Holy crap! Congratulations to you and everyone who contributed!

I've been following this thread from the get-go. If I'm understanding correctly, you've replaced the outdated cert with the new one. This will need to be repeated if/when google updates certs again?

Just an FYI. Starting yesterday a lot of people with OBi110/OBi100 devices suddenly became able to connect again to Google Voice. It's unclear why but there may have been a change on Google's end to enable this.

»www.obitalk.com/forum/in ··· msg86012

I don't have any objection to a patch. It would be nice to use a valid md5 though so that bad flash checks can still work. Did you document the ranges used in the MD5?

Also it would be nice to produce a real update fw file but it may not be possible due to secure signatures.

fw header:

4F 42 31 30 30 5F 46 57 5F 50 41 43 4B 41 47 45 	OB100_FW_PACKAGE
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 	
56 CC 2C 5B A5 D6 95 19 AC A0 13 46 8D BD ED 5E 	256bit value, SHA-256?
C3 B5 74 1B E8 83 A6 08 AB 4C FA 35 B0 7A 04 5A 
00 00 00 02 00 22 3C EE 00 00 00 00 00 00 00 00 	# sections, total length
00 00 00 00 00 00 01 00 00 08 00 00 00 0F 3B EE 	section index, file offset, flash offset, length
00 00 00 01 00 0F 3C EE 00 2D 00 00 00 13 00 00 	section index, file offset, flash offset, length
37 96 D9 0A 8A D5 71 31 4B 4D 60 3B FB 08 4E 24 	
37 F1 C0 03 1E DF DE 01 3C E3 92 42 1D 8F 0C 57 
ED C4 8F 3E 17 D3 CF 64 92 DC 75 3E E1 E6 3F 47 
F1 FE 98 3A 21 D0 E0 15 9B 09 8D 0B DB B3 E2 76 
EB 5E EB 2E EF 5F 58 25 44 D3 AC 2D CC FF 50 7B 
25 54 72 73 2E CD 67 5C B4 25 F2 2F 50 97 D9 03 
43 5E 5E 62 AF 45 07 7D A0 07 AB 3F 4C F0 E9 5D 
79 01 EC 16 CC F6 BA 29 59 89 35 5E B1 97 C5 21 
08 4C B3 22 3D DF 13 DB F3 98 C9 19 75 FD 67 37 
 

What the hell do people use to make binary diffs?

I didn't get as far as going to ranges when I saw how many calls to that sub there were.
Maybe you can backtrack them easier than me. Here's some notes on the section right at the beginning of the loaded code. (MD5_Other calls MD5 twice more, but with some little endian weirdness):

00213D1E: addi	r29, #-0x00D0, r29	; r29 -= 0x00D0
00213D22: st	#0x00B0[r29], r16 	; (UI32)r29.0x00B0 = r16
00213D26: addi	r29, #0x0098, r16 	; r16 = r29 +0x0098
00213D2A: st	#0x00C8[r29], r30 	; (UI32)r29.0x00C8 = r30
00213D2E: st	#0x00C4[r29], r21 	; (UI32)r29.0x00C4 = r21
00213D32: st	#0x00B8[r29], r18 	; (UI32)r29.0x00B8 = r18
00213D36: st	#0x00B4[r29], r17 	; (UI32)r29.0x00B4 = r17
00213D3A: add	r0, r4, r18		; r18 = r4
00213D3E: addi	r29, #0x0040, r17 	; r17 = r29 +0x0040
00213D42: add	r0, r5, r21		; r21 = r5
00213D46: add	r0, r16, r4		; r4 = r16
00213D4A: addi	r25, #-0x10000, r5	; r5 = r25 -0x10000
00213D4E: add	r0, r6, r30		; r30 = r6
00213D52: addi	r0, #0x0014, r6 	; r6 = 0x0014
00213D56: st	#0x00C0[r29], r20 	; (UI32)r29.0x00C0 = r20
00213D5A: st	#0x00BC[r29], r19 	; (UI32)r29.0x00BC = r19
00213D5E: st	#0x00CC[r29], r31 	; (UI32)r29.0x00CC = r31
00213D62: jspci	r24, #0x044B, r24	; call (r24 + 0x044B)*4       call memmove
00213D66: add	r0, r17, r4		; r4 = r17
00213D6A: jspci	r24, #0x00A3, r24	; call (r24 + 0x00A3)*4       call init md5 constants
00213D6E: add	r0, r16, r4		; r4 = r16
00213D72: jspci	r24, #0x043E, r24	; call (r24 + 0x043E)*4       call strlen
00213D76: add	r0, r2, r6		; r6 = r2
00213D7A: add	r0, r16, r5		; r5 = r16
00213D7E: add	r0, r17, r4		; r4 = r17
00213D82: jspci	r24, #0x00AE, r24	; call (r24 + 0x00AE)*4       call MD5
00213D86: addi	r29, #0x0030, r20 	; r20 = r29 +0x0030
00213D8A: add	r0, r21, r5		; r5 = r21
00213D8E: add	r0, r17, r4		; r4 = r17
00213D92: addi	r0, #0x0010, r6 	; r6 = 0x0010
00213D96: jspci	r24, #0x00AE, r24	; call (r24 + 0x00AE)*4       call MD5
00213D9A: addi	r21, #0x0020, r21 	; r21 += 0x0020
00213D9E: add	r0, r17, r4		; r4 = r17
00213DA2: add	r0, r20, r5		; r5 = r20
00213DA6: addi	r0, #0x0010, r6 	; r6 = 0x0010
00213DAA: st	#0x0030[r29], r0 	; (UI32)r29.0x0030 = 0
00213DAE: st	#0x0034[r29], r0 	; (UI32)r29.0x0034 = 0
00213DB2: st	#0x0038[r29], r0 	; (UI32)r29.0x0038 = 0
00213DB6: st	#0x003C[r29], r0 	; (UI32)r29.0x003C = 0
00213DBA: add	r21, r18, r16		; r16 = r21 + r18
00213DBE: jspci	r24, #0x00AE, r24	; call (r24 + 0x00AE)*4       call MD5
00213DC2: addi	r29, #0x0010, r19 	; r19 = r29 +0x0010
00213DC6: addi	r18, #-0x0020, r6	; r6 = r18 -0x0020
00213DCA: add	r0, r21, r5		; r5 = r21
00213DCE: add	r0, r17, r4		; r4 = r17
00213DD2: addi	r16, #-0x0020, r21	; r21 = r16 -0x0020
00213DD6: jspci	r24, #0x00AE, r24	; call (r24 + 0x00AE)*4       call MD5
00213DDA: addi	r30, #-0x0020, r30	; r30 -= 0x0020
00213DDE: add	r0, r21, r5		; r5 = r21
00213DE2: add	r0, r19, r4		; r4 = r19
00213DE6: addi	r0, #0x0010, r6 	; r6 = 0x0010
00213DEA: jspci	r24, #0x044B, r24	; call (r24 + 0x044B)*4       call memmove
00213DEE: sub	r30, r18, r18		; r18 = r30 - r18
00213DF2: add	r0, r20, r5		; r5 = r20
00213DF6: add	r0, r17, r4		; r4 = r17
00213DFA: addi	r0, #0x0010, r6 	; r6 = 0x0010
00213DFE: jspci	r24, #0x00AE, r24	; call (r24 + 0x00AE)*4       call MD5
00213E02: addi	r16, #-0x0010, r21	; r21 = r16 -0x0010
00213E06: addi	r18, #0x0010, r30 	; r30 = r18 +0x0010
00213E0A: addi	r29, #0x0020, r16 	; r16 = r29 +0x0020
00213E0E: add	r0, r30, r6		; r6 = r30
00213E12: add	r0, r17, r4		; r4 = r17
00213E16: add	r0, r21, r5		; r5 = r21
00213E1A: jspci	r24, #0x00AE, r24	; call (r24 + 0x00AE)*4       call MD5
00213E1E: add	r0, r17, r5		; r5 = r17
00213E22: add	r0, r16, r4		; r4 = r16
00213E26: jspci	r24, #0x00E4, r24	; call (r24 + 0x00E4)*4       call MD5_Other
00213E2A: add	r0, r19, r4		; r4 = r19
00213E2E: add	r0, r16, r5		; r5 = r16
00213E32: addi	r0, #0x0010, r6 	; r6 = 0x0010
00213E36: jspci	r24, #0x0478, r24	; call (r24 + 0x0478)*4       call memcmp
00213E3A: add	r0, r2, r3		; r3 = r2                                   MOD-->e0 06 00 00   r3 = 0
00213E3E: addi	r0, #0x0000, r2 	; r2 = 0x0000
00213E42: beq	r3, r0, $00213E6E	; if (r3==0) goto $00213E6E
00213E46: ld	#0x00CC[r29], r31 	; r31 = (UI32)r29.0x00CC
00213E4A: ld	#0x00C8[r29], r30 	; r30 = (UI32)r29.0x00C8
00213E4E: ld	#0x00C4[r29], r21 	; r21 = (UI32)r29.0x00C4
00213E52: ld	#0x00C0[r29], r20 	; r20 = (UI32)r29.0x00C0
00213E56: ld	#0x00BC[r29], r19 	; r19 = (UI32)r29.0x00BC
00213E5A: ld	#0x00B8[r29], r18 	; r18 = (UI32)r29.0x00B8
00213E5E: ld	#0x00B4[r29], r17 	; r17 = (UI32)r29.0x00B4
00213E62: ld	#0x00B0[r29], r16 	; r16 = (UI32)r29.0x00B0
00213E66: addi	r29, #0x00D0, r29 	; r29 += 0x00D0
00213E6A: ret				; return
00213E6E: addi	r0, #0x0001, r2 	; r2 = 0x0001
00213E72: jspci	r24, #0x004A, r8	; call (r24 + 0x004A)*4    goto 3e76
 
 

bsdiff

Hope this project succeeds.
110 now $20 on NewEgg.
Why waste time unlocking Vonage units?

Yes, assuming that obihai does not just drop web support for the obi100.

There is also bdiff:

»bdiff.sourceforge.net

While it would be possible for Obihai to brick a unit that was left 'phoning home', it seems unlikely that they would take the legal risk doing so, or that many techie users would even leave this path open.

Otherwise, if they merely 'dropped' support, wouldn't existing GV accounts continue to work? And even if were difficult to modify the UI to accept the parameters locally, I'd think that the generality of the FW_PACKAGE format would allow easy installation of a new refresh token if needed.

I think the inner md5 is calculated based on the inflated data so probably not going to bother with it. And if the fw files are signed with a private key then we won't be able to sign a patched one.

They do not need to brick the units. They just need to remove their website’s support. Have fun configuring the unit to connect to Google Voice without their website. There is no way to do that currently.

If it were signed with a private key, it would not have taken the patched firmware.

Here's a bsdiff to update a full 4MB flash dump to:
1) swap that globalsign cert in instead of those lame valicert and equifax ones
2) disable md5 fw check during boot
3) change the version string, for vanity

EDIT: deleted attachment, see later fixed version

Does this mean that the 2886 firmware update cannot yet be modified in a way that applies this via the typical updated?

Do I understand this process correctly? I believe that:

The present patch is done by reading the flash via SPI, applying the bsdiff to the resulting file, and writing it back to flash via SPI.

This same method could be used to modify the GV refresh token in flash, allowing GV config to be updated without reliance on Obihai's portal.

If it turns out that the firmware package is signed, it won't be possible to make the patch via the web interface, unless a (probably unrelated) vulnerability is found.

OTOH, if the package just uses some hash-based integrity checks, once they are understood both new certificates and GV account updates could be done via the web interface.

How would one generate the refresh token? Client ID and secret are needed. Client id can be pulled from the obitalk's portal, but what about the secret.

There is a way to do it for asterisk, but I lost the link that had instructions. This script came up in a quick google search:

»gist.github.com/rinex20/ ··· 6af50582

^^Right, look at line 9 of the script. That piece of information is not available unless it's embedded somewhere in the firmware.

haha, now I can't connect to the "old" talk.google.com servers. whoops.
Better add that Equifax cert back in...

Fixed.

Here's an improved bsdiff to update an original 2886 4MB flash dump to:
1) swap that globalsign cert in (since its the root for GIAG3) instead of those lame valicert and *verisign* ones, keeping equifax (since its the root for GIAG2)
2) disable md5 fw check during boot
3) bump version string

EDIT: remove superceded attachment. See later version.

Great work. How did you dump it? Was it with a 8pin pomadora clip and spi programmer? I have not opened mine to look.

My board had a 7pin male header. Just hooked up to parallel port and used spipgm

:

The signature is not checked at boot, only at update. By writing directly to flash the check is bypassed.

The update code is part of the packed main firmware and there are two obihai CA certificates in there as well. We know the firmware can do certificate verification so it can definitely check a signature on the update file. What else would the 144byte blob in the fw header be if not a signature?

You should probably delete the other one

You might be right.

We can verify one way or the other if we can just figure out the addressing of the compressed sections wherever they get uncompressed to. Any clues on that?

The word preceding the deflate stream is probably the destination address but the msbs of the address and overall memory map are still confusing.

Originally, I thought that he was flashing via the web interface. My mistake.

This sounds plausible, although if it is a signature, it should have at least a hash plus an copy of it that is encrypted with the private key. You can check the update routines to see if they are verufying a signature, but another way is to zero it out, calculate the md4, md5, sha1 and sha256 and see if the result is contained within that 144 byte blob. If it is a signature, spotting a match via this method would be is a quick and dirty way of confirming it. If there is no match, you get to read assembly.

Hi, I too have been following this thread. The newcerts2.bsdiff.zip that's been posted for downloaded is what we can use to upgrade the firmware and add the updated certificates? And we can do this through the local web portal?

Just want to be sure so I don't end up bricking this obi100. Thanks for all the work.

Yes the obvious things have been tried. I think it is probably salted too. Please feel free to investigate and report your findings.

It is part of it. You also need to open up the obihwi and use a flash programmer. We do not know how to update through the web portal yet.

I am backlogged at work. I do not have time to take a dump of flash memory and poke around.

Anyway, we at least have evidence that can be used to accuse obihai of refusing to do a trivial update. The claims on their forums that it takes enormous engineering effort are clearly wrong.

So here's a thought.

This is with respect to oauth2 provisioning.

So if we can identify the secret, then perhaps we can change the secret and clientid altogether that way eliminating obihai entirely from the provisioning process. That is, create refresh tokens just like we do for asterisk. This completely eliminates and need for obihai and sharing any data with them.

I never updated my device to use oauth2 it is still using credentials directly.

You can work directly from the fw file like naf did.

Obihai may no longer have valid licenses to the development tools.

Right, but i'm saying perhaps it's possible to do away with obitalk altogether in the first place.

The second md5 is salted by prepending "Goodbye! Reboot Now" and then includes the first 0x110000 bytes (stopping right before unit info section).

Unfortunately this is the one we already defeated by bypassing the check during boot.

By using credentials you are avoiding obitalk but you have to reduce your Google account security. If you have a separate Google account for your obi this is not a big deal IMO.

If using plaintext, yes, but if using oauth2, then no security is compromised. If somehow we could embed our own refresh token, that would do away with the need for obitalk for gv provisioning.

Oh thats cute. Zero out both md5, prepend string (without null?), and take md5 of range 2d0000-3dffff? Doesn't seem to match up.

Correct. No null.

Got it, was looking at the wrong bytes before. Well now we can unpatch the md5 and petition obihai to sign the image.

i dunno, i read over on the obitalk forum that we havent achieved anything yet...

Is this the thread?

»www.obitalk.com/forum/in ··· =13385.0

Ya, Mango narced on us

Do we know if the devices have a boot loader such as Das U-Boot or CFE that would allow for TFTP flashing or if it is possible to downgrade the firmware to a version where there was no signature check?

Also, any idea what OSS components are in the firmware?

Lastly, although this is the epitome of laziness, I do not have access to my obi100 right now. Could someone check the HTTP headers to see what web server is used. If it is a known web server, we could look up CVE vulnerabilities to find one that does code injection. From there, it should be possible to write code to bypass the normal updater.

I just love this remark: He clearly does not realize that things will not always be this difficult.

Similarly: This guy apparently does not understand what code signing is. If it is really being used, it would prevent this from being done. At least the intended way anyway. A CVE in the webserver would allow bypassing that.

While people seem to have since found the salted hash, I want to add that it occurs to me that a signature could be really simple. It could consist of calculating a hash, encrypting it with the private key and then putting it into the header. Then the updater could decrypt it with the public key, and verify it against the firmware update with the signature zeroed. In this way, there would be no need for the hash used for the signature to be stored in plaintext. :/

That was my thought when I read that too...

Ask people why they can't get root access for some Android phones...

Could be a lot of things..

Phones? I still cannot get root access on my Android TV. :/

It is just a thought for people to keep in mind while looking through the firmware.

Here's the latest bsdiff to update an original 2886 4MB flash dump to:
1) swap that globalsign cert in (since its the root for GIAG3) instead of those lame valicert and verisign ones, keeping equifax (since its the root for GIAG2)
2) put in correct fw md5s, so we can leave the boot-time check
3) change version string to 2886-naf3

And for those of you who don't have a screwdriver and some resistors, here's a web-loadable version...

Just apply the patch against OBi110-1-3-0-2886.fw and load via the GUI.

In that case, I take it that there was no code signing.

Thank you so much, @naf. Updated via web. Running 1.3.0 (Build: 2886-naf3). Working great!

Or a parallel port.. lol I think that would be the harder requirement for most hah

Nice work! So what is the header composed of? Did you change the downgrade whitelist so that it was flashable back to stock 2886?

It is web-flashable back to stock, there's just the downgrade blacklist of 2860 and 2881, same as original. (see code @ offset 0xdb00 in the deflated section that begins at 0x12f832)

No clue on what the extra 0x20 and 0x90 bytes of the headers were, but nothing checks them. I kept looking at the web updater code, and I only see MD5s. The web updater only checks that each section has its MD5 at offset 0x10 (as you identified early on) and that the fw can pass the salted md5 check that is also enforced at runtime.

youre definitely right. i had to borrow one for the lpt myself.
for... uhhh.... printing....

I lost my LPT programmer.. I was without a LPT port for so long I lost it.. Have a USB one I still haven't tried programming My current laptop has a docking station that provides a real one along with a serial port..

Before I try and find a replacement I need to confirm if my Pi3 can do everything the LPT one can do.. Has worked for my recent projects

Ha, I thought it was too easy to consider trying especially since 2824 had a totally different header. I thought there was a whitelist too because 2824 appears in a string near the downgrade error string. Oh well, all is good. Nice collaborating with you and happy new year.

Maybe you could post the resulting web flashable binary for those who cannot combine the stock binary and diff file?

Speaking as a software developer, I can say that would likely be a legal issue. It likely is not hard to combine the two. Just boot a Ubuntu live environment and do it from there.

bspatch OBi110-1-3-0-2886.fw new.fw newcerts3.fw.bsdiff

ETA (bspatch binaries):
* OS X: bspatch built in. Terminal.app in /Applications/Utilities
* Windows: »www.romhacking.net/utili ··· ies/929/

Likewise. Let's do it again sometime.

Thanks again to you all, pretty amazing accomplishment. I was able to generate new.fw with the instructions provided.

There is bspatch for Windows and OSX

Good deal. Thanks for the link.

I figured that I would give instructions that would just work for people. I had intended it for Windows users though.

I installed the naf3 build on a spare 110, added to OBiTALK, and configured Google Voice. For interest's sake I'll leave OBiTALK connected.

Great, although I wonder how long it will be until Obihai removes the ability to install the tokens through their website.

If you don't like to use bspatch, here is link to the web flashable binary, naf3 version: »pastebin.ca/3952393

I am not a lawyer, but I am a professional software developer and I am familiar with how licensing matters work by necessity. That patched version is likely illegal to distribute unless Obihai gave permission to redistribute derivatives. People would need to run bspatch themselves for it to be okay.

I am optimistic that won't happen. The 1xx-series devices ceasing to function due to a change at Google beyond Obihai's control is one thing. Deliberately preventing users from using their products would be a different matter entirely, something I expect even Obihai wouldn't stoop to. Anyway, it would only encourage users to reverse engineer the firmware further. I found my old OBi110 hardware 2.8 version with the damaged FXS port and installed this. Preliminary testing indicates it works properly.

I have a newbie question, after updating the firmware and connecting to the GV through the Obitalk web portal, can I delete the device from the Obitalk portal at this point? I.e., what does the Obitalk portal do after authenticating the device through them with the GV server?

double post, deleted

Yes, you surely can. You can also use the device's internal web server to disable OBiTALK Service if you are particularly concerned about your privacy.

At any time you can add your device back to the OBiTALK portal if you want to modify your Google Voice configuration.

So if we do not use the obi device to device talk (I guess that's what the Obitalk service is about), then all Obitalk portal does is to provide a platform for the OAuth2 authentication between the Obi device and the GV server, is that correct?

And after authentication, the Obi device connects to the GV server directly, i.e., does not go through the Obitalk portal anymore, correct?

Basically yes. OBiTALK also allows you to configure other aspects of your device besides Google Voice. Correct.

OK, two more questions along this line, I surely don't want to hijack this thread.

After authentication, if the device needs to reconnect to the GV server after, say, a power outrage, does the device need to go through the Obitalk portal again? I guess what I am asking is, after the 1st authentication, does the ID and the secret get stored in the device? Or how does the GV server recognize the device from the point on?

Second, because I can enter the GV credential (email and password) on the device web GUI, if I turn off OAuth2 by enabling the less secure app access on the google side, can the device connect to the GV server without even going through the Obitalk portal at all?

No, the OAuth2 "token" does. The device should work properly after a power outage with no user intervention. I tried this today and was not able to make it even attempt to connect.

So the OAuth2 token gets stored in the Obi device after 1st authentication? If that's the case, then Obi device only needs to go through the Obitalk portal once in its life time, right? I mean, even after a firmware update, the token should still be there and remains the same, correct?

Technically yes, but my experience has shown otherwise.

Two devices, obi202 and obi200. Both had all the obitalk crap disabled. I had to reauthenticate the gv accounts on the 202 after manually flashing the firmware file. Flashing the 200 in the same manner (with the same file) kept the oauth token intact.

Uhm, interesting! Thanks for the reply and the sharing!

Does anyone want to tell SteveInWa that he is the one who did nonsense speculation?

»www.obitalk.com/forum/in ··· msg85509

The forum support provided is valuable probably best not to let them know or if anyone does please go easy on them.

Hopefully they will at minimum be silent on what new fix is available and not interfere any further.

Look at Apple, issued an apology to customers after its admission to slowing down older iPhones sparked consumer outrage and national headlines.

In an attempt to regain the trust of consumers, the company will reduce the cost of an out-of-warranty replacement battery

He'll figure it out when hundreds (thousands?) of users install the crowdsourced firmware if and when Google changes their certificates again in January.

One of the reasons I'm not rushing to do so on my Obi100. That and the flexibility I still have with the older variants of the FW (2774, 2776, 2824) that don't lock out prior versions...

^^Maybe enabling the firmware downgrade is as simple as toggling a bit or two in the firmware¿?

At some point google might require oauth authentication only, but I don't see that happening any time soon. Even with 2 step verification, one can create 'app' passwords that are accepted in clients that use plain text passwords.

Anybody recognize the crypto functions at offsets 0xC470 and 0xBEC8 in the compressed code stream starting at 0x12f832 in the 2886 fw file?

Still trying to figure out how the oauth refresh token gets on the device...

Nevermind, it looks suspiciously like RC4

That is hilarious. Do a network capture of the tokens being put onto the device. If it is RC4, it should be relatively easy to crack. It would also confirm conventional wisdom that embedded systems security is a joke.

Exciting news! Loaded the modified firmware even though GV is currently working fine with the original 2886 firmware. So is it that we won't know whether the modified firmware is effective until GV stops working on original 2886 firmware again?

naf confirmed that the change to make it work fixed things before Google Voice started working fine for people again.

I thought your Obi110 was still running on 1.3.0 (Build: 2824) since you didn't want to upgrade to 2886? Did you upgrade to 2886 to install this?

I haven't yet messed with my primary OBi; I've just installed naf3 on two slightly broken 110s (hardware versions 2.8 and 3.4) for experimental purposes. I'm happy to report naf3 has been 100% stable so far.

How do I find the pastebin on the AWS website?I'm signed to the AWS website.
Thanks.

Your question makes no sense. There is no pastebin on the AWS website and you don't sign in to anything.

Click the link in the quote below: Then navigate to the URL on the pastebin.ca site to download the firmware.

I start here pastebin.ca 3952393 then this site (»s3.us-east-2.amazonaws.c ··· /naf3.fw) and the amazon aws website comes up. What am I doing wrong?

My error I have the file. How do I change it to a binary file to flash to the Obi100.

Thanks.

You don't need to change the file. From the OBi100's internal web server, System Management >> Device Update >> Firmware Update.

Thanks very much I thought I needed to change the patch to a binary file.

Update was successful but,it looks like once you have deleted your original Google voice account on the adapter Obihai will not let you provision it ever again.

I attempted to apply the update from the Web Interface. After clicking on "Update", I get a popup saying "Press OK to update the firmware. Please allow 30s for the process to complete.", I click OK, and nothing happens (not even a reboot, or any sign of activity). The fw version is still 2886 (not 2886-naf3). My fw file is correct (originally generated from the bsdiff file, later verified to be identical to the posted fw file).

Edit: I tried naf4. Also, using a different browser (in case my regular browser was blocking something) and flashing the original 2886 firmware that's already installed. Not able to flash anything. I'm pretty sure that I had to manually flash the original 2886 firmware back in 2016, don't know why it no longer works.

Latest updated bsdiff to patch an original 2886 GUI-uploadable firmware.
This one is better because it succesfully loads all 9 certs. Something was wrong with naf3 that made it stop after #3, which was equifax so nobody cared...

Changes:
1) *add* globalsign cert (root for GIAG3) leaving all previous certs intact including equifax (root for GIAG2) [had to move the certs to the end of the 0x1b844a hunk to make room, change the PEM_read_bio_X509 location and size params to point to that new location, and move table1 and its pointer back a bit in the firmware to make room for the bigger hunk]
2) put in correct fw md5s, so its web-uploadable and passes boot-time check
3) change version string to 2886-naf4

@Naf, thanks for keeping on this.

Have you been able figure out how to unblock firmware downgrades. This wold allow folks to load an older firmware where plain text authentication still works.

Not correct... I have just today activated 3 OBI100's on Google Voice via Obitalk that I had removed from GV last week when they no longer worked.
They now are working again as I had posted on another forum today.

Does that actually still work? If so, a re-certed version of that would be nice.

What version of the firmware do the plaintexters still use?

1.3.0 Build 2824. It does not appear to be available for download any longer. PM me your email address if you want a copy.

PM sent

Deleted.

Curious if this is still relevant?

»Recent Google Voice / OBi issues

Updated: »obi1.s3-website.us-east- ··· aws.com/

I posted the download link for 2824, but my post was removed. Did I break some rule?

The URL for 2824 has OBi, not OBi110.

Yes Mods! azrobert2 linked to official FW from Obihai that is not modified in any way.

Yeah you can't link directly to firmware. You'd have to link to an Obihai page or a page on their forum that has the link to the firmware. Click the Rules button at the top of the page and you can see it there.

Deleted.

Don't shoot the messenger, I'm not a mod. Just answering the question if a rule was broken is all.

Personally, I'm thankful for the clarification, I thought it was only modded stuff you couldn't directly link to.

Thanks!

Thanks

See:
»www.obitalk.com/forum/in ··· msg86434

Here's a link for a post with the 2824 firmware:

»www.obitalk.com/forum/in ··· msg86434

So if the goal here is to mitigate against the chance that obitalk will cease to send oauth refresh tokens to our devices, wouldnt an easy way to take obitalk out of the loop be to just use the password field as a place to put our own refresh token manually. And then we can just authorize and refresh them with our own client_id (hardcoded into fw)?

Latest. Not sure how useful any of the old firmware is at this point, but here goes...

Changes:
1) add globalsign cert (root for GIAG3) leaving all previous certs intact including equifax (root for GIAG2)
2) put in correct fw md5s, so its web-uploadable and passes boot-time check
3) remove firmware downgrade check
4) change version string to 2886-naf5

I think this would be the ideal solution. Creating client_id's and refresh tokens is relatively simple. Obitalk is out of the picture entirely. Still the lingering issue of updating certs if/when they need updating.

But if we don't make every device configure its own unique client_id, then we're just as stuck using the naf (or whatever) website to get a refresh token to install manually as we are with obitalk now...

In theory if the older firmware used TLS instead of SSLv3, would it still work with Username/password? What other info is getting passed?

this being unsual to me, would you please do a step by step on updating the firmware to this newest firmware. i have an obi100 with 2886 installed. thank you pothound

You can download the already-patched version from here: »obi1.s3-website.us-east- ··· aws.com/

You need the client id and client secret to obtain tokens and it should not be hardcoded so users can use their own. For the tokens you could compare a flash dump before and after obitalk provisioning and since we control the certificates we can MITM the provisioning. If it is too much trouble to make the API keys dynamic then a patcher script that modifies the firmware and embeds them would work.

Patcher idea is good. That fucking web interface in assembly is a bitch to figure out.

By observing the provisioning, with luck you may find that they are simply using a 'secret' parameter name for the token and you could then use ordinary provisioning files to input the tokens.

If that's not the case, you may be able to provision your own tokens by emulating whatever the Obihai site does.

With yet worse luck, there may be integrity checks and/or a signature that's independent of the TLS, so even an MITM-based modification won't work.

The secret param name is X_GApiRefreshToken (and X_GApiInitAccessToken).

Checking on encryption...

UPDATE: not encrypted. Its just the raw refresh token.

Is it possible that the AuthUserName and AuthPassword fields could be somehow repurposed to be used with the client id and secret?

Edit: Doh.

You need the username field, for, you know, your username... :-P
but the password field is up for grabs. I was planning on putting the refresh_token there, but if we can provision in the refresh token, then maybe that gets the client_id/secret comma-separated or whatever? have to check length limits...

I wonder whether these params get saved by Backup Configuration and/or loaded by Restore Configuration. Editing a backup file would not be a major hassle for most folks, certainly easier than setting up a provisioning server.

Just checked my 200/202 xml backup files. No tokens or secrets. This explains why one still has to use obitalk to provision a google account even after restoring the xml file.

Not being saved doesn't necessarily mean that they aren't restored. Aren't passwords not saved yet are accepted in the XML file?

And, it doesn't necessarily mean that tokens are not accepted in a normal provisioning file pulled by HTTP(S).

Token restored from backup config = no
Token ITSP provisioned = yes

I couldn't get it to *un*set though. Had to reset to go back to the obitalk provisioned token.

unfortunately obi registered their client_id as a web-style app, not a standalone-style app, so I can't just use *their* client_id to authorize and get a refresh token in the offline mode. that woulda been fun. o well, we can just mod the fw to use a different client_id.

Can you change X_UserAccess attribute of those keys so they are saved/restored during backup?

Here's a bsdiff to update 2886 to be able to (optionally) use a user-provided client_id/client_secret/refresh_token to oauth for gv.

To use, just set the AuthPassword field, in a format like this (suspiciously similar to the exact data posted to the oath token service):

client_id=<your own client id>&client_secret=<your own secret>&refresh_token=<token you get from oauth>&grant_type=refresh_token
 

If AuthPassword is defaulted/blank, everything goes back to the obi client/secret with the obitalk-provided token way.

Changes:
1) add globalsign cert (root for GIAG3) leaving all previous certs intact including equifax (root for GIAG2)
2) put in correct fw md5s, so its web-uploadable and passes boot-time check
3) remove firmware downgrade check
4) oauth token request override
5) change version string to 2886-naf7

Now if someone would just remind me how to get a freshly reset box out of "Service Not Configured" without using obitalk, we'd be all set...

.

I don't know the answer, but since you have gained control over the certificates, can't you just MITM the connection from Obitalk and see what's needed?

Wow! That was fast, any rules regarding our (your own) client id and secret?

Oyeah...

BTW, you don't even need modded certs for that, just download the config file specified by the provisioning URL and un-AES it with the key/iv in the provisioning URL.

Just that you need to authorize yourself to have the google talk scope.
And its a lot easier if your oauth client has an application type of 'other' instead of web, so you dont have to have a web redirect url.

To grab an authorization code, just browse to something like this:

»accounts.google.com/o/oa ··· ient_id=

Then trade that for a refresh key:

curl \
 --request POST \
 --data "code=<authorization code>&client_id=<your client id>&client_secret=<your client secret>&redirect_uri=urn:ietf:wg:oauth:2.0:oob&grant_type=authorization_code" \
 https://accounts.google.com/o/oauth2/token
 

This is essentially the same thing that's being done here, right?

»nerdvittles.com/?p=19169

I'm thinking that a guide using the web-based tool(s) might be easier for most to understand.

Yep. [Never seen the oauth playground before. Pretty slick. Too bad they don't put fucking google talk on the pretty dropdown]

OAuth is all about just getting rid of the user/pass as keys to the account correct?

Are 'app passwords' acceptable with these higher security rules?

How to find out what "client_id" and "client_secret" do I have? It looks like my Google account and its password doesn't work here...

OZO, I haven't tried it yet, but looking at the latest diff and the directions there, I think you're supposed to make up your own client ID and secret. I'd suggest looking at this

»nerdvittles.com/?p=19169

Starting with the section 'Obtaining Your Google Voice OAuth 2 Credentials for XiVO'

save your made up Client ID and Secret (notepad maybe?) and follow the guide there up to and including step 6, but use your made up ID and Secret, save the refresh token provided to you too, set up the line (like above, under the diff download) and put it in the AuthPassword field.

***I THINK.***

These instructions are not quite correct. They make use of an already created client_id.

To generate your own, follow the instructions in the first post of this thread - »[Asterisk] OAuth 2.0 Support for Asterisk 13 or Asterisk 14 .

In my directions to OZO, I'm saying to make your own up instead of using the ones there. I don't think you have to generate them. I could be wrong.

I was using the specific post your pointing to ask if this was essentially the same steps that needed to be taken.

The client_id is associated with a developer account. I suppose it's not 100% required to make your own, but I did chose to do so any way so it's not associated with any other google account.

Well, now you have me wondering if we can make them up.

To be honest, I wouldn't be surprised if the ones on that post would work, it's for access to Google Talk APIs after all.

*I don't recommend it*

Thank you, jsolo1 . I'll keep that in mind if (and only "if") I decide to update OBi to the new firmware. So far I still use OBi100 with the old build 1.3.0.2824, that can use old user/password login combination. But frankly, I don't feel any need for OAuth2 for myself and try to keep it this way till I can

I'm curious to hear 2824 still works with Google Voice for you. I realize Google has dozens/hundreds of servers in various versions, but I would have assumed by now all would require TLS. I believe they started that rollout in 2014.

Very interesting thread. It might come in handy in the future if my OBi110 (GV) no longer works with user_name/password. I've been using this version for years. It's been set and forget. It's been working flawless. In my case I don't see any need to update.

SoftwareVersion 1.3.0 (Build: 2824)

You guys are geniuses! I just bought a ten dollar "testing" obi100 from ebay, and when it comes, I'm going to load the pre-OAUTH (2824) firmware in it and see if it connects with just the user name and password. Of course, my old obi100 has been connecting just peachy for at least a couple of weeks with the latest "stock" firmware (2886) too, so, does anyone know why the un-modded obi firmware is now connecting OK? BTW, was naf ever a sailor, or a cavalry trooper?

Re. using the pre-OAUTH firmware, if one is using a "throwaway" google account, why should anyone, including me, care if user name and password are sent "plain text" or otherwise, un-encrypted?

Could someone please translate this into something that I (and other non-geniuses) might be able to understand?

Although they are stored on your device in a retrievable format, they are encrypted via SSL/TLS when sent to Google.

You don't care about this if you configure your device with its internal web server. It's just like configuring any SIP-based provider. As long as you have a properly-configured firewall and good network security practices, you're safe.

Google was concerned that so many people's usernames and passwords were stored in OBiTALK's servers. Since most people didn't use throwaways, the unlikely event of a breach would mean the attackers would gain access to not only Google Voice accounts, but Gmail and all other Google services. That is why the decision was made to switch to OAuth2.

Thanks for the reply. Does my old HT286 that I am connecting to the Simonics GVGW using SIP encrypt the user name and/or password? And why is the un-modded 2886 firmware now connecting to Google Voice OK, and has been for weeks?

Strictly speaking it hashes it with MD5 digest authentication (Google it if you're curious). Hashes are one-way, encryption is two-way. Google rolled back their certificate changes for an unknown reason. It's speculated this is temporary.

That is why I would like to know if 'app passwords' are an acceptable trade-off from OAuth2..

If the user-pass gets leaked, it won't give access to the account..

Thanks for the reply. I, like most folks, use MD5sums to verify the integrity of various downloads. It's easy from the Linux command line. So does this mean that our SIP credentials can be wiresharked and then easily read?

They'll be salted, so not easily, but it isn't impossible.

MD5 for passwords is basically considered broken.. MD5 for downloads is still acceptable, depending on what you are doing, but there are better choices.. Download sources have not been providing the MD5 hashes for files the last couple years (I noticed them not being posted in 2017)

I'm thinking that some of my recent downloads came with MD5s. My take is that MD5 might not be good for "secrecy" but is still useful for verifying the integrity of downloads, n'est-ce pas?

It's fine for confirming that a few bits weren't corrupted by defective hardware, or that a software bug didn't drop a byte or a block.

But, it appears that a well-equipped malicious attacker can add malware to the download, along with carefully crafted data (that won't be executed), such that the MD5 is the same as the original download. See 'Collision vulnerabilities' in »en.wikipedia.org/wiki/MD5 .

Where do you get the key/iv isn't it stored in $SPRM0/$SPRM1?

Ya, just point the ConfigURL at your own server with those as params to see their values.

Thank you very much, gentlemen! I just updated my Obi100 with the naf5 modded firmware, and configured it for GV using the Obitalk portal. The Obi portal gave me some crap about the Obi100 and Obi110 being EOL and that I should "upgrade"...and here is their message:

" Configuration has been updated successfully.
Device Configuration - OBi100
The OBi100 and OBi110 has reached it's (sic) end of life (EOL) status and are no longer supported.
Please upgrade to a more recent OBi device to receive support.

Recommended devices to upgrade to:
OBi200
OBi202"

SUCCESS! The Obitalk portal configured my Obi100 OK, and it now works peachy keen with GV! Does anyone have the correct Obihai address to which I may mail the required F-YOU postcard?

B.T.W., I bsdiff patched (newcerts5.fw.bsdiff) the "stock" 2886 FW, and I then compared MD5sums with the linked naf5.fw download and both had the same MD5, so you can safely use the naf5.fw download-no need to bsdiff patch yourself. (here is the correct MD5: 94705c3425dd5b7864e86c8537527a99 naf5.fw) I really enjoyed "sticking" it to Obihai, so THANKS AGAIN you reverse engineering wizards!

Oh, just ask nicely? Classic.

Today out of curiosity I installed 2824, reset its configuration, turned on less secure apps, and tried to configure the OBi with a username and password. I got the typical "Backing Off (1s):TCP connection to 74.125.28.125 failed" error. I tried several different DNS servers which returned different IP addresses for Google Talk, but all produced the same error.

So, at least in my specific case, 2824 doesn't work for Google Voice. If there's something I missed, I would be interested to know.

Im with you. I don't see how 2824 works for anyone today.

@Mango

Looks like the solution in »Re: ObiHAI Obi100/Obi110 Firmware Mod Discussion is the best. Generate your own oauth tokens and away you go.

It will keep using the old access_token until it is overwritten by a token refresh. I would force a token refresh by going to google security and removing obihai's access to gtalk and rebooting the device.

Take a look at the syslog when coming back from the reboot. Token refresh should look something like this if everything went ok:

<7> GAPI:Refreshing tk
<7> Using AuthPassword as token request override
...
<7> GAPI:refresh tk ok
 

If its not using the AuthPassword, the second line would be something like:

<7> No AuthPassword. Using original obitalk-supplied client/secret/token
 

Syslog showed an error and the OBi110 didn't connect. I then replaced the PW with the real credentials and syslog showed override with PW and it connected, so it looks like it's working. I didn't change anything, so maybe it was a timing problem. Thanks again!

So, will you upgrade to 2886 to use naf's fw?

Like you, my Obi110 still running 2824 but built an asterisk server early last year to take back control of my 110.

Might be worth making the jump now that naf has custom FW here.

I don't really use Google Voice except for experimental purposes, but I have been running naf's firmware since he published it to help in testing. I say "help" although I haven't really done anything because it's been 100% stable.

Nice website

Nice firmware

Great work guys! Appreciate the work you all put into this.

hi i have my obi firmware update page up, and i have the new firmware in my downloads. will you explain exactly what we do next. i'm afraid of ending up with a brick. thank you nellie

Bravo! kudos! Great work guys!

You flash it through the web UI just like any other firmware. Probably a good idea to back up settings first, just in case.

2 of my obi100's reconnected ok after flashing NAF7. 1 required GV to be deleted and reinstalled to get reconnected. Glad I found this group!

"Choose File" the firmware file in whatever directory you downloaded it to. Press "Update" and press "Yes"

Great work to you reverse engineering wizards and making the FW easy for us to update our Obihai's. Thanks again.

you guys are great no doubt about it...

thanks fellas

removed post (inappropriate area)

thank you. i was thinking more steps were required. nellie

Have you had any progress on this? I tried restoring the config from backup, but it didn't work.

Thanks

GV supports cnam for every customer. I believe it can be switched on by the ata fw. Anyone looked into this?

Care to back up that statement with any evidence? AFAIK, Google Voice has never supported CNAM.

My previous GV voip setup (GVjackapp on MagicJack hardware) displayed the caller name on the phone. That is my only evidence. Sorry, I should have started with that.

^^It sounds like the GVjackapp did the lookups.

---------------
»www.pcphonesoft.com/gvja ··· ils.html

CNAM Caller ID Name Reverse Number Lookup
:::Using the national CNAM/LIBD database, caller id name reverse number lookup service is available for incoming calls from US/Canada phone numbers. Look ups are just $0.01 each available in $10 prepaid increments.

What goes for "blam" & "blorg"?

I assume this xml is something that has to be hosted on some web server? Some actual url accessible via internet? I suppose possible to run a local web server too.

Wonder if this can be used on a 200 series boxes to bypass obitalk entirely too?

I think he means literally "blam" and "blorg" will work.

Nice! What needs to be changed in this line for sp2/3/4?

SP2 should be "VoiceService.1.VoiceProfile.1.Line.2."

This is what it was doing because I never paid for any extra services and unknown incoming calls did display the state they were calling from. Both really nice features.

Caller ID with Name / Location
:::The caller's name and number is sent to your phone after the first ring. If the name cannot be located in your online Contacts (or Speed Dial list if you have the Professional version) the caller's location (state or country) is displayed.

I'm guessing the Obi doesn't have access to my contacts. Maybe in the future?

They have it now, but it is a paid addon from Obihai.

Tried this with a obi202, no go. Looks like it's ignoring the URL specified in ConfigURL when the SignalingProtocol is set to google voice. Am I right to assume there's some flag in there that you changed in the 1xx firmware so it works?

Hold up hold up hold up. I don't know what you're trying to accomplish on a obi202 at all, because (as far as I know) you don't have a fw that can use oauth tokens that aren't provided by obitalk, so unless you can get a *valid* refresh token using obi's client_id/secret, you probably shouldn't be writing anything to X_GApiRefreshToken (if that even exists on the different fw/sw of obi202)

Also, it doesn't seem like you're even talking about the right setting for ITSP provisioning...

So... in conclusion... "no"?

^^My ultimate goal is to eliminate any need for obitalk portal for any kind of provisioning.

Under service providers/itsp profile {x}/general is the "SignalingProtocol" setting options are sip and google voice. For gv it makes sense that this be set to google voice, right?

Aside from that I see your point. Firmware would need to be modded so it could use non obi tokens.

I have tried to follow your steps and decompress deflated streams starting at 0xf3cee in newcerts7 patched FW binary. Most streams decompressed fine after prepending them with 10 byte header except one located at 0x168d52. My gzip complains about length error. After making change 0x7ccdb -> 0x7ccdc, no complain from gzip anymore. Not sure if its matter.

Are you thinking about making a patch for OBi2xx to use self generated OAuth credentials?

You are of course right about the uncompressed length of 0x168d52. Apparently I fat-fingered it. Luckily I'm let off the hook by the inflate routine at 0x1a30be/0x1ff68e not checking I don't have an obi2xx, but if someone else is working on one im sure i could chip in some ideas.

...and the patch should be 100x easier since its dynamically linked and IDA supports ARM so you dont have to fucking script putting the string constants into the fucking incorrect disassembly from mipsxdis

And here's the hint: if you look in /obi/obiapp at the token refresh sub at 0xD9760, the obitalk refresh token is in [R7,#0x3C]. The AuthPassword should be in [R7,#0x38]. Just use that instead of all that sprintf concatenated crap.

My Obi110 Is working with Google Voice again, thank you for making me the owner of my own device!

A few years back when GV stopped working and I made the irreversible 2886 firmware upgrade, I tried to use the Obihai portal, not only they wanted me to share personal information, when I enabled access to my device, without any previous warning, I was requested to pay to have the service activated. I didn't and since then it got stuck in "Service not configured".

So I updated the firmware to naf7 and was dreading to go to the portal again, but today I did the XML file trick and I was spared of that, Thank you!

Thanks for the code, but I'm having problems getting this to work on my OBi110. I'm an XML novice and not sure I created the file correctly. I used Notepad to create the file. I set the "File Name" to file.xml and "Save as Type" to All Files.

I put the XML file on a dd-wrt router's NAS drive, but I don't know how to code the ConfigURL I can access the NAS drive in Windows using File Explorer. The path under Network is Router_Name -> USB_Storage -> file.xml
I tried the following in ConfigURL and both failed:

http://Router_Name/USB_Storage/file.xml
http://192.168.1.1/USB_Storage/file.xml
 

I also pointed to an OBi config backup file, so I could see if it worked. It didn't.

The OBihai Forum provides XML files to update digit maps for foreign countries. These XML files are applied by using the Restore Configuration option under Device Update. I tried the Restore function with your XML file, but it also didn't work. The SP1 status is "Service Not Configured".

I didn't know if I should change Encoding on the XML file, so I tried both ANSI and UTF-8.

I manually configured GV on the OBi110 SP1 after a factory reset before trying the above with the following 2 changes:
SignalingProtocol: Google Voice
AuthUserName: My_UserID@gmail.com

Please help!

You can't do it that way.

Take a look at this link, scroll down to procedure.
»www.dd-wrt.com/wiki/inde ··· B_server

Using that example you can upload your file to the jffs folder. Depending how you have your ftp set up it'll be accessible directly or you'll have to move it there manually.

You can test if the url work by pasting it into a browser. If the xml is opened or you're prompted to download, then you should be good to go. Perform the test using incognito mode or a different browser. With asuswrt firmware I'm prompted to login first before I can access the file. Don't recall how ddwrt works as I don't have it on any routers in the vicinity.

@OBi1FW Are you able to also host dummy XML files for SP1 and SP2 to use for ITSP ConfigURL, as per @naf's post? Thanks.
Reference: »Re: ObiHAI Obi100/Obi110 Firmware Mod Discussion

Is there a reason why the Restore Configuration procedure isn't working with your xml file? ITSP Provisioning is getting too complicated for me. I hate to give up now. This is the last step I need to totally get off OBiTalk.

Can I upload the XML file using the restore configuration? I tried Obitalk portal and loading the token directly on the obi110 web page without any luck. I already loaded the patched firmware which seemed to work fine and it now report the name of the patched firmware.

No, setting the oauth token doesn't work when restoring a backup.
Either ITSP provision it, or just use obitalk for the initial provision (and then turn it off and revoke its access to gtalk and just use AuthPassword override if you like)

I second the idea that OBi1FW could add 2 static xml files to make it easier for those that might not have http servers handy.

Success!!!!! I found a super easy free Windows http server and hosted the xml file myself. After defining the ConfigURL and rebooting, the status on SP1 became Backing Off. I added my GV credentials and it connected.

The http server is Mongoose. Download the binary here:
»cesanta.com/binary.html

Store the binary in the same folder as your xml file and double click on it. That's it! All the files in the folder are available on port 8080.

ConfigURL: http://192.168.1.100:8080/file.xml
 

I tried Obitalk with no luck. I think I tried with and without also putting a refresh token in where the device web page has a spot for password. What do you mean by "just use AuthPassword override"? A step by step would be really helpful.

As an alternate I have a couple boxes with LAMP that I think I could use to serve the xml file.

Looks like the obi supports tftp too.

»tftpd32.jounin.net/

Tftp is similar to ftp but without the authentication part. Very easy to set up. Once the keys are in place there should be no need for further action unless the unit is factory reset.

Thanks. If I understand it correctly, after the patch it'll either use obi's access_token, or self generated refresh_token. It won't be able to refresh obi's token, unless I find a space to check the length of AuthPassword and refresh token conditionally.

The strategy I used in naf7 was to leave access_token reads untouched, and just do the switch on the access_token write based on the AuthPassword length (null/zero length AuthPassword --> use the obitalk-provisioned client_id/secret/refresh_token to get the access_token, else just use the AuthPassword itself as the access_token request).

P.S. if you want to talk OBi20x patching, lets move over to the other thread »Obihai OBi20x/30x + OBi1000 + OBi50x + OBi2000 firmware mods

Ok, I would be glad.

»obi1.s3-website.us-east- ··· TALK.xml

I made one file that sets both SP1 and SP2. It's ok if you want to use one of those for SIP.

Today afternoon I am working on an interactive tutorial to generate client_id, client_secret, and refresh_token.

So there should be no reason for someone on pre-Oauth firmware to not try this 2886-naf7 firmware, because they can always revert back to 2824 or earlier if they wanted to?

Seems like a good way to get any other improvements made by Obi to the firmware even if you don't use GV currently.

Here is the tutorial I made for manual configuration of Google Voice. Corrections are welcome.

»obi1.s3-website.us-east- ··· /OAuth2/

This is not really necessary, yet, because the OBiTALK portal still works, for now. We don't know how/if Obihai is going to respond to the new firmware, nor what Polycom will do with OBiTALK long term. If the portal stops working one day, or if you just don't like to use the portal, you can use this technique.

This is based on instructions posted by naf and RonR (thanks to jsolo1 for the link).

Ooooo; I guess I saw that earlier out of the corner of my eye, but didn't really let it sink in.

I'm in that camp, still using my pre-Oauth firmware on my Obi100 (2776 at present). None of this has been an issue for me because a while back I started using Bill's GVGW on SP1 and it works so flawlessly that I've not been tempted to try the naf7 FW.

Has anyone actually verified that one can go from 2824 to 2886-naf7 and back again? Your question mark, JTS33, suggests that you aren't positive either...

Yes, I can verify this.

Thanks Mango. Good enough for me...

This is only a suggestion. As a precaution, perhaps you could disable Auto Firmware Update and clear the FirmwareURL in your XML file.

Well, by default it is already that way. The only way it could be changed is if the user changes it. (Or if OBiTALK changes it, but if they're using the XML file, they probably don't use OBiTALK.)

It's a good suggestion though. I always make sure it's disabled on my OBi.

I'm having an issue after updating to naf7 firmware from naf5, after about a day or so, I'll get the "backing off" authentication error with Google Voice and have to reauthenticate through the Obitalk portal. I've tried removing the GV line from my SP1 and re-adding it back on, but same thing happens.

Is this happening to anyone else? Can I try anything else to fix this?
I didn't save the naf5 firmware to revert back though (I rely on OBi1FW's website for my FW), but don't see how this problem could be related to changing to naf7.

One reason would be if you didn't have the old fw to revert back to

if you're going to use obitalk, just Reset Configuration and start over. (you didn't use the xml file to provision bogus tokens did you? they're quite sticky and only for people using AuthPassword override and no obitalk)

So the RC4 just encrypts the device's private key and obi-signed cert in the OBI100 UNIT INFO section.

What the fuck is the point of encrypting that? If I can read it, I can clone it, encrpytion and all. I can't modify it because its signed, encryption or not. I don't get it.

I was having the same problem on one of my Obi100's with Naf7. If I interrupted the power, I had to re-authenticate to get connected again. I deleted it from Obi-talk and re-installed it again and that fixed it. Now I can interrupt the power and it will connect once power is restored. Obviously something had changed by doing this.

Security by obscurity? Did you figure out purpose of the chunk of data located at offset 0x0120 of OBI100 UNIT INFO?

BTW, by modding this structure you can easily enable 2nd phone port on obi200 that is connected to the 2nd pair of conductors of rj11.

ya, thats where the encrypted private key and obi-signed cert begin.

come again?

Holy s**t! They populated all the discrete components for the second SLIC??? That wouldn't make sense unless there was an 'OBi200x' that was sold in huge quantities to some OEM or perhaps a big player like Vonage.

Edit: Doh

In which they would use the OBi300/OBi302

The obi200 only has one fxs port. Typically, only a single pair is needed per line, so if both pairs are used (4 wires), it's possible to have 2 lines on one cable.

It is an open secret that embedded developers do shoddy programming. They create things quickly and the first thing that works without fatal downsides is what goes into production. Designing things well so that they are maintainable or have proper security is an afterthought.

That costs money, therefore bean-counters want it avoided..

When I did a "Reset Configuration" of my Obi110 on the naf7 firmware, I noticed that the config is more like an Obi202, with 2 phone ports specified (ph, ph2) and 4 service provider slots specified (sp1 to sp4) in the DigitMap and things like that. Anyone else notice that? I used Obitalk portal to configure my device for Google Voice.

I'm new to Obi's. I'm running stock firmware (1.3.0 2886) on a 110 model. I also used Obitalk to configure for GV. It has been working 100% for 3 weeks. The local ui (192.168.1.5) shows 2 phone ports (sp1 and sp2), 2 service provider profiles (itsp-a and itsp-b), voice service parameters for sp1 and sp2, and 10 user defined digit maps in addition to the sp1 and sp2 maps.

The naf patch allows you to change back to the stock firmware.

do i send sp1 to the trash first? nellie

a simple answer yes or no would be appreciated nellie

Does not matter. I didn't.

Please test it, record your observations, and let us know what you find.

it is working perfectly with google voice connected. i purchased this obi100 on ebay to experiment with, and i want to back it up first. then i will try updating it as is. hope to get to it today. thank you nellie

very easy install on obi100. went into obitalk portal to set up GV. works. very pleased. thx

(really unfortunate that obihai not officially update fw for old obi's. shame on you obihai.)

hi i updated to the naf7 successfully with all your help. thank you nellie

Hi Mango. I too loaded 2824 fw into my an Obi100, and it would not connect using password and username. (backing off) However, I ran across this »productforums.google.com ··· hkqzIIV0 in my travels, and this might explain why the long time 2824 fw users can connect while we "Johhny come lately"s cannot connect!

I believe you need to allow less secure apps in your GV account.
Go here:
»accounts.google.com/
Under Sign In & Security click Apps with Account Access
Turn on Allow Less Secure Apps

I'm happy using my own credentials with naf7 fw, so I haven't tested 2824. Please let us know if this works.

I turned on support for less secure apps, and I tried the new device "captcha"...no luck so far...but, I am still trying some things...,

I've been running 2886-naf7 successfully for some time now. I've noticed a possible very minor issue in that if power to my OBi100 is cut and later restored, sometimes the power light is blinking green, although the OBi is otherwise working normally. If I reboot the OBi using the web portal, the power light is then constant green. Not sure but I don't remember this ever happening with the official firmware. No big deal. I've had this device for many years so I suppose it could be a hardware issue.

I just tried disconnecting and reconnecting the power and it didn't happen, so it's not 100% reproducible.

Hi,
I flashed naf7 on my Obi110, system info page shows 1.3.0 (Build: 2886-naf7)
I followed the guide »www.obifirmware.com/OAuth2/
I'm having an issue where the Obi resets itself and SP1 becomes unregistered, and all the data I enter in ITSP and SP1 is wiped off.
1. I set ITSP to the XML and system start, but after 2 reboots it reverts to Disabled
2. After I do all the google oauth steps, on the last page of instructions i set SignallingProtocol to Google Voice and then submit
3. without reboot (I also tried to reboot after every setting change) I go to voice SP1 settings and set username and the auth token. I hit submit then reboot. OBI110 reboots twice, and after I refresh the web interface all the settings are gone.

Any idea what I'm doing wrong?

Thanks!

You probably forgot to disable OBiTALK Service and provisioning. Without that, OBiTALK will keep resting whatever you configure locally.

As for 1., that is expected. The XML unsets urself because it only need be done once.

Thanks for the reply!
How do disable obitalk service? just remove the device from the account?
How do i remove the provisioning? delete the profiles (on obitalk) from device?

Disable OBiTalk Auto Provisioning.

System Management -> Auto Provisioning
Under OBiTalk Provisioning
Method: Disabled

Does using Simonics mean that I don't have to worry about this firmware change issue anymore? I do get CNAM with Simonics which is nice, but I have to wait 2 seconds before I say hello when answering a phone call.

Correct

Additionally, if you use a SIP phone rather than an ATA, you won't have to wait for the first ring

Weird thing happened last week. After the Obi started working again on its own last December it again stopped. When I went to Obitalk my Obi100 was not shown. I tried the factory reset with the reset button, which is a real pain, and no luck. Then I used the ***8 1 method and that did the factory reset, and then I was easily able to re-provision my Obi.

Now why the unit suddenly disappeared from the Obitalk dashboard I have no idea.

BTW, now using 2886-naf7, and thanks.

Did it disappear from the Obitalk dashboard while you were using naf7?

I'm a little surprised Obitalk allows any version of naf firmware to work. Perhaps they just look at the digits ...2886 and they're happy. Then again, maybe they are catching on and making the Obi's (with naf) disappear from the Obitalk dashboard to frustrate users (I doubt it.)

Of course the real benefit in using naf7 is that Obitalk is not needed and, perhaps in the future, will be the only way to keep the 1xx boxes working natively with GV. That is GV without needing Simonics Gateway (or similar.)

No, it disappeared before I installed naf7.

I was working on a Obi100 today with a fresh reset. I could not log into it until I let the Obi connect to the internet first. After that, no problem connecting directly to the computer. My question is, did it go to Obitalk to register (or something)? And if so, would we all have problems after a reset if Obitalk disappeared someday? My gut feeling is it goes to Obitalk and simply unblocks the WAN port? If so, that may be an easy (for naf ) setting in the firmware which would solve the problem for people that reset the box after naf firmware was installed. The people with stock firmware would have a brick after a reset (if Obitalk was shut down.)

This might be another Obitalk requirement that should be eliminated. My Obi302 did not have this issue. Maybe because it has both WAN and LAN ports. The computer happily connected directly to the LAN after a fresh reset.

Hi, I recently switched from simonics to naf7. I used obitalk portal to reconfigure my google voice, it worked for a day and now I am getting "backing off, authentication error"....I resolved it by re-entering my credential but few minutes later I am getting same error. Any idea?

I saw there is a OAuth feature for not using obitalk portal, is that is the solution to this "backing off authentication error" problem?

I have an Obi110 using Obitalk and it has been reliable. You should try logging into your simonics.com account and click the link "Deauthorize Google Voice connection".

I generated my own credentials for my Obi302 and Obi100 and they have been reliable as well.

Can the current version FW survive the upcoming GV change in June?

lol

I'm guessing you'll find out in June

Thanks for information. I logged in and deauthorized simonics and it worked for 2 days (rather few hours) but again back to same problem with google authentication. Is this OBI issue or Google? It seems like obitalk with nav7 working fine for you, so it must be some other issue. Any other idea?

Thanks.

My Obi110 with Obitalk is using stock firmware. I have not tried the combination of naf7 with Obitalk. I would recommend you stick with naf7 and generate your own oAuth2 credentials. That is probably the only combination that will have a chance come June 18.

Correct me if I'm wrong, but I don't think the use of oAuth2 for authentication has anything to do with the use of XMPP for voice communications. In other words, just because you switch to using oAuth2 doesn't mean that you are not using XMPP and that you won't be impacted if Google drops XMPP support.

True. I just feel Obitalk will completely drop support for the Obi1xx boxes on (or before) that date but maybe Google will slowly (or never) change over. Remember their false alarm in 2014?

Thanks. I will try OAuth2.

I'm new to all of this. I have an OBi 110 that no longer works with GV, so I'm considering downloading the naf7 firmware from www.obifirmware.com.

How can I convince myself that the firmware is safe and that it won't either insert a worm into my local network, turn the OBi into some kind of zombie bot, or hijack my Gmail account? I want to trust it, but these days you can't be too careful!

This forum is populated with a good crew of people, largely regulars (to which I'm relatively new!). Naf is known around these parts. You have nothing to worry about.

The bad news is that you won't be able to use your 110 much longer (apart from using it as a regular ATA). It appears that Google may be making it impossible for 3rd party firmware to accommodate the changes in store for GV.

hey they finally updated the certs to GIAG3 (again) so naf7 is required again:

# openssl s_client -connect talk.google.com:5222 -starttls xmpp -xmpphost gmail.com </dev/null
CONNECTED(00000003)
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = gmail.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=gmail.com
   i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
 1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
   i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
 

long live naf7, atleast for another month ;-)

I'm very curious if naf7 still works with the new Google Voice setup (XMPP support ("chat" option) removed)?

Yes it does, but outbound only. I have an OBi200 with 5859 and an OBi110 both defined with the same GV account. Outbound on the OBi110 works, but not inbound. I'm routing inbound from the OBi200 to the OBi110. When outbound fails I will route outbound from the OBi110 to the OBi200.

Thanks azrobert,

I have not yet let Obihai modify my Google Voice account and my 100 and 302 are still working for inbound and outbound calls. I plan on leaving it this way until it fails.

I'm wondering now if someone opens a new Gmail/GV account now do they get the "chat" option?

Try it and see and report back!