Custom Sylvania ROM development

[vio]

I didn't have too much time today, but I managed to take a look at the decompiled method. The results look promising, even if the code seems incomplete:

• _t51, _t52,..., _t57 are pointers to consecutive bytes from an array, so we can replace them with r2, r2[i+1], ..., r2[i+7]
  [*]*((intOrPtr*)(4509488 + (index * 4)) can be considered as a value in a lookup table
  

Considering a CRC implementation using a lookup table as described in this article (crcFast method), the decompiled code can be simplified as below:

L00401B60(_unknown_ r1, char* r2, _unknown_ r9)
{
    _unknown_ r4;
    _unknown_ r5;
    _unknown_ r6;
    _unknown_ _t49;
    _unknown_ _t50;
    char* _t51;
    char* _t52;
    char* _t53;
    char* _t54;
    char* _t55;
    char* _t56;
    char* _t57;
    _unknown_ _t83;
    _unknown_ _t84;
    signed int _t85;
    signed int _t86;
    _unknown_ _t88;
    _unknown_ _t89;




    _t88 = __eflags;
    _t51 = __ecx;
    _push(_t85);
    _push(_t83);
    _t84 = 32;
    _t86 = _t85 | 255;
    __ebp = _t84 - 28;
do {
        data(i) = (r2[i] & 255 ^ _t86)& 255; 
        crc(i) = _t86 >> 8 ^  crcTable[data(i)];

        data(i+1) = (r2[i+1] & 255 ^ crc(i))& 255;
        crc(i+1) = crc(i) >> 8 ^  crcTable[data(i+1)];
        
        data(i+2) = (r2[i+2] & 255 ^ crc(i+1)) &255;
        crc(i+2) = crc(i+1) >> 8 ^  crcTable[data(i+2)];
        
        data(i+3) = (r2[i+3] & 255 ^ crc(i+2))& 255; 
        crc(i+3) = crc(i+2) >> 8 ^  crcTable[data(i+3)];
        
        data(i+4) = (r2[i+4] & 255 ^ crc(i+3))&255; 
        crc(i+4) = crc(i+3) >> 8 ^  crcTable[data(i+4)];
        
        data(i+5) = ((r2[i+5] & 255 ^ crc(i+4))&255);
        crc(i+5) = crc(i+4) >> 8 ^  crcTable[data(i+5)];


        data(i+6) = ((r2[i+6]& 255 ^ crc(i+5))&255); 
        crc(i+6) = crc(i+5) >> 8 ^  crcTable[data(i+6)];
        
        _t51 = _t51 + 8;
        _t84 = _t84 - 8;
        __ebp = __ebp - 1;    
        
        data(i+7) = ((r2[i+7] & 255 ^ crc(i+6))&255);
        _t86 = crc(i+6) >> 8 ^  crcTable[data(i+7)];
        
    } while(_t88 != 0);
    
    while(_t89 != 0) {
        data(i) = (r2[i] & 255 ^ _t86)& 255;
        _t86 = _t86 >> 8 ^  crcTable[data(i)];
        _t51 = _t51 + 1;
        _t84 = _t84 - 1;
    }
    _pop(__edi);
    _pop(__esi);
    return  !_t86;
}

I assume that the first loop is computing the CRC using 8 bytes steps, until less than 8 bytes remain. The second loop is processing these remaining bytes.

 

[tfurrows]

Would the >>8 indicate 8-bit steps (1-byte) rather than 8-byte?

 

[Rrok007]

Forgive my ignorance, but a thought just occurred to me. What prevents us from identifying the various chipsets, finding drivers for them, and then just loading stock Android OS on the tab?

 

[vio]

Would the >>8 indicate 8-bit steps (1-byte) rather than 8-byte?

Each operation is using one byte indeed, but there are 8 operations in sequence - hence the 8 byte step.
Anyway, I took some time to study the CRC algorithms and I've done some test implementations. I found out that I can write a CRC algorithm using the code above (I actually implemented one to check my theory).
The problem is, while the algorithm is pretty simple, the calculated value is heavily dependent on the CRC polynomial (the value used to compute the crcTable). In other words, we will need to find the crcTable - it could be hard-coded or calculated at runtime.
So, if anyone is taking another take with the decompiler, try to look for a table with 256 entries - or a method that calculate such a table. Address 4509488 looks like a good starting point.

 

[cfrockit]

The problem is, while the algorithm is pretty simple, the calculated value is heavily dependent on the CRC polynomial (the value used to compute the crcTable). In other words, we will need to find the crcTable - it could be hard-coded or calculated at runtime.
So, if anyone is taking another take with the decompiler, try to look for a table with 256 entries - or a method that calculate such a table. Address 4509488 looks like a good starting point.

Still working my way through the code for insights on the update method so if I encounter anything related to above I'll forward it along.

In the meantime, as they say "Riddle me this one Batman ...", if Disgo has inserted the Slyvania "hwver" how is the update server going to differentiate it's a Disgo?

Here's the Procedure from IUW.exe that is determining OS version. It references two items I looking for insight: 1) OSVersionInfoSize - Size of what is it calculating? 2) MajorVersion >= 5 - vio references Minor/Major version but why "greater than equal to five"?

/*    Procedure: 0x00443BBD - 0x00443C20
 *    Argument size: -304
 *    Local size: 152
 *    Save regs size: 0
 */

L00443bbd()
{
    struct _OSVERSIONINFOA Vffffff68;  /* size = 148 bytes */
    /* unknown */ void  Vfffffffc;

    Vfffffffc = M00458004 ^ ebp;
    Vffffff68.dwOSVersionInfoSize = 0x94;
    GetVersionExA( & (Vffffff68.dwOSVersionInfoSize));
    if(Vffffff68.dwPlatformId == 2) {
        eax = 0x443bb9;
        if(Vffffff68.dwMajorVersion >= 5) {
            goto L00443c03;
        }
    }
    eax = 0x443b54;
L00443c03:
    InterlockedExchange(M0045a818, eax);
    *M0045a818();
    ecx = Vfffffffc ^ ebp;
    return L004120AC();

 

[natura]

infotm_key
42c93d86f4de2dcbe416bfe5a3e80403

(only one -decrypt site results showed these 8 numbers)
20110706

 

[st0ne]

Just so we all know: a new EX7 file opened today.
/222.73.93.45/update/11.2.1.5/11.2.1.5.2.0_beta5.ius
I am checking it now.

 

[st0ne]

Ok I am stuck already. I can't do a 3 finger method to get into the recovery screen. it just keeps booting. I have un rooted it. and still it wont respond to 3 fingers. I am currently running beta_4 on my EX7.


ok I used the OGT method with the tool to push the update.. it's booting now... taking a long time...

 

[st0ne]

not seeing a lot of changes.... they made the back arrow bigger in portrait mode. but all they did was cut off the screen rotate button. and now when a program turns the screen... it doesn't turn back when you end the program. and now no button to turn it back your self.

 

[Jv90]

yeah, keep the beta4, thats better

 

[lorenii]

I hate it when programs auto rotate and there is no way out of it.... sucks donkey kongs...

 

[vio]

Here's the Procedure from IUW.exe that is determining OS version. It references two items I looking for insight: 1) OSVersionInfoSize - Size of what is it calculating? 2) MajorVersion >= 5 - vio references Minor/Major version but why "greater than equal to five"?

Shameless speculation follows...
1) OSVersionInfo is a structure, the size is probably referring to the number of bytes used by this structure. Usually this is needed when using low-level memory access routines (moving bytes from an address to another).
2) The "if" construct looks like some validation code. If we consider the first part of the ROM version (excluding vendor id), we get something like "2.0.5", "2.1.8" and so on. Note that all known files start with a "2" - this might be the "PlatformId". Also, for the third digit we have 5,6,7 and 8 as known values - this one might be the "MajorVersion". All known values are >= 5. Coincidence or conspiracy?
So, we can conclude that the "if" code is checking for some pattern in file version. If the pattern matches, one method is called (0x443bb9). If the pattern is rejected, another method is called (0x443b54) - this one is probably an error handler.

 

