Any way to edit AIT chipset based firmware to change bitrate?

[conceptionist]

I searched all over the web and found no entry on this topic, I recently purchased KDLINKS R100 rear-view mirror dash-cam from amazon claiming to be 1296p, it's video quality however is slightly subpar to my Galaxy S5 1080 resolution when compared side by side. I was wondering if there is any way to increase bitrate or other quality values on the firmware I received from them that supposedly includes few bug fixes. I checked the header on the file and it mentions 'JADO CHINA', did a bit of searching online and found this product page from china that likely belongs to the supplier that sells the same product to second hand dealers. Anyone with knowledge on this topic, please respond.

 

[jokiin]

I'd think you're possibly on your own there, AIT is used predominantly in lower priced products and doesn't get a lot of support, lucky to even find a firmware for one

 

[conceptionist]

I'd think you're possibly on your own there, AIT is used predominantly in lower priced products and doesn't get a lot of support, lucky to even find a firmware for one

I was fortunate to get the firmware from seller who got it from their supplier to fix format card issue. I'm messing around in IDA Pro disassembler, loaded up the firmware as ARM (little endian) and got to work finding the bitrate values, what do you think..

looks like the 0x12 (18) and compares to max value 0x19 (25), should I try changing those 0x12 to something else..?

 

[jokiin]

maybe have a look on the goprawn forums and see if anyone there is doing anything with AIT chipsets yet, even if not maybe one of the guys there will have some ideas

 

[jokiin]

check with @nutsey also, he might have some ideas

 

[conceptionist]

I did search in that forum for AIT, nothing came up.

Anyway, think I just managed to change it to 24 bits by changing HEX values from 12 to 18, I'll let you guys know if I bricked my unit after I try it. If it all works out, I'll go after frame rate next. Keep you guys updated. Thanks for all your help.

 

[Tobi@s]

Sounds interesting, unfortunately the chipset is not that popular. There might(very likely will) be a checksum in the firmware header that prevents the modified firmware from flashing

 

[conceptionist]

Sounds interesting, unfortunately the chipset is not that popular. There might(very likely will) be a checksum in the firmware header that prevents the modified firmware from flashing

You are right. The procedure began with MD5 check. It of course failed. Now where do I begin finding the MD5 it checks against and generating new one to replace with. Should be easy if I'm not mistaken. I bet they do this to prevent corrupt flash loads not against modifying, there shouldn't be any protections in place theoretically speaking.

 

[conceptionist]

I'm willing to bet this highlighted hex range contains MD5 key

Now all I likely need to do is cut off everything below it into separate file and generate new key, voila.

 

[Tobi@s]

Well there are several ways: you could scan the binary for known crc generator polynomials so youd know you have to look for a crc sum.
This is how we(actually @nutsey) found it in Novatek: Almost identical firmwares with only a few different bytes, the different bytes in the header were the checksum (its really only a simple sum, see novatek hacking thread)

How i found it in ambarella (and the best thing you could try): getting access to the debug shell through uart (most manufacturers dont remove their uart port/keep the pinout) and hope that it tells you whats wrong with the modified binary - for example the invalid checksum/md5/...

 

[Tobi@s]

I'm willing to bet this highlighted hex range contains MD5 key

Now all I likely need to do is cut off everything below it into separate file and generate new key, voila.

Most of the time the checksum only validates the payload. I assume that the binary is aligned and the payload starts after all the 0x00 padding bytes. Best thing would be to get another firmware binary to compare the header

 

[conceptionist]

Most of the time the checksum only validates the payload. I assume that the binary is aligned and the payload starts after all the 0x00 padding bytes. Best thing would be to get another firmware binary to compare the header

I don't have another file. But..

I did manage to find routine that handles Md5 check, not sure what I'll do with it.

 

[Tobi@s]

Oh thats cool. Where does the payload start? Just calculate some md5s for payload likely areas

 

[conceptionist]

Oh thats cool. Where does the payload start? Just calculate some md5s for payload likely areas

Tried many likely points, they don't match to original md5 in header. Am I doing something wrong?

 

[conceptionist]

I'm thinking using another method that might work, make a custom switch to swap micro-sd card once the original firmware check goes though and right before it begins loading flip the switch to another card with modified binary. what do you think?

 

[Tobi@s]

I think you might not be fast enough with this method. Even with a low reading rate like 1MB/s the firmware is loaded faster to RAM than you can do your hardware trick. Would still try more md5 checks. If the file isnt that big you could write a small script that calculates the md5 for many different starting addresses till EOF
Or you go the uart route

 

[Tobi@s]

Tried many likely points, they don't match to original md5 in header. Am I doing something wrong?

Oh I forgot something very important to mention: Keep the byte order in mind. did you compare hex or decimal md5 sums?

 

[conceptionist]

Oh I forgot something very important to mention: Keep the byte order in mind. did you compare hex or decimal md5 sums?

I compared these hex @ 00000010h: 34 F4 3B CC 32 25 60 F2 FA 4F A0 ED 1D C8 BE 5E, how can I compare decimal md5 sums? And by byte order you mean not cutting off before nor exceeding every hex rows of 16?

 

[conceptionist]

I think you might not be fast enough with this method. Even with a low reading rate like 1MB/s the firmware is loaded faster to RAM than you can do your hardware trick. Would still try more md5 checks. If the file isnt that big you could write a small script that calculates the md5 for many different starting addresses till EOF
Or you go the uart route

I was thinking of that, a way to automate and brute every point till matched md5, maybe there a program that can do that, I can only code in PHP, that might work with a bit of trial and error.

 

[Tobi@s]

Php might be a bit slow but will still work.
Just a loop that starts at 0x10 or whatever seems good and ends somewhere in the payload.

Byte Sex/Byte order: there are two possibilities: little or big endian. Big endian means mst(most significant bit first) while little endian means least significant bit first (lsb)
0xaabbccdd as big endian: 0xaabbccdd
As little endian: 0xddccbbaa
So if its stored as little endian you cant simply read the 16 byte from left to right

Your md5 was most likely already in hex format, so if you got a md5 that looks similar to the 16 byte from the header (for example all bytes read from right to left) youve already found it


Is there no chance to get access to another firmware?