AttributeError: 'bool' object has no attribute 'hex' #3
Comments
|
Bumping this issue up. Having the same error: Welcome to Tricore BSL. Type help or ? to list commands, you are likely looking for upload to start. (BSL) sboot |
|
It's been a long time since I originally set this up, but I'm fairly certain this indicates something isn't correct on the hardware side. PWM wires backwards (they're mislabeled in one of the pics on here, iirc), level shifter not working correctly, etc. |
|
I've dug a bit deeper and here is what I have found. Sboot executed instead of extract_boot_passwords terminates the script with the following error: IsoTPSocketConnection gets a wrong argument instead of address. class IsoTPSocketConnection(BaseConnection): Starting from 1.21 udsoncan switched to a different type of address provision. Hence it fails. |
|
Downgraded udsoncan to 1.20 and now getting: (BSL) sboot Digging deeper |
|
Here is all of the package versions that mine is running (working), maybe this will help. I'm also on debian buster version, with Python 3.9.2 async-timeout==4.0.3 |
|
@aarons3 , (BSL) extract_boot_passwords |
|
An alternate way you can get the boot passwords is via the "manual method" which is described in the Simos18_SBOOT repository. I'm on the first step where you run twister to compute the key data and get the timing value. Normally it's 01Dxxxxx for the B part number simos18 units. Yours is way different, which kind of makes me suspect that something is off here, but you can still continue the process.
|
|
run a couple 'sboot' commands and post the seed, if you can. Running twister starting at 0 on rpi hardware will be a pretty long process, a lot better on more powerful hardware if you have it. (I'm using my NAS which isn't powerful, but still a lot better than my pi4 lol). |
|
His key recovery worked, there was some weird issue with the isotp socket
where he never received a response to the Send Key message. I think the
stack trace in this case is a bit of a red herring; it’s a bug but the
alternative would basically be a nice “no data received” error.
The main thing I could see causing this would be if the ECU rebooted during
the time where the script was performing the seed/key calculation somehow.
I actually think trying again might be a viable approach here. If that
doesn’t work it’s time to start taking can dumps to see what’s up I think.
…On Fri, Nov 8, 2024 at 8:25 AM aarons3 ***@***.***> wrote:
An alternate way you can get the boot passwords is via the "manual method"
which is described in the Simos18_SBOOT repository.
I'm on the first step where you run twister to compute the key data and
get the timing value. Normally it's 01Dxxxxx for the B part number simos18
units. Yours is way different, which kind of makes me suspect that
something is off here, but you can still continue the process.
image.png (view on web)
<https://github.com/user-attachments/assets/e77fb6cb-9094-47e0-9749-99af15dcc930>
—
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABTO2NRGC573HQFS6SNJVLZ7TJWRAVCNFSM6AAAAABRNJ6BGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRVGAZTIMRRGA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
@aarons3 , [emiter@emiters-srv Simos18_SBOOT-main]$ ./twister 025748C5 dea9abac Key Data: Key Data: Key Data: Key Data: Key Data: Currently my bootloader.py values is set to 02300000 but it still takes 10-15 minutes to calculate the value. @bri3d , |
|
I do have omp installed and when I run twister it loads all 4 cores of my RPi to 400%, just for clarity |
|
Doing what Aaron suggests and using the manual process may help for you
then, offloading the calculation to your computer. The timeout is (I think)
around 5 minutes, so you have quite a bit of time. I’ve never seen such a
high variance in seed (timer) values or such a slow calculation; it seems
like your Pi has some competition for resources or low clocks (temp/power)
or… something? I developed this whole thing on a Pi 3, so it’s definitely
possible.
…On Fri, Nov 8, 2024 at 8:51 AM em1ter ***@***.***> wrote:
I do have omp installed and when I run twister it loads all 4 cores of my
RPi to 400%, just for clarity
—
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABTO2N5S7MRQSNBRRUQ663Z7TMX5AVCNFSM6AAAAABRNJ6BGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRVGA4TGNRZGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Thank you. Once again, thank you @aarons3 and @bri3d for all your advises! |
|
The documentation Aaron linked for the “manual” process will let you
offload processing using the power of copy and paste :)
…On Fri, Nov 8, 2024 at 9:15 AM em1ter ***@***.***> wrote:
Thank you.
TBH I've never worked with RPi before, although my work is closely related
with Linux and UNIX servers. The power to my Pi is supplied from lab power
supply set to 13V to CAN hat integrated buck converter. The same power line
powers the ECM.
I have not played with Pi OS and HW setup much so it may be indeed lacking
computing power. I;ll research on what I can do to speed it up.
Offloading the calculation to a separate more powerful PC can be a
solution to my problem as well however to automate it definitely requires
bootloader.py to be rewritten to pass the seed over the network somewhere
like running the command via ssh and getting the output from it. I'll see
what I can do with this.
Once again, thank you @aarons3 <https://github.com/aarons3> and @bri3d
<https://github.com/bri3d> for all your advises!
—
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABTO2M3XH35FJN3DNE5333Z7TPRJAVCNFSM6AAAAABRNJ6BGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRVGE2TINZZG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@bri3d , Sending 0x65 Security Access with Key... Since I do not have any tools dedicated for logging CAN frames but I'll try to build something from what I have laying around to dump the entire communication of Pi with ECM. Just for clarity, my ECM is Simos18.1 (06K907425B) with controller TC1791S-384. Although this project is named "TC1791_CAN_BSL" and relates to Simos18_SBOOT, in your research "secrets-of-simos18" I found that the ECM you used was Simos18.6 (06K907425E) with controller TC1791S-512. |
|
No, it’s all the same. 18.1 and 18.6 are functionally identical and 18.10
just has a different public key. The steps to enter the bootstrap loader
are the same for all Tricore parts.
I’m away from my computer and have been answering from my phone; I’ll take
a quick look to make sure the error you’re seeing isn’t a bug at its root
cause, but I’m pretty sure it’s just the ECU not responding to you sending
the Key for some reason.
…On Fri, Nov 8, 2024 at 10:11 AM em1ter ***@***.***> wrote:
@bri3d <https://github.com/bri3d> ,
I've had some progress. I have wrapped execution of twister on remote
server into sh script and made bootloader.py running it instead of local
twister. That actually worked and allowed me get key way faster than when
running it on Pi.
However I'm still getting the same error:
Sending 0x65 Security Access with Key...
Traceback (most recent call last):
File "/tools/simos18_tools/TC1791_CAN_BSL/bootloader.py", line 743, in
BootloaderRepl().cmdloop()
File "/usr/lib/python3.9/cmd.py", line 138, in cmdloop
stop = self.onecmd(line)
File "/usr/lib/python3.9/cmd.py", line 217, in onecmd
return func(arg)
File "/tools/simos18_tools/TC1791_CAN_BSL/bootloader.py", line 676, in
do_sboot
sboot_login()
File "/tools/simos18_tools/TC1791_CAN_BSL/bootloader.py", line 275, in
sboot_login
sboot_sendkey(bytearray.fromhex(key))
File "/tools/simos18_tools/TC1791_CAN_BSL/bootloader.py", line 148, in
sboot_sendkey
print_success_failure(conn.wait_frame())
File "/tools/simos18_tools/TC1791_CAN_BSL/bootloader.py", line 67, in
print_success_failure
if data[0] is 0xA0:
TypeError: 'NoneType' object is not subscriptable
Since I do not have any tools dedicated for logging CAN frames but I'll
try to build something from what I have laying around to dump the entire
communication of Pi with ECM.
Just for clarity, my ECM is Simos18.1 (06K907425B) with controller
TC1791S-384. Although this project is named "TC1791_CAN_BSL" and relates to
Simos18_SBOOT, in your research "secrets-of-simos18" I found that the ECM
you used was Simos18.6 (06K907425E) with controller TC1791S-512.
Could it be that due to firmware or hardware differences CAN frames to
communicate with ECM are different between 18.1 and 18.6?
—
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABTO2NA3S45IH5YAZKD3RTZ7TWEFAVCNFSM6AAAAABRNJ6BGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRVGMYDKNRTG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@bri3d , However there is another issue. I'm unable to perform reading. It fails with the following error: Is this another issue with my hw and/or connection or is it something different? |
|
Btw, if you don't like me flooding in this issue but still don't mind helping me please ping me on my email [email protected] and we can figure out the way of communication which most suits you. |
|
args[1] is |
Hellow!
I am trying to extract passwords and am getting the following error.
The text was updated successfully, but these errors were encountered: