The 1st step into CAS+ flashing

[critor]

Here's the CAS+ inf file content:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117

;Texas Instruments Incorporated ;Driver Information File for TI-Nspire ;Copyright (c) Texas Instruments Inc. All rights reserved. [Version] Signature           = "$Windows NT$" Class               = Net ClassGUID           = {4d36e972-e325-11ce-bfc1-08002be10318} Provider            = %TI% DriverVer           = 05/24/2006,5.2.3790.1454 CatalogFile         = tirndis.cat [Manufacturer] %TI%          = TIDevices,NT.5.1 [TIDevices] %TIDevice%    = RNDIS, USB\VID_0451&PID_E011 [TIDevices.NT.5.1] %TIDevice%    = RNDIS.NT.5.1, USB\VID_0451&PID_E011 [ControlFlags] ExcludeFromSelect=* ; Windows 2000 specific sections --------------------------------- [RNDIS.NT] Characteristics = 0x84   ; NCF_PHYSICAL + NCF_HAS_UI BusType         = 15 DriverVer       = 05/24/2006,5.2.3790.1454 AddReg          = RNDIS_AddReg_NT, RNDIS_AddReg_WIN2K_XP CopyFiles       = RNDIS_CopyFiles_NT ; DO NOT MODIFY THE SERVICE NAME [RNDIS.NT.Services] AddService = USB_RNDISY, 2, RNDIS_ServiceInst_NT, RNDIS_EventLog [RNDIS_CopyFiles_NT] ; no rename of files on Windows 2000, use the 'y' names as is usb8023y.sys, , , 0 rndismpy.sys, , , 0 [RNDIS_ServiceInst_NT] DisplayName     = %ServiceDisplayName% ServiceType     = 1 StartType       = 3 ErrorControl    = 1 ServiceBinary   = %12%\usb8023y.sys     LoadOrderGroup  = NDIS AddReg          = RNDIS_WMI_AddReg_NT [RNDIS_WMI_AddReg_NT] HKR, , MofImagePath, 0x00020000, "System32\drivers\rndismpy.sys" ; Windows XP specific sections ----------------------------------- [RNDIS.NT.5.1] Characteristics = 0x84   ; NCF_PHYSICAL + NCF_HAS_UI BusType         = 15 DriverVer       = 05/24/2006,5.2.3790.1454 AddReg          = RNDIS_AddReg_NT, RNDIS_AddReg_WIN2K_XP ; no copyfiles - the files are already in place [RNDIS.NT.5.1.Services] AddService      = USB_RNDIS, 2, RNDIS_ServiceInst_5_1, RNDIS_EventLog [RNDIS_ServiceInst_5_1] DisplayName     = %ServiceDisplayName% ServiceType     = 1 StartType       = 3 ErrorControl    = 1 ServiceBinary   = %12%\usb8023.sys     LoadOrderGroup  = NDIS AddReg          = RNDIS_WMI_AddReg_5_1 [RNDIS_WMI_AddReg_5_1] HKR, , MofImagePath, 0x00020000, "System32\drivers\rndismp.sys" ; Windows XP and Windows 2000 Sections [RNDIS_AddReg_NT] HKR, Ndi,               Service,        0, "USB_RNDISY" HKR, Ndi\Interfaces,    UpperRange,     0, "ndis5_ip" HKR, Ndi\Interfaces,    LowerRange,     0, "nolower" [RNDIS_AddReg_WIN2K_XP] HKR, NDI\params\NetworkAddress, ParamDesc,  0, %NetworkAddress% HKR, NDI\params\NetworkAddress, type,       0, "edit" HKR, NDI\params\NetworkAddress, LimitText,  0, "12" HKR, NDI\params\NetworkAddress, UpperCase,  0, "1" HKR, NDI\params\NetworkAddress, default,    0, " " HKR, NDI\params\NetworkAddress, optional,   0, "1" [RNDIS_EventLog] AddReg = RNDIS_EventLog_AddReg [RNDIS_EventLog_AddReg] HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll" HKR, , TypesSupported,   0x00010001, 7 [SourceDisksNames] 1=%SourceDisk%,,1 [SourceDisksFiles] usb8023y.sys=1 rndismpy.sys=1 [DestinationDirs] RNDIS_CopyFiles_NT    = 12 [Strings] ServiceDisplayName    = "USB Remote NDIS Network Device Driver" NetworkAddress        = "Network Address" TI                    = "Texas Instruments Incorporated" TIDevice              = "Texas Instruments Remote NDIS Network Device" SourceDisk            = "TI USB Network Driver Install Disk"

