Jump to content

KingSong KS16 firmware reversing


Spark

Recommended Posts

hey riders,

to speed up my efforts I thought I just ask for partners in crime :D

is the firmware binary crypted?  looking at it in the hex editor right now I'm not sure ;=)

can s1 give me some info about the processor used on KingSong KS16B/C models and the flash rom used? (I dont want to disassemble my wheel yet, as I use it every day :blink1:)

I plan to use IDA PRO to analyse the firmware.

 

the V.125 binary is 49.280 Bytes, so I wonder where is the rest , read the part of the rom where the crap media files are stored (HELLO KINGSONG! ;))

there are two things I want to achieve:

1st disable startup message, bluetooth on off message and please deaccelerate forever.

This could easily be done by erasing those files from where they are stored.

 

2nd speed up my KS16b 820Wh to 35 km/h :D

This could be done by either directly modifying the engine parameters in the firmware

or maybe even by tuning the android app that sets the max speed parameter. (has anyone tried this yet?)

 

If you have read out the flash that stores the media files, that would be helpful too.

Im also looking for all KS16B/C binary files in all versions, in order to compare code changes.

also any info on checksum calculation are welcome, (if crc is just handled by the android app, I wouldnt waste any time on this)

cya

Link to comment
Share on other sites

Couldn't find a clear picture of the mainboard showing the MCU, I'd suspect it's STM32, possibly some STM32F103 (which seems pretty common in the wheels), but I need to open up the B to see it up close (although it's probably coated, so it may be impossible to read the markings). Also, it could be that they just use a bigger version of F103 (more Flash) and stick the voice message data directly into the code (encoded or with some low samplerate / small bitrate to save space), or it's pre-written in a portion of the Flash that is never overwritten during update, so there may not be a separate Flash/EEPROM -chip.

No idea if there's any encryption or not. There could be some sort of bootloader of their own (for updating and/or decryption purposes), so it could be that no decompiler will recognize the binary, as it could be missing the parts at the beginning that the decompiler expects to find to recognize the architecture etc. I have no experience with decompiling raw machine code dumps (I tried it once with KS firmware-binaries too, sometime last year, and without any success :P), so I doubt I can be of much help there. I don't recall noticing anything resembling decryption on the app, if memory serves, it sends the file "as-is" to the board, but I could remember wrong.

Link to comment
Share on other sites

It's STM32F103C8T6, same as (at least newer) Gotways and probably many, many other wheels:

AZrJVJR.png

Kinda hard to see from the picture, but yeah... The board's coated, so getting the markings to show takes a lot of playing around with flashlight and camera. Here's a high(er)-res picture link to entire board, but you won't make out the chip markings due to the coating:   LINK

There's a chip with lots of pins to the upper right of the board in the picture, which is the only thing I think could be some sort of a memory chip. The chips on the lower part of the board are the gate drivers and the current sensors, not sure on others (looks like a couple of voltage regulators at least). The small chip next to MCU is the IMU (gyro/accelerometer).

Link to comment
Share on other sites

I wonder if someone can decompile the KingSong APK which might give some insight into how the firmware is loaded?  Or does the firmware/bootloader itself have a decryption routine when a new firmware is uploaded to it?  I wonder if they decrypt the firmware file in the app as it is being uploaded through Bluetooth... They wouldn't do that would they?  :whistling:

https://stackoverflow.com/questions/12732882/reverse-engineering-from-an-apk-file-to-a-project

I wonder whether this guy was ever able to get a copy of the firmware.  Maybe see if you can contact him?

 

Link to comment
Share on other sites

4 minutes ago, Hunka Hunka Burning Love said:

I wonder if someone can decompile the KingSong APK which might give some insight into how the firmware is loaded?  Or does the firmware/bootloader itself have a decryption routine when a new firmware is uploaded to it?  I wonder if they decrypt the firmware file in the app as it is being uploaded through Bluetooth... They wouldn't do that would they?  :whistling:

I don't remember the details, but check this post / thread:

I didn't actually read what I wrote there and don't remember exactly, I've got an open KS in the next room that I want to close up tonight, a bunch of private messages and a gazillion other things to do right now  x)

Link to comment
Share on other sites

2 hours ago, Hunka Hunka Burning Love said:

I remember reading that posting.  It was very informative!  I think we were discussing firmware upload bricking at that time IIRC.  I wish I could find a copy of the firmware.  I've got a copy of IDA PRO, and I wouldn't mind playing around with it a bit.

The links to the firmware-binaries are listed in  http://apkdomain.duapp.com/kingsong/versions.json  Look for the "app_url"s, like   

"app_url":"http://apkdomain.duapp.com/kingsong/16B.bin" 
Link to comment
Share on other sites

21 hours ago, Hunka Hunka Burning Love said:

I wonder if someone can decompile the KingSong APK which might give some insight into how the firmware is loaded?  Or does the firmware/bootloader itself have a decryption routine when a new firmware is uploaded to it?  I wonder if they decrypt the firmware file in the app as it is being uploaded through Bluetooth... They wouldn't do that would they?  :whistling:

https://stackoverflow.com/questions/12732882/reverse-engineering-from-an-apk-file-to-a-project

I wonder whether this guy was ever able to get a copy of the firmware.  Maybe see if you can contact him?

 

The APK shows the link of the firmware download and can be downloaded with a browser. 

Upps. Esaj was faster.

you can use Tools to go step by step back to code. Don't estimate to get source code with remarks.

Link to comment
Share on other sites

Anyone try this online disassembler?

https://retdec.com/decompilation/

Or this one for Linux/Mac?

https://www.hopperapp.com/index.html

Some reading:

http://stm32duino.com/viewtopic.php?f=3&t=1806

I've got IDA Pro running, and I've selected the ARM little endian processor for the STM32F103 with the CORE-M3 processor, but does anyone know what settings these should be entered as?  It's also not able to find an entry point.  

445386_stm32_2.jpg

Okay I think this is way over my head at this point.  I give I give!  :crying:  So much for my amateur hacking attempt!  I don't know nothing, John Snow!

Link to comment
Share on other sites

hey esaj, thanks a lot for opening your wheel!!
guys, sorry it took me soo long the weather is too good ;)
Cortex M3, Arm7 is a good point to start. :)
Though I did not yet manage to get a useful disassembly :/

I think they use parts of the chips internal flash ram to store
other parameters like total mileage and stuff
that are not overwritten during firmware flash,
not sure about external flash.
though the coating is useful against moisture, 
it would make it difficult to read or write to a possible 
second memory chip without having a full understanding of how everything works together first,
in order to do it in software.

@Hunka Hunka Burning Love
I already decompiled one apk and found nothing that looks
like encryption or compression at least inside the java code.
However a few methods might be interesting to play with
to see if we can read or write different stuff than what
the app currently uses.

Sometime ago I saw a video from the kingsong factory,
where a guy used a custom android app to set or controll
some firmware/engine parameters, however I can't find the vid right now.
Anyway, we can use the apps Bluetooth communication methods to play around,
without having to write our own app.

private void readAlarmParas() {
        byte[] data = new byte[20];
        data[0] = (byte) -86;
        data[1] = (byte) 85;
        data[16] = (byte) -104;
        data[17] = (byte) 20;
        data[18] = (byte) 90;
        data[19] = (byte) 90;
        MainActivity.mBluetoothLeService.writeBluetoothGattCharacteristic(data);
    }
private void writeAlarmParas() {
        byte[] data = new byte[20];
        data[0] = (byte) -86;
        data[1] = (byte) 85;
        data[2] = (byte) this.speedLevel1;
        data[3] = (byte) 0;
        data[4] = (byte) this.speedLevel2;
        data[5] = (byte) 0;
        data[6] = (byte) this.speedLevel3;
        data[7] = (byte) 0;
        data[8] = (byte) this.waneSpeed;
        data[9] = (byte) 0;
        data[16] = (byte) -123;
        data[17] = (byte) 20;
        data[18] = (byte) 90;
        data[19] = (byte) 90;
        MainActivity.mBluetoothLeService.writeBluetoothGattCharacteristic(data);
    }


Of course theres a sanity check inside the firmware to not accept any values
(also a few sanity checks in the app  like if (this.speedLevel1 > this.speedLevel2 || this.speedLevel2 > this.speedLevel3)  etc.). But I did not find the time yet to recompile the project and feed some garbage to test it.
For me the result counts,  the easier the better ;)

Link to comment
Share on other sites

The hard way is to disassemble the  binary find the entry point analyse the bootloader etc. ;)

@OliverH & esaj
thanks for the link but  doesn't 16A,  16B , 16C.bin refer to the mainboard model used?

so we just get v.125 for these different hardware revisions.  :blink1:

Link to comment
Share on other sites

10 minutes ago, Spark said:

The hard way is to disassemble the  binary find the entry point analyse the bootloader etc. ;)

I don't know anything about the instruction sets used in ARMs and gave up after the decompilers I tried couldn't figure out where the sections are, I can't figure out what part is code and what part is data on my own from a hex dump. Never really worked with assembler, decompiled Java bytecode is easy, because it keeps the symbols and makes reading it very straightforward. :P

 

10 minutes ago, Spark said:

@OliverH & esaj
thanks for the link but  doesn't 16A,  16B , 16C.bin refer to the mainboard model used?

so we just get v.125 for these different hardware revisions.  :blink1:

Yeah, they're only the newest versions for each board, I was just pointing out to hunka where he can get the binaries if he wants to give it a try. Since the versionCode and the changelog is the same for all (except KS14D, and KS16S is not listed yet, apparently the mainboards are redesigned in these), I think they use the same codebase across the (older) KS14/16/18 -models, and use something like compile-time #define's to change specific things to match each wheel revisions, while most of the code stays the same. Never occurred to me to download the older versions and keep them stored, maybe someone else did? You could still try to analyze the binaries between the different wheels (like KS16A & B ) to try to see what the differences are there, although I'm not sure how useful that will be at least without knowing the hardware (like what pin goes where, which registers of the MCU match those pins etc.).

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...