[giveen]

Well after getting my RMA tablet back I have v11.2.0.7 and going to update it to Beta-3

 

[cfrockit]

Well after getting my RMA tablet back I have v11.2.0.7 and going to update it to Beta-3

Check your build.prop first for the date and version. Not that infoTMIC is consistent with updates but the returned device may have a newer/better version. Also, the U0 - u-boot-nand.bin - 2009.08-svn661 (Mar 06 2015 - 05:33:51) was different that all of the other updates. Not sure what impact that has on the tablet.

build.prop from 11.2.0.7.2.0_beta3.ius

Dated: 20110301.150645
Version: 10

# begin build properties
# autogenerated by buildinfo.sh
ro.build.id=FRF85B
ro.build.display.id=FRF85B
ro.build.version.incremental=eng.liuqi.20110301.150645
ro.build.version.sdk=8
ro.build.version.codename=REL
ro.build.version.release=2.2
ro.build.date=2011年 03月 01日 星期二 15:08:33 CST
ro.build.date.utc=1298963313
ro.build.type=user
ro.build.user=liuqi
ro.build.host=liuqi-desktop
ro.build.tags=test-keys
ro.product.model=p7901a
ro.product.brand=generic
ro.product.name=p7901a
ro.product.device=p7901a
ro.product.board=
ro.product.cpu.abi=armeabi
ro.product.manufacturer=unknown
ro.product.locale.language=en
ro.product.locale.region=US
ro.wifi.channels=
ro.board.platform=imap210
# ro.build.product is obsolete; use ro.product.device
ro.build.product=p7901a
# Do not try to parse ro.build.description or .fingerprint
ro.build.description=p7901a-user 2.2 FRF85B eng.liuqi.20110301.150645 test-keys
ro.build.fingerprint=generic/p7901a/p7901a/:2.2/FRF85B/eng.liuqi.20110301.150645:user/test-keys
# end build properties

#
# ADDITIONAL_BUILD_PROPERTIES
#
ro.versioncode=10
ro.debuggable=0
persist.service.adb.enable=0
persist.app2sd.enabled=0
ro.suspend.unloadWifiDriver=true
ro.config.notification_sound=OnTheHunt.ogg
ro.config.alarm_alert=Alarm_Classic.ogg
media.stagefright.enable-player=true
media.stagefright.enable-meta=true
media.stagefright.enable-scan=true
media.stagefright.enable-http=true
ro.setupwizard.mode=DISABLED
net.bt.name=Android
dalvik.vm.stack-trace-file=/data/anr/traces.txt

 

[xavim]

You can find such a table in the u-boot (Universal Boot Loader) package (u-boot-1.3.2/lib_generic/crc32.c). The second CRC field is computed with all data included in the entries section, till the end of the file, including any padding in between. Then you set this value into the second CRC field, set the first field to zero, and compute the first field using the header data only, from the beginning, and up to include the second CRC field. Hope this helps.