Note that the date is posterior to my oldest orange-blue CAS+ boot1/boot2/OS build dates.
(the one on which I have the OS image in the documents folder, but which doesn't work with TI-Nspire Computer Link 1.0)


The oldest CAS+ DHCP server is sending 3 to 4 IP adresses to the TI virtual network interface on my computer, which is reqesting them.
But it seems that for some reason my computer is either not receiving those IPs, either not acknowledging them.

I've tried what you proposed: manually assigning the proposed IP.
But it doesn't work: "the IP is allready in use".
I've tried assigning another IP in the same subnet, but no other active IP was visible in the subnet.

Remember the CAS+ IP seems to be the interface IP plus one.
So it might be affected after the computer acknowledges.


And of course, I have no problems with more recent CAS+ DHCP servers.

[Goplat]

I've found a buffer overflow vulnerability in the command shell's printf routine, which could potentially allow executing code by TYPEing a file. We may not be able to exploit it at this time because
- the code may have changed (the CAS+ has Reliance v2.00.0451/FlashFX v2.0, instead of Reliance v2.10.1150/FlashFX v3.00).
- the WRITE command can't create a file with 00, 08, 0A, or 0D bytes in it (this could be insurmountable, or not a problem at all, depending on what the addresses of the relevant functions and stack items turn out to be)
but I think it might be worth a try.

First step is to dump the stack to get some addresses... Try this (in whatever directory you're comfortable creating files in):

write stackdump 192
%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x
type stackdump

[bsl]

I was just looking at that vulnerability.
I was trying:
AAAA%08x%08x%08x.....%08x
and hoping to get one of the "%08x" would give me 41414141 - then replace that with %s
to read arbitrary memory addresses - could not find it so far.
Seems this technique ignores %p, havent tried %n.

critor : for a quick test try:
c:\>write test.tns 19
c:\>AAAA,%08x,%08x,%08x  <RETURN>
c:\>type test.tns
EDIT: If this format string is in the stack on the CAS+ instead of a buffer like the later models, then this looks more promising.

[critor]

critor : for a quick test try:
c:\>write test.tns 19
c:\>AAAA,%08x,%08x,%08x  <RETURN>
c:\>type test.tns

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

C:\documents\ndless\>write test.tns 19 AAAA,%08x,%08x,%08x C:\documents\ndless\>dir 1980-01-01 00:00:00     <Dir> . 1980-01-01 00:00:00     <Dir> .. 1980-01-01 00:00:00    639280 os.tns 1980-01-01 00:00:00        19 test.tns Free Space: 17480192 bytes C:\documents\ndless\>type test.tns AAAA,20000013,106F259B,00000000 C:\documents\ndless\>

[critor]

And here's the other test!

First step is to dump the stack to get some addresses... Try this (in whatever directory you're comfortable creating files in):

write stackdump 192
%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x
type stackdump

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

C:\documents\ndless\>write stackdump.tns 192 %8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8 x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x% 8x%8x%8x%8x%8x%8x%8x%8x%8x%8x%8x C:\documents\ndless\>dir 1980-01-01 00:00:00     <Dir> . 1980-01-01 00:00:00     <Dir> .. 1980-01-01 00:00:00    639280 os.tns 1980-01-01 00:00:00        19 test.tns 1980-01-01 00:00:00       192 stackdump.tns Free Space: 17479680 bytes C:\documents\ndless\>type stackdump.tns 20000013106F2648       010919DA0       0      C0       010919DB4       210919E48 10919DAC101A923C101A9C7C1091A490       0106F2188106F218D106F219C       01091A3A0       3B10919DF810919DDC101AC3A4101F1B2410917E841091A3A81091A3A0      3B10919E10 10919DFC1091A3A8FFFFFFFF106A1CB41091A3C710919E3010919E14101A93041014BA38       0 1091A3A8101AA97C106A1CA810919E4810919E34101AA70C       2       1106FB5C010919E60 10919E4C10000994101A9194       0       010919E7810919E64101279841000097C10000040 10917E8410919E7C10919E7C       0 C:\documents\ndless\>

[Goplat]

As I feared, looks like the command shell code is different (and unlike the later version, the address of RelDclVPrintf doesn't show up in uninitialized space in the TYPE command's stack frame). Without knowing the addresses of any useful functions we can't exploit the buffer overflow safely yet. We had better wait for another CAS+ OS to be dumped, so we can see the older command shell code, and come back to this then.

[mikehill2003]

As I feared, looks like the command shell code is different (and unlike the later version, the address of RelDclVPrintf doesn't show up in uninitialized space in the TYPE command's stack frame). Without knowing the addresses of any useful functions we can't exploit the buffer overflow safely yet. We had better wait for another CAS+ OS to be dumped, so we can see the older command shell code, and come back to this then.

What's the best way to dump the OS?

[critor]

As I feared, looks like the command shell code is different (and unlike the later version, the address of RelDclVPrintf doesn't show up in uninitialized space in the TYPE command's stack frame). Without knowing the addresses of any useful functions we can't exploit the buffer overflow safely yet. We had better wait for another CAS+ OS to be dumped, so we can see the older command shell code, and come back to this then.

What's the best way to dump the OS?

As far as we know up to now, the production CAS+ OS can only be dumped by connecting the NAND ROM chip to a reader...

TI-Nspire Computer Link 1.0 does only access a virtual drive content...
And it seems we can't run the DataLight shell to access the physical drive content without assembly...


But once the production OS is dumped, me may be able to dump other CAS+ OSes easier through some exploits.


Note the Ndless 1.7 installer exploit does freeze the CAS+ OS.
(calculator can still be turned off/on and the pointer can still be moved through the joypad, but that's all)

[bsl]

Try:
type /phoenix/policy.dat

Maybe changing something in this file is all that is needed !!!!!

EDIT: re-naming this file to policy.back :

Code: Select All | Copy To Clipboard

1 2 3

copy policy.dat policy.back del policy.dat

, may enable USB, and other features.

[Goplat]

Are you completely sure of what policy.dat does? I don't think we should risk the possibility that the OS won't boot without it. This is the only known copy of this OS in the world.

[critor]

Anyway, there seems to be no "policy.dat" file on the oldest 1.0.3xx OS.

Code: Select All | Copy To Clipboard

1 2 3

C:\phoenix\>type policy.dat Error = -1

[critor]

By the way, when I connect a more recent CAS+, I get a much smaller DHCP log:

Code: Select All | Copy To Clipboard

1 2	pn-srv6-1217: sent reply 2, len=281, to 172.16.80.65:68 pn-srv6-1217: sent reply 5, len=281, to 172.16.80.65:68

[critor]

Let's talk about the CAS+ DHCP server again.

When I connect the old blue-orange CAS+, I get:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

pn-srv6-701: request type 1 pn-srv6-821: ready to reply(hh=4, sz=281), typ=2, to port 68 pn-srv6-838: sent reply 2, len=281, to port 68 pn-srv6-701: request type 1 pn-srv6-1073: bound dhcp-ans [172.16.177.46:68] to 8 pn-srv6-821: ready to reply(hh=8, sz=281), typ=2, to port 68 pn-srv6-838: sent reply 2, len=281, to port 68 pn-srv6-701: request type 1 pn-srv6-821: ready to reply(hh=8, sz=281), typ=2, to port 68 pn-srv6-838: sent reply 2, len=281, to port 68 pn-srv6-701: request type 1 pn-srv6-821: ready to reply(hh=8, sz=281), typ=2, to port 68 pn-srv6-838: sent reply 2, len=281, to port 68 pn-srv6-701: request type 1 pn-srv6-821: ready to reply(hh=8, sz=281), typ=2, to port 68 pn-srv6-838: sent reply 2, len=281, to port 68 pn-srv6-701: request type 1 pn-srv6-1073: bound dhcp-ans [172.16.50.34:68] to 9 pn-srv6-821: ready to reply(hh=9, sz=281), typ=2, to port 68 pn-srv6-838: sent reply 2, len=281, to port 68

The CAS+ RNIS interface doesn't get a valid IP and I cannot send/receive files.

When I connect a more recent CAS+, I get:

Code: Select All | Copy To Clipboard

1 2	pn-srv6-1217: sent reply 2, len=281, to 172.16.80.65:68 pn-srv6-1217: sent reply 5, len=281, to 172.16.80.65:68

The CAS+ RNIS interface does get a valid IP immediatly and I can send/receive files.


Has somebody a good knowledge of the DHCP protocol, and of what could be wrong in the 1st log?

In the 1st log, after "sent reply 2", I just get "request type 1" again...
As if the sent IP was not accepted/understood by the computer, which is just asking again...


Do you know of any way of logging what is sent/received by an IP-less interface?

[perennial]

Goplat, if you want to experiment some more with the CAS+, I can send you the CAS+ calculator (experiment however you like until you are satisfied then you can send it back) also with the TI-Nspire broken ribbon(keep). Please let me know if you are interested.
(I keep deleting and posted again to get your attention.) Don't mean to spam.

[Goplat]

Thanks for the offer, but there isn't anything I could do with a CAS+; I don't know of any way to run code on it.
Regarding the other calc, I am not a hardware guy; I can't fix a broken ribbon cable (and I already have a TI-Nspire anyway).